A preface,

In the use of MyBatis, MybatisPlus and other DAO layer database access framework, we often deal with level 1 cache and level 2 cache. In order to enhance the overall control of the cache system and improve the response speed of software applications, we sort out the level 3 cache once.

Caching can not only improve system performance, but also bring dirty data side effects. The system’s cache system, cache structure, cache policy, cache media and so on have an impact on the possible dirty data.

Caching is a double-edged sword, which can improve the efficiency of application systems while avoiding dirty data is also a lot of work. Especially when different levels of cache are used at the same time, the probability of data exceptions increases rapidly.

Second, level 1 cache

Level-1 cache based on MyBatis technology is enabled by default and cannot be disabled. There are two types of cache: SESSION and STATEMENT. The same session can execute multiple statements before closing, at which point the level 1 cache life cycle ends. The common situation is that one SQL statement is executed per session, so there is not much difference between the two types.

mybatis:
  configuration:
  # Enforce the use of statement level caching
    local-cache-scope: statement
Copy the code
1. Dirty data analysis

Level 1 cache dirty data problems: When a session calls the same query statement (including the query condition) more than twice, the second call will cache data from the local, and at the same time, if another session changes the relevant data, it is obvious that the data queried from the cache is dirty.

Although this phenomenon does exist, given that the session duration is controllable and the data query returns to normal after the session ends, in most cases the real-time row of data does not meet this requirement.

2. Avoid dirty data
  • Enforce the use of statement level caching

The statement level cache is mandatory in the global configuration to prevent the system from caching dirty data caused by the session not being closed in time

  • Close the session in time

You are advised to execute only one SQL statement for a session and close the session immediately after the SQL statement is executed. When the session is closed, the session cache is automatically released according to the automatic transaction submission mechanism.

  • Avoid complex query statements

The complex query statement is converted into several simple statements and processed by transaction summary in the business layer. In fact, complex SQL statements have an increasingly negative impact on query performance as data volumes swell. The MybatisPlus join query solution even strongly recommends that developers abandon traditional multi-table join queries.

Third, level 2 cache

The level 2 cache is namespace oriented, and all DAO methods in the same Mapper file can affect the cache. Level 2 cache is disabled by default.

For proper use of level 2 cache, please refer to the MybatisPlus Level 2 Cache Solution article.

1. Dirty data analysis

There are many cases in which level 2 cache generates dirty data. The typical scenario is as follows:

  • The joint query

When tables A and B are jointly queried, the query data is added to the cache of the namespace where the Mapper belongs. At the same time, table A or table B updates the database data. If the joint query and update tables are not in the same namespace, The cache update signal is not received until the cache refresh time is over, so there is no doubt that there is dirty data.

2. Avoid dirty data
  • Set an appropriate cache expiration time

Level-2 cache data is forced to expire to ensure passive invalidation of cache data.

  • Avoid using traditional multi-table join queries

It is highly recommended to use MybatisPlus as the basic technology for data access to ensure that correct namespace-based cached data can be actively refreshed. New multi-table join query operation, please see MybatisPlus connection query solution.

Four, three level cache

Level-3 cache refers to the service layer cache, usually oriented to the Service layer. It mainly caches data that does not change frequently or uses CPU resources for repeated calculation. In general, level 3 cache exists on top of level 2 cache. There are many business layer cache implementations, including:

  • Caffeine Manual
  • EhCache User manual
  • Redis User manual

The business layer cache is self-controlled and can fully control the life cycle of the cache, which is quite flexible and convenient.

1. Application scenarios

Business caching, as its name implies, is the need to cache data generated by processing a business process, such as a repeated calculation, because the results can be cached because of the high frequency of calls.

It is recommended that the business layer call the DAO layer to obtain data by using the second-level cache. The main goal of the business layer is to use data, and caching data is not its main responsibility.

5. Interface cache

The interface cache is oriented to the whole interface and improves the response performance of the interface. The interface layer can call the data access layer directly, or call the data access layer (level 2 cache), xOR call the business layer, xor call the business layer (level 3 cache), or even cache the results returned by the interface itself.

Like this article click ♥️ like ♥️ support, if necessary, can contact me through wechat Dream4S. Related source code in GitHub, video explanation in B station, this article in the blog world.