The LRU algorithm of Redis (i.)

Recently overtime more tired, do not want to write at all.

Just read an interesting article, the Redis author Antirez's review of the LRU algorithm for Redis. The LRU algorithm is the meaning of least recently used, discarding the least recently used resources. Redis is often used as a cache, and if you can remove infrequently used keys and keep them as often as possible, the memory utilization is quite high. Of course, LRU also has weaknesses, consider one of the following:

~~~~~a~~~~~a~~~~~a~~~~a~~~~~a~~~~~a~~|~~b~~b~~b~~b~~b~~b~~b~~b~~b~~b~~b~~b~|~~~~~~~~~~c~~~~~~~~~c~~~~~~~~~c~~~ ~~~|~~~~~d~~~~~~~~~~d~~~~~~~~~d~~~~~~~~~d|

Suppose that 4 key,a are accessed at frequencies of 5 seconds and 1 times, B accesses 2 seconds 1 times, and C and D are accessed 10 seconds 1 times. Because B has the highest frequency of access, the idle access time for B is minimal. Its last access time was also the second most recent. But D is a special case where the frequency of access is 10 seconds and 1 times, but its access time is recent.

Of course, in the long run, this algorithm is still good. Typically, a key with a high frequency of access has relatively little idle time. The LRU algorithm replaces the least recently used key, which is the longest idle time. This algorithm is very simple to implement, we order to track a key last access time can, and even sometimes do not need, as long as the maintenance of a linked list, have access to move to the table header, the need to replace the element, the end of the chain is removed.

Redis does not support LRU replacements at the earliest. By modifying the structure of the Redis object, the author squeezes out 24bit space to do it. Because the pointer is too large, there is no space to implement it with a linked list. 24bit is enough to store the time stamp low, can support 194 days, key data refresh frequently, enough.

How to choose the maximum idle time key to swap out is also a problem, the Redis key is stored in a flat hash table, adding an additional data structure to complete the cost is too large. Now that LRU is an asymptotic algorithm for the ideal page change, why don't we try the LRU asymptotic algorithm?

The original implementation of Redis is very simple: when you need to swap out a key, select any 3 keys, and swap out the longest idle time. The equivalent of a random sampling of the entire key space, and a better choice. Later, the algorithm evolved into N random key, the algorithm is optimized, the default becomes a sample of 5 keys, speed without loss. Although the implementation is so simple, it works very well. If you think about it, you will find it impossible to make the best decisions with this algorithm, but you are unlikely to make very bad decisions. If there is a heap of frequently accessed key,5 in the dataset, it is unlikely that the "hot" key will be selected for 1.

The LRU algorithm of Redis (i.)