Member-only story
Understanding Redis Parent-child Node Inconsistency
I recently encountered a problem in a production environment where the Key of the Redis parent node had expired, but the child nodes were still reading the expired data.
Today, I’d like to share what I learned from this problem.
We know that most business scenarios are read more and written less. In order to take advantage of this feature and improve the throughput of the Redis cluster system, the parent-child architecture and read-write separation are usually used.
As shown in the figure above.
- Parent node: responsible for the write operation of the business.
- Child node: synchronizes the data of the Parent node in real-time and provides read capability.
In order to improve throughput, the architecture of one parent and multiple children are adopted to distribute the read pressure of the business to multiple servers.
The above scheme seems reasonable, but in fact, there may be some hidden dangers!
Fault 1: Read expired data.
The high performance of Redis is mainly due to pure memory operations, but the cost of memory storage media is too high, so the storage of data has certain constraints.
The common solution is to set the expiration time. For some data that is not used very frequently, it will be deleted regularly to improve the utilization of resources.
To delete expired data, Redis provides two strategies:
- Lazy delete.
Also known as passive deletion, when the data expires, it will not be deleted immediately. Instead, it waits until there is a request for access, checks the data, and deletes the data if it expires.
Advantages: No need to start additional scanning threads separately, reducing the consumption of CPU resources.
