Shulou(Shulou.com)05/31 Report--

This article introduces you how to keep the data in MySQL and Redis consistent, the content is very detailed, interested friends can refer to, hope to be helpful to you.

In high concurrency business scenarios, the data consistency of MySQL and Redis is very important. Accessing MySQL for many times will lead to failure or slow down, while too much cache Redis will also cause problems, that is, data will be lost, stored, and the data will be lost.

Redis is most widely used in the Internet industry. In many cases, it is also called "in-memory database". It combines the advantages of cache and database, but it is not easy to turn on persistence and active-standby synchronization mechanism.

If the database is successfully written, the cache will be invalidated and cached the next time it is read. This is the real-time policy of caching.

From the perspective of architecture design: cache is cache, cache data will be lost at any time, the purpose of cache is to intercept requests to the database, compared to data reliability, consistency, or throughput, stability priority.

There are three refresh strategies considering data consistency.

Real-time strategy

Asynchronous strategy

Timing strategy

Real-time policy is the most commonly used strategy, which can give users the best experience, but once the amount of data is too large, it will appear, and the data will often be unbearable.

The asynchronous strategy applies to a large amount of data, but the data is not important because it may lead to dirty data or data loss.

Timing strategy is suitable for situations where the amount of data is large and the data is also very important. This is also the most stable solution.

In the process of reading, the application first fetches the data from the cache, and if it does not get it, it fetches the data from the database and puts it in the cache after success. If hit, the application fetches the data from the cache, fetches it and returns.

In the process of writing, the data is saved in the database, and after success, the cache is deleted, and the next time it is read, it will be written to the cache.

From the point of view of user experience, as soon as there are writes to the database, the cache is discarded and a database read is triggered to update the cache.

However, this contradicts high concurrency-if everything is read from the database in real time, the database is often unbearable in high concurrency scenarios.

When reading and writing data, there is generally no problem with applying the timing policy.

MySQL persisted data, Redis read-only data

MySQL and Redis deal with different data types

MySQL deals with real-time data, while Redis processing does not require very high real-time data. In the case of low concurrency, the read operation gives priority to reading the redis, accesses the MySQL if it does not exist, and writes the read data back to the Redis; the write operation writes directly to the MySQL, and then to the Redis. In the case of high concurrency, the read operation is the same as above, while the write operation uses asynchronous writes, writing Redis first and then returning directly, and then writing MySQL periodically.

When it comes to updating data, it is easy to have the problem of data consistency between the cache and the database. Whether it is writing to the database and then deleting the cache, or deleting the cache before writing to the database, data inconsistencies may occur, for example:

Before writing to the database and then deleting the cache, the thread is down. If the cache is not deleted, there will be data inconsistencies.

Delete Redis first, and before writing to the database, another thread reads it and finds that the cache is empty. At this time, it will go to the database to read data and write to the cache. At this time, the data in the cache is dirty data.

Because writes and reads are concurrent and there is no way to guarantee the order, there will be a problem that the data in the cache and the database are inconsistent. At this time, you can use the

Delayed double deletion strategy

Perform Redis.del (key) operations before and after writing to the library, and set a reasonable timeout

Delete cache first

Write the database again

Dormant for a while

Delete the cache again

Set the expiration time of the cache

In theory, setting the cache expiration time is the solution to ensure ultimate consistency. All write operations are based on the database. As long as the cache expiration time is reached, the subsequent read request will naturally read the new value from the database and then backfill the cache.

So much for sharing on how to keep the data consistent in MySQL and Redis. I hope the above content can be helpful to you and learn more. If you think the article is good, you can share it for more people to see.

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.