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

In this issue, Xiaobian will bring you an example analysis of Redis and database data consistency. The article is rich in content and analyzed and described from a professional perspective. After reading this article, I hope you can gain something.

When it comes to maintaining data consistency between Redis and Mysql, the first solution that many people think of is to serialize read and write requests and string them into a memory queue. But this scheme has a fatal drawback: serializing read and write requests results in a significant reduction in system throughput, requiring several times more machines than normal to support a request on the line. Why does the consistency problem between Redis and Mysql arise? In fact, we can consider such a business scenario: we need to update some data, we first update the database data, and then clear the data in the Redis cache. However, the database update operation succeeded, but there was an exception in Redis clearing the cache, which would lead to such a situation: the data in the database has been updated to the latest data, but the data in the Redis cache is still old data. At this time, there will be data consistency problems between Redis and Mysql.

Some opportunistic friends will think, that I first clear the old data in the cache, and then write new data to the database, and finally update the cache can not? There may be a problem in this way: we clear the Redis cache successfully, but the write has not written new data to the database before a read request occurs, which will cause the old data in the database to be stored in Redis again, and then wait until the new data is written to the database. Data consistency between Redis and Mysql.

Yesterday, when talking about Redis distributed environment, it was actually said that in distributed environment, data read and write operations are concurrent operations, so the order of execution of read and write operations with a piece of data cannot be guaranteed, so it may occur that read operations are executed before write operations, and then dirty data will occur leading to data consistency problems. At this time, we need to consider whether the data we read is strong consistency data, such as account balance, which must be strong consistency data, then read the database. If the real-time data read is not very strict, such as the score leaderboard, we can read Redis data directly. If the concurrency of the machine is not high, the read data is read from Redis first, and the data obtained from the database is written to Redis only when the data does not exist in the cache. Write data is the opposite, first clear Redis cache data, and then write data to the database, if it is simple data, this time can be written to Redis for read operation, if it is data that needs multi-table table query, you can temporarily not write Redis, wait until there is query operation and then write to Redis.

What if it's high concurrency? In case of high concurrency, read data operations are the same as above, read from Redis first. However, the write data operation is different from the previous one. In the case of high concurrency, the write data is first written to Redis, and then regularly written from Redis to Mysql. In the case of high concurrency, it should be noted that each request to read data needs to return data within the timeout period. If the data is updated frequently, it may cause Redis to backlog a series of update operations, resulting in a large number of read data requests timeout. Finally, this large number of read data requests are all pressed to the database, resulting in cache breakdown, which may seriously lead to database downtime. At this time, the solution is generally to increase throughput by adding machines, or temporarily return an old data to the client.

So here we are actually very clear about the scheme, there are two more common schemes: Redis is used as a cache server, generally as a cache for two purposes: request fast processing and reduce I/O frequency. Reducing I/O frequency actually means that data is written to the database in real time under the high concurrency situation just mentioned, and then the data is accumulated to a certain extent and written to the database regularly. Rapid request processing is limited to obtaining data from Redis when processing read requests. Redis supports high concurrency operations, so the processing speed is very fast. If there is no data in Redis, query in the database, and then write to the cache in Redis, so that the second read can directly fetch data from the cache.

The second scheme is asynchronous cache. Redis caches hot data. Add, delete and change are all in Mysql operation. As long as Mysql has insert, update and delete operations, binlog-related messages can be pushed to Redis through kafka or rabbitMQ and other third-party message push tools. Redis parses the data in binlog to update the data in Redis cache. The master-slave backup mechanism in Mysql also implements data consistency through binlog.

The above is an example analysis of the consistency of Redis and database data shared by Xiaobian. If there are similar doubts, please refer to the above analysis for understanding. If you want to know more about it, please pay attention to the industry information channel.

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.