Redis and database consistency are also called "double write consistency". In a distributed system, data inconsistency may occur due to concurrent read and write operations between multiple nodes. This article will focus on how to achieve data consistency by using the combination of Redis and database.
Reasons for data inconsistency:
First of all, when reading data, you always query Redis first, and return it directly if it hits, and query the database first if it misses, then write it into the cache and set the timeout period, so there will be no problem;
The following problems occur when modifying data:
1. Delete the cache first and then modify the database
Thread A deletes the cache first, thread B reads the cache as empty, then reads the database and adds the data to the cache, thread A modifies the database again, at this time the cache is dirty data
2. Modify the database first and then delete the cache
Thread A first reads that the cache is empty and then queries the database. Thread B deletes the cache after modifying the database. Thread A updates the data queried by thread B before modification to the cache. At this time, the cache is also dirty data.
solution:
Delayed double deletion:
After deleting the cache and modifying the database, delete the cache after a certain period of time, so that the master database can synchronize data to the slave database. Delayed double deletion is not easy to control the delay time, and dirty data may appear during the delay.
Read-write lock (strong consistency):
Use Redisson to implement read-write locks, and add shared locks when reading, which can ensure that reading and reading are not mutually exclusive, and reading and writing are mutually exclusive. When we update data, add an exclusive lock, which is read and write, and both read and read are mutually exclusive, so that we can ensure that other threads will not read data while writing data, and avoid dirty data. What needs to be noted here is that the same lock needs to be used for the read method and the write method.
Asynchronous notification (consistent delay):
1. Use RabbitMQ middleware to send a message to MQ after the data is updated, and the cache service listens to the MQ message to update the cache. Since the message needs to pass through MQ, there will be a certain delay, so the delay is consistent.
2. Ali's canal component is used to realize data synchronization: there is no need to change the business code to deploy a canal service. The canal service disguises itself as a slave node of mysql. When the mysql data is updated, canal will read the binlog data, and then obtain the data through the canal client and update the cache.
Scheme comparison and selection:
- Strong Consistency vs Delayed Consistency: Choose an appropriate data consistency scheme based on business needs, and weigh the consistency level and performance overhead.
- Performance and reliability trade-off: Evaluate the characteristics of different solutions in terms of performance and reliability, and make a choice based on requirements.
- Choose a solution based on business needs: consider the actual needs of the business, such as the frequency of data updates, the requirements for real-time data, and the scalability of the system.