前言
MySQL 中有 1TB 的数据，如果我们使用 Redis 把这 1TB 的数据都缓存起来，但是实际业务场景数据访问都是有局部性的，也就是我们通常所说的“八二原理”，80% 的请求实际只访问了 20% 的数据。
为了保证较高的性价比，缓存的空间容量必然要小于后端数据库的数据总量。不过内存
大小毕竟有限，随着要缓存的数据量越来越大，有限的缓存空间不可避免地会被写满的风险。
Redis缓存数据淘汰分类
noeviction：当内存使用超过配置的时候会返回错误，不会驱逐任何键
volatile-ttl：从配置了过期时间的键中驱逐马上就要过期的键
volatile-random：加入键的时候如果过限，从过期键的集合中随机驱逐
volatile-lru：加入键的时候如果过限，首先从设置了过期时间的键集合中驱逐最久没有使用的键
volatile-lfu：从所有配置了过期时间的键中驱逐使用频率最少的键
allkeys-random 策略，从所有键值对中随机选择并删除数据
allkeys-lru 策略，使用 LRU 算法在所有数据中进行筛选
allkeys-lfu 策略，使用 LFU 算法在所有数据中进行筛选
volatile-lru 和 allkeys-lru 策略都用到的算法
如果现在有数据 6、3、9、20、5
有一个新数据 15 要被写入缓存，但此时已经没有缓存空间了，也就是链表没有空余位 置了，那么，LRU 算法做两件事:
1.数据 15 是刚被访问的，所以它会被放到 MRU 端;
- 算法把 LRU 端的数据 5 从缓存中删除，相应的链表中就没有数据 5 的记录了
其实，LRU 算法背后的想法非常朴素:它认为刚刚被访问的数据，肯定还会被再次访问， 所以就把它放在 MRU 端;长久不访问的数据，肯定就不会再被访问了，所以就让它逐渐 后移到 LRU 端，在缓存满时，就优先删除它。
LRU 算法在实际实现时，需要用链表管理所有的缓存数据，这会带来额外的空间开销。而且当有数据被访问时，需要在链表上把该数据移动到 MRU 端，如果有大量数据被访问就会带来很多链表移动操作，会很耗时进而会降低 Redis 缓存性能。
Redis 默认会记录每个数据的最近一次访问的时间戳(由键值对数据结构 RedisObject 中的 lru 字段记录)。然后，Redis 在决定淘汰的数据时，第一次会随机选出 N 个数据，把它们作为一个候选集合。接下来Redis 会比较这 N 个数据的 lru 字段，把 lru 字段值最小的数据从缓存中淘汰出去。
Redis 提供了一个配置参数 maxmemory-samples，这个参数就是 Redis 选出的数据个数 N。
内存淘汰策略建议
优先使用 allkeys-lru 策略。这样可以充分利用 LRU 这一经典缓存算法的优势，把最近最常访问的数据留在缓存中，提升应用的访问性能。如果你的业务数据中有明显的冷热数据区分，我建议你使用 allkeys-lru 策略。
如果业务应用中的数据访问频率相差不大，没有明显的冷热数据区分，建议使用 allkeys-random 策略，随机选择淘汰的数据就行。
如果你的业务中有置顶的需求，比如置顶新闻、置顶视频，那么，可以使用 volatile-lru策略，同时不给这些置顶数据设置过期时间。这样一来，这些需要置顶的数据一直不会被删除，而其他数据会在过期时根据 LRU 规则进行筛选。
获取redis实例内存最大使用值
config get maxmemory
获取redis内存淘汰机制配置
config get maxmemory-policy
