当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)。交换会让 Redis 的性能急剧降低，对于访问量比较频繁的 Redis 来讲，这样龟速的存取效率基本上等于不可用。算法
在生产环境中咱们是不容许 Redis 出现交换行为的，为了限制最大使用内存，Redis 提供了配置参数 maxmemory 来限制内存超出指望大小。缓存
当实际内存超出 maxmemory 时，Redis 提供了几种可选策略 (maxmemory-policy) 来让用户本身决定该如何腾出新的空间以继续提供读写服务。dom
noeviction 不会继续服务写请求 (DEL 请求能够继续服务)，读请求能够继续进行。这样能够保证不会丢失数据，可是会让线上的业务不能持续进行。这是默认的淘汰策略。性能
volatile-lru 尝试淘汰设置了过时时间的 key，最少使用的 key 优先被淘汰。没有设置过时时间的 key 不会被淘汰，这样能够保证须要持久化的数据不会忽然丢失。淘汰最近最少使用的key对象
volatile-ttl 跟上面同样，除了淘汰的策略不是 LRU，而是 key 的剩余寿命 ttl 的值，ttl 越小越优先被淘汰。内存
volatile-random 跟上面同样，不过淘汰的 key 是过时 key 集合中随机的 key。淘汰随机的key数据io
allkeys-lru 区别于 volatile-lru，这个策略要淘汰的 key 对象是全体的 key 集合，而不仅是过时的 key 集合。这意味着没有设置过时时间的 key 也会被淘汰。效率
allkeys-random 跟上面同样，不过淘汰的策略是随机的 key。配置
volatile-xxx 策略只会针对带过时时间的 key 进行淘汰，allkeys-xxx 策略会对全部的 key 进行淘汰。若是你只是拿 Redis 作缓存，那应该使用 allkeys-xxx，客户端写缓存时没必要携带过时时间。若是你还想同时使用 Redis 的持久化功能，那就使用 volatile-xxx 策略，这样能够保留没有设置过时时间的 key，它们是永久的 key 不会被 LRU 算法淘汰。请求
设置缓存的最大内存+ 淘汰策略:
maxmemory <bytes> maxmemory-policy noeviction