Simplicity First Technical Notes

website·Indexed 29 days ago

https://web-note-kappa.vercel.app

A collection of technical notes and guides focusing on Java development, Spring Boot, and distributed systems. Topics include JVM internals, Spring framework (IoC, AOP), database optimization, distributed transactions, Dubbo, and practical troubleshooting for production issues like FGC and CPU spikes.

Tokens
39.7K
Snippets
95
Records
229
Agent score
70%

What's inside Simplicity First

  1. Overview of Distributed Transaction Implementation Schemes

    In microservices architectures where business systems have independent databases, distributed transactions are required to ensure consistency across multiple data stores. Common implementation strategies include:

    • 2PC/XA: A two-phase commit protocol ensuring strong consistency.
    • TCC (Try-Confirm-Cancel): A business-level two-phase design.
    • AT Mode: A non-intrusive approach (e.g., Seata) that uses data snapshots.
    • Local Message Table: Ensuring consistency via a local table to track message status.
    • Reliable Message Eventual Consistency: Using message queues to achieve eventual consistency.
    • Best-Effort Notification: A notification-based approach where the system attempts to notify the target but does not guarantee delivery.
  2. Overview of JVM architecture and components

    The JVM consists of two subsystems and two components that work together to execute Java bytecode:

    • Class Loader (Subsystem): Loads .class files into the Method Area of the Runtime Data Area based on the fully qualified class name.
    • Execution Engine (Subsystem): Translates bytecode into native machine instructions for the CPU to execute.
    • Runtime Data Area (Component): The memory managed by the JVM (Heap, Stack, etc.).
    • Native Interface (Component): The interface used to interact with native libraries written in other programming languages.
  3. Overview of Spring Framework Core Modules

    Spring is a lightweight framework designed to improve development efficiency and system maintainability. It consists of several key modules:

    • Spring Core: The foundation for all other functions, primarily providing IoC (Inversion of Control) and dependency injection.
    • Spring AOP: Provides Aspect-Oriented Programming implementation.
    • Spring Aspects: Supports integration with AspectJ.
    • Spring JDBC: Java Database Connectivity support.
    • Spring JMS: Java Message Service support.
    • Spring ORM: Supports ORM tools like Hibernate.
    • Spring Web: Support for creating Web applications (includes WebFlux for asynchronous responsive processing in 5.x).
    • Spring Test: Support for JUnit and TestNG testing.
  4. Dubbo Core Components Overview

    Dubbo is a high-performance RPC framework designed for service governance in distributed systems. Its core architecture consists of the following components:

    • Provider: The service provider that exposes services.
    • Consumer: The service consumer that calls remote services.
    • Registry: The registry center responsible for service registration and discovery.
    • Monitor: The monitoring center used for access statistics and call tracking.
    • Container: The service runtime container that manages the loading and execution of services.
  5. Compare Dubbo and Spring Cloud

    While both are used for distributed systems, they differ primarily in communication and architecture:

    • Communication: Dubbo uses RPC (Remote Procedure Call) for high-performance binary communication, whereas Spring Cloud typically uses HTTP RESTFul services.
    • Architecture: They have different component ecosystems for service discovery, configuration, and gateway management.
  6. Understand the Dubbo architectural layers

    Dubbo is designed with a ten-layer architecture to decouple different concerns of the RPC process:

    1. Service Layer: Interface layer implemented by providers and consumers.
    2. Config Layer: Configuration management for Dubbo settings.
    3. Proxy Layer: Transparent service interface proxy; generates client Stubs and server Skeletons.
    4. Registry Layer: Handles service registration and discovery.
    5. Cluster Layer: Manages routing and load balancing across multiple service providers.
    6. Monitor Layer: Monitors RPC call counts and execution time.
    7. Protocol Layer: Encapsulates the RPC call logic.
    8. Exchange Layer: Encapsulates request-response patterns and converts synchronous calls to asynchronous.
    9. Transport Layer: Abstract network transmission layer (e.g., using Netty or Mina).
    10. Serialize Layer: Handles data serialization for network transmission.
  7. Understand Database Transaction Fundamentals and ACID Properties

    A transaction is a logical group of operations that must either all succeed or all fail (atomicity). For transactions to work, the underlying database engine must support them (e.g., MySQL's InnoDB supports transactions, while MyISAM does not).

    ACID Properties:

    • Atomicity: The transaction is the smallest unit of execution and cannot be split. Either all actions complete or none do.
    • Consistency: Data remains consistent before and after the transaction.
    • Isolation: Concurrent transactions do not interfere with each other.
    • Durability: Once committed, changes are permanent even in the event of a system failure.

    Implementation in InnoDB:

    • Isolation is achieved via locking mechanisms.
    • Durability is ensured by the redo log (records new data backups).
    • Atomicity and Consistency are ensured by the undo log (records data backups before modification to allow rollbacks).
  8. Understand the MySQL query execution lifecycle

    When a SQL statement is executed in MySQL, it passes through the following components:

    1. Connector: Handles authentication and permission checks during login.
    2. Query Cache: Checks for cached results (Removed in MySQL 8.0).
    3. Analyzer: Parses the SQL statement to determine the intent and validates syntax.
    4. Optimizer: Determines the most efficient execution plan (e.g., choosing which index to use).
    5. Executor: Executes the plan and retrieves data from the storage engine.
  9. Configure HTTP Request Headers

    Request headers provide additional information about the client and the request:

    • Host: Specifies the domain name of the server and optionally the TCP port. Defaults to port 80 for HTTP.
    • Referer: Indicates the address of the page that linked to the requested resource, allowing servers to track traffic sources.
    Host: developer.mozilla.org
    Referer: https://developer.mozilla.org/testpage.html
  10. Seata underlying architecture principles

    Seata implements distributed transactions using the following mechanisms:

    1. TM and RM: It utilizes a Transaction Manager (TM) for global transactions and a Resource Manager (RM) for branch transactions, using Netty for coordination.
    2. Connection Interception: It uses Spring AOP to intercept the Connection in the Datasource class. When a commit occurs, a new sub-thread is started to handle locking, while other transaction commits are unlocked by the RM.
    3. Transaction Groups: The initiator starts a transaction group and registers it, with the RM notifying participants to complete the registration.
  11. Understand the SpringMVC request processing flow

    SpringMVC operates using several key components to handle HTTP requests:

    1. DispatcherServlet: The front controller that receives all incoming requests.
    2. HandlerMapping: Parses the request to determine which specific handler method should be executed.
    3. HandlerAdapter: Responsible for invoking the determined handler method.
    4. ViewResolver: Resolves the result of the handler to prepare the jump to a specific physical view.