How Mysql and Redis data are consistent

First clarify the relationship between Mysql and Redis: Mysql is a database used to persist data and ensure the reliability of data to a certain extent; Redis is used as a cache to improve the performance of data access.

This is a very classic question about how to ensure data consistency in Mysql and Redis (ie, cache consistency).

Anyone who has used cache should know that in practical application scenarios, it is difficult to ensure that the cache is the same as the data in the database in real time.

Basically, they try to keep their data as consistent as possible most of the time, and ensure that it is eventually consistent.

How cache inconsistencies arise

If the data has not changed, then there is no cache inconsistency problem.

Usually cache inconsistency occurs when data has changed. Because you need to operate the database and cache at the same time for each data change, and they belong to different systems, it is impossible to achieve success or failure of the operation at the same time, and there will always be a time difference. Cache inconsistency may occur during concurrent reads and writes (in theory, this can be guaranteed by distributed transactions, but in practice, few people do this).

Although there is no way to ensure strong consistency between the cache and the database when the data changes, there are certain design methods for updating the cache. Following these design methods can minimize the impact time and scope of this inconsistency.

Several designs of cache update

There are roughly four design methods for cache update:

• Delete the cache first, and then update the database (this method is most prone to long-term dirty data under concurrency, which is not desirable)
• Update the database first, delete the cache (Cache Aside Pattern)
• Only the cache is updated, and the database is updated synchronously by the cache itself (Read/Write Through Pattern)
• Only the cache is updated, and the database is updated asynchronously by the cache itself (Write Behind Cache Pattern)

Next, we will introduce some of these four design methods in detail.
Delete the cache first, then update the database

This method is prone to cache inconsistency in the case of concurrent read and write

As shown in the figure above, the possible execution flow sequence is:
Client 1 triggers logical client 2 that updates data A Triggers logical client 1 that queries data A Deletes data A in the cache
Client 2 queries data A in the cache, misses Client 2 queries data A from the database and updates it to the cache Client 1 updates data A in the database

It can be seen that the last data A in the cache is inconsistent with the data A in the database, and the data A in the cache is old dirty data.

Therefore, this method is generally not recommended.

Update the database first, and then invalidate the cache. <br>In the case of concurrent read and write, this method may also cause temporary cache inconsistency.

As shown in the figure above, the possible execution sequence of the process is:
Client 1 triggers the logical client to update data A 2 triggers the logical client to query data A 3 triggers the logical client to query data A 1 updates data A in the database
Client 2 queries data A in the cache, hits return (old data)
Client 1 invalidates the data A in the cache Client 3 queries the data A in the cache, if the miss client 3 queries the data A in the database, and updates it to the cache

It can be seen that the data A in the cache is consistent with the data A in the database. In theory, there may be data inconsistency for a short period of time, but the probability is relatively low, and most businesses will not have too many problems.

Only the cache is updated, and the database is updated synchronously by the cache itself (Read/Write Through Pattern)
This method is equivalent to that the business only updates the cache, and then the cache updates the database synchronously. An example of Write Through is as follows:

As shown in the figure above, the possible execution sequence of the process is:
Client 1 triggers the logical client to update data A 2 triggers the logical client 1 to query data A to update the data A in the cache, the cache updates the data A in the database synchronously, and then returns the result Client 2 queries the data A in the cache, and the hit returns

The process of Read Through and WriteThrough is similar, except that when the client queries data A, if the data A in the cache is invalid (expired or expelled), the cache will synchronously query the data A in the database, cache it, and then return it to the client

In this way, the probability of cache inconsistency is extremely low, but special modification of the cache is required.

Only the cache is updated, and the database is updated asynchronously by the cache itself (Write Behind Cache Pattern)
This method is detailed so that the business only operates to update the cache, and then the cache updates the database asynchronously, for example:

As shown in the figure above, the possible execution flow sequence is:
Client 1 triggers the logical client to update data A 2 Triggers the logical client 1 that queries data A to update the data A in the cache, returns client 2 to query the data A in the cache, hits the return cache and asynchronously updates the data A to the database

The advantage of this method is that the performance of reading and writing is very good. Basically, as long as the memory is operated, it will be returned to the client, but it is not strongly consistent, and there is a situation in which data is lost. If the cache service hangs when the cache asynchronously updates the data to the database, the data that has not been updated to the database at this time will be lost.

Summary <br>The several cache update design methods mentioned above are all the experience summed up by predecessors. These methods have some drawbacks more or less, and they are not perfect. In fact, it is difficult to have a perfect design. When you are designing a system, you should not pursue perfection. You must have some trade-offs and find a way that is most suitable for your business scenario.

Author: Light Chaser