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

Redis is used to store users' reward ticket information in the event. In principle, it is cleared every day, but now it is set to

ExpireAt (zero)

However, according to the recent operation feedback, some users have abnormal tickets. After checking with log, it is found that the key specified to expire at zero does not expire on time, and the data can be read from the library at 0: 23 seconds. A simple exists (key) is used in the program to determine whether the key exists or not.

In this way, it may be that the master library expired at zero, but did not synchronize to the slave library in time. On the Internet, some users encounter the same situation, Redis version 3. This would have happened before 2, and then I looked at our redis version and found that it was 3.0. no wonder we encountered the same situation.

So the solution is to add the judgment of the key lifetime ttl to the exists (key) judgment at the same time, if the ttl is 0, it will not be taken.

Experiment:

Then we measured it. Now the master database sets a key expiration time, and then reads the slave database before and after the expiration time. It is found that there is a delay in reading the expired key directly from the slave database, ranging from 5 to 7 seconds. But when we read the main library, there is basically no delay, and we can't read it at the end of the day.

Summary: for Redis versions prior to 3.2, there will be a delay in master-slave expired key synchronization failure.

Related link: https://www.cnblogs.com/bridger/archive/2012/11/07/2758734.html

Https://blog.csdn.net/u012538947/article/details/52540313

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.