Redis and MySQL double write consistency analysis

Cache issues

• Cache avalanche （ A large number of data sets are out of date ）;

• Cache breakdown （ Hot data expired ）;

• Cache penetration （ The data does not exist in the cache or in the data ）

Cache obsolescence

volatile-random,volatile-ttl,volatile-lru,volatile-lfu

allkeys-random,allkeys-lru,allkeys-lfu

Read write buffer

• Synchronous direct writing ： Write redis, Also write the database ;

• Write back asynchronously ： First write redis, Then wait redis When weeding out data , Synchronously write back data to the database .

Three classic caching modes

• Cache-Aside Pattern： Bypass caching mode

• Read-Through/Write-through

• Write-behind

1. Cache-Aside Pattern

Cache-Aside Reading process

Read request

Hit cache - return

Missed hit - Reading data - Update cache - return

Cache-Aside Writing process

Write requests

Update the database - Delete old cache

2. Read-Through/Write-Through（ Read and write through ）

Read-Through： By caching the abstraction layer Cache-Provider To operate reading

Read request

Hit cache - return

Missed hit - Reading data - Update cache - return

Write-Through： By caching the abstraction layer Cache-Provider To operate write

Write requests

Update the database , At the same time, set the update cache

3. Write-behind （ Asynchronous cache write ）

Follow Read-Through/Write-Through There are similar places , It's all by Cache Provider To be responsible for cache and database reading and writing .

They have another big difference ：

Read/Write-Through Is to update the cache and data synchronously ,

Write-Behind It just updates the cache , Don't update the database directly , adopt Batch asynchronous To update the database .

The consistency between cache and database is not strong , The system with high requirement of consistency should be used carefully . But it's suitable for frequent writing scenarios ,MySQL Of InnoDB Buffer Pool Mechanism This mode is used .

Question answer ：

1. When operating cache , To delete the cache , Or update the cache ？ The answer is ： Delete cache .  Update cache , It is easy to cause data inconsistency between cache and database

2. In the case of double writing , Operate database first or cache first ？ The answer is ： Database first .  Operation first cache , It is also easy to cause inconsistency between cache and database data

4. Yes 3 Two schemes ensure weak consistency between database and cache , Final consistency

Personally feel , In the business scenario of pursuing absolute consistency , It is not suitable to introduce caching mechanism

Premise ： There is a failure to delete the cache , So how to ensure consistency ？

1.  Cache delay double delete ： The delay time is difficult to control , The second deletion may fail

2.  Delete cache retry mechanism （ Message queue ）： Business code intrusion

3. Read binlog Delete cache asynchronously

Retry deleting the cache mechanism is ok , It will cause a lot of Business code intrusion . Actually , You can also optimize ： Through the database binlog To eliminate key

With mysql For example ：

• You can use Ali's canal take binlog Log collection sent to MQ Inside the queue

• And then through ACK The mechanism confirms that this update message is processed , Delete cache , Ensure data cache consistency