Today, I will share a high-frequency interview question for a first-tier company. "How to ensure data consistency based on the architecture of Redis and MySQL". This problem has stumped many programmers who have worked for more than 5 years. The difficulty is not the problem itself, but the idea of solving this problem.
1
background introduction
In general, Redis is used as a cache for read operations between applications and databases. The main purpose is to reduce database IO and improve data IO performance. As shown in the figure, this is the overall architectural design of Redis plus MySQL.
When the application needs to read some data, it will first try to load it in Redis, and return directly if it hits. If there is no hit, query from the database, and then cache the data in Redis after querying the data.
In such an architecture, there will be a problem, that is, a piece of data is stored in the database and Redis at the same time. When the data changes, Redis and MySQL need to be updated at the same time. Since the updates are sequential, this kind of two sides In the writing environment, it cannot satisfy the ACID characteristics like pure database operations. Therefore, there may be a situation where one party fails to update while the other party succeeds, resulting in data consistency problems.
2
Solutions
If there is a data consistency problem, how can we solve it? Generally, the following two solutions come to mind.
Either update the database first, then update the cache;
Either delete the cache first, and then update the database.
If the scheme of updating the database first and then updating the cache is adopted, there will also be such a problem. If the cache update fails, the data in the database and Redis will be inconsistent.
If the cache is deleted first, and then the database is updated, the ideal situation is that when the application accesses Redis next time, it finds that the data in Redis is empty, and loads and saves it from the database to Redis, then the data is consistent. However, in extreme cases, the atomicity of deleting Redis and updating the database cannot be guaranteed, so if other threads access this process, there will still be data inconsistencies.
Therefore, if you need to ensure the data consistency of Redis and MySQL in extreme cases, you can only use the final consistency scheme.
As shown in the figure, for example, RocketMQ-based reliable message communication is used to achieve eventual consistency.
For another example, you can also monitor the Binlog log in MySQL directly through the Canal component, and synchronize the updated data to Redis.
Because this is implemented based on eventual consistency, if the business scenario cannot accept short-term data inconsistency, then this solution cannot be used.
The above is my understanding of this issue.
3
Summarize
When we are interviewing, the interviewer may also ask various purely technical questions without scenarios, such as: "Your final consistency solution" still has data inconsistency? How to solve it?
Don’t panic, technology is for business, so different business scenarios have different technology choices and solution designs, so at this time, you can ask the interviewer, what is the specific business scenario?
Everyone must remember that a certain technical solution cannot be applied to all business scenarios. There is only the most suitable solution, and there is no optimal solution.