Shulou(Shulou.com)06/03 Report--

This article focuses on "how to achieve data consistency between Redis cache and database". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "how to achieve data consistency between Redis cache and database".

Catalogue

I. consistency

1. Strong consistency

2. Weak consistency

3. Final consistency

2. Data consistency solution between redis cache and mysql database

1. Plan 1: adopt delayed double deletion strategy

2. Solution 2: update the cache in one step (synchronization mechanism based on subscription Binlog)

First of all, let's take a look at what kinds of consistency are there?

1. Consistency 1. Strong consistency

If your project's requirements for caching are strongly consistent, do not use caching. This level of consistency is most in line with the user's intuition, it requires the system to write what will be read, and the user experience is good, but it often has a great impact on the performance of the system.

2. Weak consistency

This consistency level restricts the value that the system can read and write immediately after a successful write, and does not promise how long the data will be consistent, but will try its best to ensure that the data can reach a consistent state after reaching a certain time level (such as second level).

3. Final consistency

The final consistency is a special case of weak consistency, and the system will ensure that a state of data consistency can be achieved within a certain period of time. The reason why the final consistency is put forward separately is that it is not only a kind of consistency model highly respected in weak consistency, but also a model respected by the industry in the data consistency of large-scale distributed systems. In general, high availability ensures only final consistency, not strong consistency.

With strong consistency, read and write requests will be serialized into a memory queue, which will greatly increase the processing efficiency of the system and greatly reduce the throughput.

2. Data consistency solution between redis cache and mysql database

In this picture, many of the business operations of most people are cached according to this diagram. But once it is designed to double write or

Database and cache updates and other operations, it is easy to have data consistency problems. Whether you write to the database first, delete the cache first, or delete the cache first, the problem of data consistency will occur when writing to the database. Give two small examples.

1. Delete the redis cache first, but for some other reason, before writing to the database, another thread reads it and finds that the cache is empty, then goes to the database to read the previous data and writes to the cache. In this case, the cache is dirty.

2. If the database is written first, but before the cache is deleted, the thread writing to the database is interrupted for other reasons. If the cache is not deleted, the data inconsistency will also occur.

Generally speaking, write and read are concurrent in most cases, and there is no absolute guarantee of sequence, so it is easy to have inconsistent cache and database data. How can we solve this problem?

1. Plan 1: adopt delayed double deletion strategy

Basic idea: delete the cache before and after writing to the library, and set a reasonable timeout

Basic steps: delete the cache first-then write to the database-hibernate for a while-delete the cache again

Note: the time of dormancy is determined according to the time spent reading data business logic of your project. The main purpose of this is to ensure that the read request ends before the write request, which can delete the cache dirty data caused by the read request.

The disadvantage of this scheme: set double deletion policy + cache timeout policy setting, so the worst result is that the data is inconsistent within the timeout time, and it increases the time-consuming of writing requests.

2. Solution 2: update the cache in one step (synchronization mechanism based on subscription Binlog)

Basic idea: mysql Binlog enhanced subscription consumption + message queue + incremental data update to redis- read redis: hot data is basically written in redis- mysql: additions, deletions and modifications are all operations mysql- update redis data: mysql data operation Binlog, to update redis

Let's take a look at the detailed process.

1. Redis update

1). Data operation is mainly divided into two parts:

One is full volume, which writes all the data to redis;, and the other is increment (update, insert, delete) for real-time updates.

2) analyze after reading binlog, use message queue to push and update redis cache data of each station.

In this way, once there are new write, update, delete and other operations in MySQL, the messages related to binlog can be pushed to Redis,Redis, and then the Redis can be updated according to the records in binlog.

In fact, this mechanism is very similar to the master-slave backup mechanism of MySQL, because the master and slave of MySQL also achieve data consistency through binlog.

Here you can use canal (an open source framework of Ali), through which you can subscribe to MySQL's binlog, and canal imitates the backup request of mysql's slave database, which makes the data update of Redis achieve the same effect.

Of course, the message push tool here you can also use other third parties: kafka, rabbitMQ, etc., to implement the push update Redis.

At this point, I believe you have a deeper understanding of "how to achieve data consistency between Redis cache and database". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.