Preface summary:
Under the condition of satisfying real-time performance, there is no scheme that completely preserves the consistency between the two, only the final consistency scheme.
Graphical description:
- Sequence diagram, describing the calling sequence of requests;
- The red line is request A, and the black line is request B;
- The text in red is the final inconsistent data between MySQL and Redis;
- The data is updated from 10 to 11.
1. Write MySQL first, then Redis
Requests A and B both write to MySQL first, and then write to Redis. In the case of high concurrency, if request A freezes when writing to Redis, and request B has completed the data update in sequence, the problem in the figure will appear.
But there is a premise here, that is, for read requests, first read Redis, if not, then read DB, but read requests will not write back to Redis . That is, read requests do not update Redis.
2. Write MySQL first, then delete Redis
In view of this situation, in the first query, the data requested by B is 10, but the MySQL data is 11. There is only this inconsistency, which can be tolerated for businesses that do not require strong consistency .
When requesting B to perform the second query, because Redis is not hit, the DB will be checked again, and then written back to Redis.
3. Write MySQL first, and update Redis asynchronously through Binlog
This solution will guarantee the final consistency of MySQL and Redis, but if request B needs to query data halfway, if there is no data in the cache, it will directly query DB; if there is data in the cache, the query data will also be inconsistent.
Therefore, this solution is the ultimate solution to achieve final consistency, but it cannot guarantee real-time performance.
4. Discussion of alternatives
(1) Write MySQL first, then Redis
- For projects with low concurrency and consistency requirements, many of them are used in this way;
- When Redis is instantly unavailable, it is necessary to call the police and deal with it offline.
(2) Write MySQL first, then delete Redis
- This method is recommended. If deleting Redis fails, you can try again several times, otherwise the alarm will be issued;
- This solution is the best solution in real-time, and is recommended in some high-concurrency scenarios.
(3) Write MySQL first, and update Redis asynchronously through Binlog
- For remote disaster recovery and data aggregation, it is recommended to use this method, such as binlog + kafka, and the data consistency can also reach the second level;
- This solution is not recommended for purely high-concurrency scenarios, such as snap-ups, flash sales, etc.
5. Personal conclusions
- Real-time consistency scheme : adopt the strategy of "write MySQL first, then delete Redis". Although there may be inconsistencies between the two in this case, the conditions to be met are a bit harsh, so it is to meet the real-time conditions and try to satisfy the consistency the optimal solution of .
- Final consistency scheme : "write MySQL first, then update Redis asynchronously through Binlog", and update Redis asynchronously through Binlog combined with message queues, which is the optimal solution for final consistency.