[Redis] cache synchronization

[Redis] cache synchronization

1. Data synchronization strategy

There are three common ways to cache data synchronization:

1. Set the validity period : set the validity period for the cache, automatically delete it after expiration, and update it when you query again.
   • Advantages: simple and convenient
   • Disadvantages: poor timeliness, may be inconsistent before the cache expires
   • Scenario: business with low update frequency and low timeliness requirements
2. Synchronous double write : directly modify the cache while modifying the database.
   • Advantages: strong timeliness, strong consistency between cache and database
   • Disadvantages: code intrusion, high coupling
   • Scenario: Cache data that requires high consistency and timeliness
3. Asynchronous notification : Send an event notification when the database is modified, and related services modify the cached data after listening to the notification.
   • Advantages: low coupling, multiple cache services can be notified at the same time
   • Disadvantages: general timeliness, there may be intermediate inconsistencies
   • Scenario: General timeliness requirements, multiple services need to be synchronized

---

2. Asynchronous notification strategy

MQ-based asynchronous notification:

Canal-based asynchronous notification:

---

3. Canal

Canal, translated as waterway/pipe/ditch, canal is an open source project under Alibaba, developed based on Java. Provides incremental data subscription & consumption based on database incremental log analysis. GitHub address: https://github.com/alibaba/canal

Canal is implemented based on MySQL's master-slave synchronization:

• MySQL master writes data changes to the binary log (binary log), and the recorded data is called binary log events
• MySQL slave copies the master's binary log events to its relay log (relay log)
• MySQL slave replays events in the relay log, reflecting data changes to its own data

Canal is to disguise itself as a slave node of mysql, so as to monitor the binary log changes of the master. Then notify the Canal client of the obtained change information, and then complete the synchronization of other databases.

---

3.1 Canal client

Canal provides clients in various languages. When Canal detects binlog changes, it will notify the Canal client.

Canal provides clients in various languages. When Canal detects binlog changes, it will notify the Canal client. But here we will use the third-party open source canal-starter on GitHub. Address: https://github.com/NormanGyllenhaal/canal-client

Import dependencies:

<dependency>
    <groupId>top.javatool</groupId>
    <artifactId>canal-spring-boot-starter</artifactId>
    <version>1.2.1-RELEASE</version>
</dependency>

yml configuration:

canal:
  destination: heima # canal实例名称，要跟canal-server运行时设置的destination一致
  server: 192.168.101.65:11111 # canal地址 

---

3.2 Listeners

Write a listener to listen to Canal messages:

@CanalTable("tb_item") //要监听的表 
@Component
public class ItemHandler implements EntryHandler<Item> {
    
    

    @Override
    public void insert(Item item) {
    
    
        //写数据到jvm进程缓存
        //写数据到redis
    }

    @Override
    public void update(Item before, Item after) {
    
    
        //写数据到jvm进程缓存
        //写数据到redis
    }

    @Override
    public void delete(Item item) {
    
    
        //删除jvm进程缓存
        //删除redis缓存
    }
}

What Canal pushes to the canal-client is the modified row of data (row), and the canal-client we introduced will help us encapsulate the row data into the Item entity class.

In this process, you need to know the mapping relationship between the database and the entity, and you need to use several annotations of JPA: