daidawang Technical Blog

website·Indexed 30 days ago

https://daidawang.github.io

A technical blog featuring deep dives into the Spring Framework, including Spring Boot lifecycle, BeanFactory, ApplicationContext, and AOP. The content also covers distributed system theories such as CAP and BASE, distributed ID generation (Snowflake), LBS spatial queries for administrative region parsing, and guides on Node.js and Hexo deployment.

Tokens
47.9K
Snippets
164
Records
224
Agent score
74%

What's inside daidawang

  1. Overview of Spring Boot MVC Auto-Configuration components

    Spring Boot's MVC auto-configuration is driven by four primary configuration classes:

    • ServletWebServerFactoryAutoConfiguration: Configures the embedded Tomcat server factory.
    • DispatcherServletAutoConfiguration: Configures the DispatcherServlet.
    • WebMvcAutoConfiguration: Configures various WebMVC components.
    • ErrorMvcAutoConfiguration: Configures MVC error handling.
  2. Understand the Spring BeanDefinition registration process

    Spring uses BeanDefinition to encapsulate the basic information required to create a Bean. The general workflow for adding a Bean to the container is:

    1. Use a BeanDefinitionReader (e.g., XmlBeanDefinitionReader) or ClassPathBeanDefinitionScanner (which powers @ComponentScan) to read configuration/annotations and generate a BeanDefinition.
    2. Register the BeanDefinition into a BeanDefinitionRegistry.
    3. When the Bean is needed, Spring retrieves the BeanDefinition from the registry to instantiate the Bean.
    4. If the Bean is a singleton, it is stored in the SingletonBeanRegistry (the first level of the three-level cache) to avoid repeated creation.
  3. Understand the role of AnnotationAwareAspectJAutoProxyCreator in Spring AOP

    The AnnotationAwareAspectJAutoProxyCreator is a Bean Post Processor responsible for two primary tasks in Spring AOP:

    1. Identifying all aspects in the container and converting high-level aspects (those using @Aspect annotations) into low-level aspects (Advisors).
    2. Creating proxy objects for eligible beans using ProxyFactory based on the identified aspect information.

    It operates during the Bean lifecycle, allowing extensions either before dependency injection or after Bean initialization.

  4. Understand TCC (Try-Confirm-Cancel) Distributed Transaction Pattern

    TCC is a distributed transaction pattern that ensures eventual consistency by splitting a business operation into three phases: Try, Confirm, and Cancel.

    Advantages:

    • Performance: Resource locking is granular rather than locking the entire resource.
    • Eventual Consistency: Guaranteed via idempotent Confirm and Cancel operations.
    • Reliability: Solves coordinator single-point-of-failure through timeout mechanisms and backup coordinators.

    Disadvantages:

    • High development cost due to business coupling and the need to implement three distinct methods for every operation.
  5. Apply BASE theory for eventual consistency

    BASE is a pragmatic approach to the CAP theorem, prioritizing availability over strong consistency to achieve eventual consistency based on business needs.

    • Basically Available (BA): The system guarantees core functionality even during failures. This may involve increased response times (e.g., 0.5s to 1s) or disabling non-essential features (degradation) during peak loads.
    • Soft State (S): The system allows data to exist in an intermediate or inconsistent state for a period, such as data replication lag between nodes.
    • Eventually Consistent (E): Provided no new updates occur, the system guarantees that all data replicas will eventually converge to the same latest value.
  6. Implement coordinate-to-city resolution using a spatial database

    To resolve coordinates (longitude/latitude) into administrative regions (province, city, district) without relying on external APIs, you can use a database that supports Spatial data types (e.g., MySQL, SQL Server, Oracle, PostgreSQL). The process involves downloading boundary vector data, importing it into a spatial-enabled table, and using spatial intersection queries to find which boundary polygon contains a specific point.
  7. Manage distributed transactions with Seata

    Seata is a distributed transaction framework utilizing three primary roles:

    • TC (Transaction Coordinator): Maintains global and branch transaction states and coordinates commits/rollbacks.
    • TM (Transaction Manager): Defines the global transaction scope, starts the transaction, and triggers commit/rollback.
    • RM (Resource Manager): Manages the resources of branch transactions and communicates with the TC to register and report status.

    Supported Modes:

    • AT Mode: Default mode. Eventually consistent, no business intrusion.
    • TCC Mode: Eventually consistent, requires business intrusion (manual implementation of Try-Confirm-Cancel).
    • XA Mode: Strong consistency, sacrifices availability, no business intrusion.
    • SAGA Mode: Designed for long-running transactions, requires business intrusion.
  8. Understand the CAP Theorem trade-offs

    The CAP theorem states that a distributed system can only satisfy two out of three requirements: Consistency, Availability, and Partition Tolerance. Since Partition Tolerance is essential for distributed systems, the choice is typically between CP and AP.

    • Consistency (C): All nodes see the same data at the same time. This is categorized into:
      • Strong Consistency: Every subsequent access after an update sees the latest data.
      • Weak Consistency: Some or all subsequent accesses may see old data.
      • Eventual Consistency: After a period of time, all accesses will see the latest data.
    • Availability (A): The system remains operational and responds within a normal timeframe, avoiding timeouts or failures.
    • Partition Tolerance (P): The system continues to operate despite network failures or node outages.

    Trade-off Scenarios:

    • CP (Consistency + Partition Tolerance): Sacrifices availability. The system may be unavailable for a period to ensure data consistency.
    • AP (Availability + Partition Tolerance): Sacrifices consistency. The system remains available, but concurrent accesses may see inconsistent data.
  9. Understand the Spring Container Interface Hierarchy

    The Spring container is structured as a hierarchy of interfaces. ConfigurableApplicationContext extends ApplicationContext, which in turn extends BeanFactory. BeanFactory is the core Spring IoC container providing basic bean management. ApplicationContext is an extension of BeanFactory that adds enterprise-specific functionality. In most implementations, ApplicationContext contains a BeanFactory as a member variable, and calls to context.getBean() are delegated to the underlying BeanFactory.
  10. Understand the relationship between @Aspect and Advisor

    In Spring AOP, @Aspect represents a high-level aspect definition, while Advisor is the low-level representation used at runtime. Spring converts high-level aspect annotations into low-level Advisors. The common high-level notification annotations include:

    • @Before: Pre-processing
    • @AfterReturning: Post-processing after successful return
    • @AfterThrowing: Processing after an exception is thrown
    • @After: Final processing (regardless of outcome)
    • @Around: Full wrap-around processing
  11. Install Seata dependencies in a Spring Boot project

    To integrate Seata into a service (e.g., order-service), add the following dependencies to your pom.xml. Note that the seata-spring-boot-starter is explicitly versioned to avoid using the older version (1.3.0) bundled with the Spring Cloud Alibaba starter.
    <!-- seata -->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
        <exclusions>
            <!-- Exclude lower version 1.3.0 -->
            <exclusion>
                <artifactId>seata-spring-boot-starter</artifactId>
                <groupId>io.seata</groupId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>io.seata</groupId>
        <artifactId>seata-spring-boot-starter</artifactId>
        <!-- Use version 1.4.2 -->
        <version>${seata.version}</version>
    </dependency>