Algorithms in Redis, Memcached, guava, Ehcache

Cache those things, one is a memory explosion to use the LRU (least recently used), LFU (minimum number of accesses), FIFO algorithm cleanup Some, and set the timeout time to delete the key expires, with an active or lazy method.

Before looking at all the details, you can read a fairly professional "cache algorithm", the world is really wide, the algorithm is really wonderful.

1. LRU Simple and rough Redis

Today, REDIS3.0 's release notice said that the LRU algorithm greatly improved, the open source code to gossip about, the results of distress, the old version of the "approximate LRU" algorithm, is too simple, too lazy, too redis.

Search for LRU on GitHub's Redis project and find the code in REDIS.C's freememoryifneeded () function.

First look at the 2.6 version of the code: unexpectedly is randomly find three records out, compare which idle time the longest to delete which, and then randomly three out, has been deleted to memory enough to put down new records so far .... Poor I look at the configuration document after the imagination, always thought it would help me in the whole redis to find the longest free time, which I think I have 1 million records, it casually find three and began to delete.

Good, clean up the mood again to see the 3.0 version of the improvement: now every random five records, inserted into a length of 16 in the queue of idle time, and then delete the line of the Pai, and then find five out, continue to try to insert the queue ... Well, a little bit, at least two times at random, at least not only in a random five to find the longest in the article, will be together with the previous comparison. the memcached

By contrast, memcached implements a standard LRU algorithm that uses a textbook bidirectional list to store the LRU relationships in the slab. Code in the ITEM.C, see memcached Source Analysis-----The LRU queue and the item structure, the elements inserted into the column header, when the deletion of their own front and back two elements butt up, update the first to do the removal and then do the insertion.

Allocating memory over time will naturally start cleaning up from the end of the LRU queue. the same guava Cache

Guava cache also made a two-way queue, see LocalCache in the Accessqueue class, also will be in the super-time from queue tail cleanup, see evictentries () function. the same ehcache/hazelcast as the old Redis version

Look at the document, incredibly like Redis2.6, directly randomly 8 records, find the oldest that, brush to disk, and then see the code, eviction class and Onheapstore evict () function.

Look at Hazelcast, almost the same, randomly take 25. This algorithm, switching to LFU is also very simple. Summary

But then think about it, maybe Redis is not the main cache, this memory explosion needs to remove some elements through the LRU is not its primary function, the default settings are not noeviction--memory directly error, so do not bother to build a doubly linked list, And every visit to update it, look at Google Group long discussion, the new version of the algorithm is also the crystallization of community wisdom. Moreover, Ehcache and Hazelcast is also the same as its old version of the algorithm, the new version of Redis is also stronger than the two.

Later, according to @ Liu Shaohong classmate's hint, JBoss Infinispan also implemented more advanced lirs algorithm than LRU, can avoid some cold data for some reason is a large number of access, the hot data is squeezed out.

2. Expiration key Delete

If you can start a timer for each of the outdated elements, one to the time trigger to delete it, it is undoubtedly the fastest way to remove the expiration key is the most space, in Java with a deplayqueue stored, open thread constantly read can do. But because the thread consumes more CPUs and is a bit wasteful in memory, it seems like we don't have to use this method.

So the lazy check is that every time the element is accessed, it checks whether it has timed out, and this is the same for each family. But what if that element was never visited again, will it ever occupy a seat? Therefore, each family has provided a regular way of active deletion. Redis

Code in the REDIS.C of Activeexpirecycle (), the people who read the document know that it will be in the main thread, every 100 milliseconds to execute, each random 20 key checks, if 1/4 of the key expired, it is possible to expire at this time the key may be more than 100 milliseconds, Start the next round of inspections immediately. However, to avoid the CPU time is accounted for, but also limit the total execution time of each round not more than 1 milliseconds. Memcached

Memcached has a irrelevant LRU crawler thread that leverages the previous LRU queue and can be set to run once (by default, 100 milliseconds), checking the past along the Lieli, checking the n data in the LRU queue every time. Although the expiration time of each key setting may not be the same, but how to say the hit rate is also better than the Redis random selection of n data, but it does not have the redis kind of expired more immediately to expand the next round of checking the function, so every second can only check the 10N of data, you need to weigh their own n settings. Guava Cache

In the guava cache, the expiration time for all elements in the same cache is the same, so it is more convenient than memached, which follows the previous LRU queue check timeout, without qualifying the number until it expires. And the timing of this check is not 100 milliseconds, but it is called every time the Prewritecleanup () method is written to the data.

Spit trough a sentence, guava of the LocalCache class inside already 4872 line, a little is not light quantity. Ehcache

Ehcache more chaotic, first of all its memory storage only lazy check, no active check expired, will only be in memory over time with the approximate LRU algorithm (see above) to the memory of the elements to the disk, in the file store has a timeout to check the thread, the FAQ specifically explains why.

Then the disk storage there is a thread that runs around 8 hours at a time, traversing all the elements at once .... See the Diskexpirytask in Diskstoragefactory. One lap to look down, the Ehcache is the weakest.

The article continues to revise, when reproduced please retain the original link: http://calvin1978.blogcn.com/articles/lru.html