volatile-lru, volatile-random 和 volatile-ttl 在没有匹配key的时候和 noeviction是一样的 。
To pick the right eviction policy is important depending on the access pattern of your application, however you can reconfigure the policy at runtime while the application is running, and monitor the number of cache misses and hits using the Redis INFO output in order to tune your setup.
依赖于你的应用去选择正确的逐出政策是非常重要的，然而在Redis运行时，你也可以重新配置逐出政策，并且你可以使用INFO命令输出内存使用情况然后重新配置。
In general as a rule of thumb: 一般的配置规则
Use the allkeys-lru policy when you expect a power-law distribution in the popularity of your requests, that is, you expect that a subset of elements will be accessed far more often than the rest. This is a good pick if you are unsure. 使用allkeys-lru，当你希望你的请求是一个 power-law 分布，如此，你期望常驻内存的元素是你可被访问元素的子集。如果你不确定的话，使用allkeys-lru是好的选择。
Use the allkeys-random if you have a cyclic access where all the keys are scanned continuously, or when you expect the distribution to be uniform (all elements likely accessed with the same probability). 如果所有key被周期地访问或者的当逐出分布不统一时（所有元素被访问的概率一样），使用allkeys-random。
Use the volatile-ttl if you want to be able to provide hints to Redis about what are good candidate for expiration by using different TTL values when you create your cache objects. 在创建对象缓存的时候如果你想通过使用TTL的值提供好的逐出候选者，使用volatile-ttl 。
The allkeys-lru and volatile-random policies are mainly useful when you want to use a single instance for both caching and to have a set of persistent keys. However it is usually a better idea to run two Redis instances to solve such a problem.
当你使用一个实例作为缓存并且key都是永久性的时候，使用allkeys-lru和 volatile-random。但是还有更好的做法，可以使用两个Redis实例解决内存不足问题。
It is also worth to note that setting an expire to a key costs memory, so using a policy like allkeys-lru is more memory efficient since there is no need to set an expire for the key to be evicted under memory pressure.
另外注意，设置过期时间是消耗内存的，因此使用像 allkeys-lru 的政策比较有内存效率，因为它不需要去为过期的key的逐出增加额外的内存压力。
How the eviction process works 逐出是这样工作的
It is important to understand that the eviction process works like this:
理解逐出工作方式，就像这样：
A client runs a new command, resulting in more data added. 一个客户端运行一个新的命令，导致更多数据被添加。Redis checks the memory usage, and if it is greater than the maxmemory limit , it evicts keys according to the policy. Redis检测内存使用，如何超过 maxmemory 限制，就根据政策逐出key。
A new command is executed, and so forth. 新的命令被执行。
So we continuously cross the boundaries of the memory limit, by going over it, and then by evicting keys to return back under the limits.
因此我们持续添加数据达到内存限制，通过上面的步骤，逐出一些key使得内存回到限制之下。
If a command results in a lot of memory being used (like a big set intersection stored into a new key) for some time the memory limit can be surpassed by a noticeable amount.
如果命令的结果是导致很大的内存被使用（比如一个新的key是一个大的set集合），很多时候达到内存限制是显而易见的。?
Approximated LRU algorithm 近似的LRU算法
Redis LRU algorithm is not an exact implementation. This means that Redis is not able to pick the best candidate for eviction, that is, the access that was accessed the most in the past. Instead it will try to run an approximation of the LRU algorithm, by sampling a small number of keys, and evicting the one that is the best (with the oldest access time) among the sampled keys.Redis的LRU算法不是准确的实现。也就是说Redis没有为逐出选择 最好的候选人 ，也就是没有选择过去最后被访问离现在最久的。反而 是去执行一个 近似LRU的算法，通过抽样少量的key，并且逐出抽样中最后被访问离现在最久的key（最老的访问时间）。
However since Redis 3.0 (that is currently in beta) the algorithm was improved to also take a pool of good candidates for eviction