目录
设置多大的缓存容量合适？
长尾效应
重尾效应
电商商品的例子
最佳实践
Redis 缓存有哪些淘汰策略？
LRU 算法
Redis 中的LRU 算法
优势
如何处理被淘汰的数据？
什么是脏数据呢？
淘汰策略使用场景
业务数据中有明显的冷 热数据区分
数据访问频率相差不大，没有明显的冷热数据区分
业务中有置顶的需求
数据访问都是有局部性的，也就是我们通常所说的“八二原理”，80% 的请求实际只访问了 20% 的数据。所以，用 1TB 的内存做缓存，并没有必要。
缓存数据的淘汰机制。简单来说，数据淘汰机制包括两步：第一，根据一定的策略，筛选出对应用访问来说“不重要”的数 据；第二，将这些数据从缓存中删除，为新来的数据腾出空间，
设置多大的缓存容量合适？
红、蓝两条线，显示了不同比例数据贡献的访问量情况。
- 蓝线代表了“八二原理”表示的数据局部性
- 红线则表示在当前应用负载下，数据局部性的变化。
?
长尾效应
蓝线。它表示的就是“八二原理”，有 20% 的数据贡献了 80% 的访问了，而
剩余的数据虽然体量很大，但只贡献了 20% 的访问量。这 80% 的数据在访问量上就形成了一条长长的尾巴
重尾效应
在这条红线上，80% 的数据贡献的访问量，超过了传统的长尾效应中 80% 数据能贡献的访问量。原因在于，用户的个性化需求越来越多，在一个业务应用中，不同用户访问的内容可能差别很大，所以，用户请求的数据和它们贡献的访问量比例，不再具备长尾效应中的“八二原理”分布特征了。
20% 的数据可能贡献不了 80% 的访问，而剩余的 80% 数据反而贡献了更多的访问量
电商商品的例子
在商品促销时，热门商品的信息可能只占到总商品数据信息量的 5%，而这些商品信息承载的可能是超过 90% 的访问请求。
这时，我们只要缓存这 5% 的数据，就能获得很好的性能收益。
另一方面，如果业务应用要对所有商品信息进行查询统计，这时候，即使按照“八二原理”缓 存了 20% 的商品数据，也不能获得很好的访问性能，因为 80% 的数据仍然需要从后端数据库中获取。
最佳实践
设置为总数据量的 15% 到 30%，兼顾访问性能和内存空间开销。
为redis节点设置最大缓存大小
CONFIG SET maxmemory 4gbRedis 缓存有哪些淘汰策略？
redis4.0 之前有6 种内存淘汰策略，在 4.0 之后，又增加了 2 种策略。
按照是否会进行数据淘汰把它们分成两类：
- 不进行数据淘汰的策略，只有 noeviction 这一种
- 会进行淘汰的 7 种其他策略。
会进行淘汰的 7 种策略，我们可以再进一步根据淘汰候选数据集的范围把它们分成两类：
- 在设置了过期时间的数据中进行淘汰，包括 volatile-random、volatile-ttl、volatile- lru、volatile-lfu四种。
其中 volatile-lfu为（Redis 4.0 后新增）
- 在所有数据范围内进行淘汰，包括 allkeys-lru、allkeys-random、allkeys-lfu（Redis4.0 后新增）三种。
?
使用如下命令查看淘汰策略
127.0.0.1:6386> config get maxmemory-policy
1) "maxmemory-policy"
2) "volatile-lru"
- noeviction ： 一旦缓存被写满了，再有写请求来时，Redis 不再提供服务，而是直接返回错误
- volatile-ttl ：在筛选时，会针对设置了过期时间的键值对，根据过期时间的先后进行删除，越早过期的越先被删除。
- volatile-random： 就像它的名称一样，在设置了过期时间的键值对中，进行随机删除。volatile-lru 会使用 LRU 算法筛选设置了过期时间的键值对。
- volatile-lfu： 会使用 LFU 算法选择设置了过期时间的键值对。
- volatile-lru :会使用 LRU 算法筛选设置了过期时间的键值对。
- allkeys-random :从所有键值对中随机选择并删除数据；
- allkeys-lru ：使用 LRU 算法在所有数据中进行筛选。
- allkeys-lfu ：使用 LFU 算法在所有数据中进行筛选。
LRU 算法
LRU 算法的全称是 Least Recently Used，从名字上就可以看出，这是按照最近最少使用的原则来筛选数据
LRU 会把所有的数据组织成一个链表，链表的头和尾分别表示MRU 端和 LRU 端，分别代表最近最常使用的数据和最近最不常用的数据。
?
现在有数据 6、3、9、20、5。如果数据 20 和 3 被先后访问，它们都会从现有的链表位置移到 MRU 端，而链表中在它们之前的数据则相应地往后移一位。因为，LRU 算法选择删除数据时，都是从 LRU 端开始，所以把刚刚被访问的数据移到 MRU 端，就可以让它们尽可能地留在缓存中。
如果有一个新数据 15 要被写入缓存，但此时已经没有缓存空间了，也就是链表没有空余位置了，那么，LRU 算法做两件事：
- 数据 15 是刚被访问的，所以它会被放到 MRU 端；
- 算法把 LRU 端的数据 5 从缓存中删除，相应的链表中就没有数据 5 的记录了。
其实，LRU 算法背后的想法非常朴素：它认为刚刚被访问的数据，肯定还会被再次访问， 所以就把它放在 MRU 端；长久不访问的数据，肯定就不会再被访问了，所以就让它逐渐后移到 LRU 端，在缓存满时，就优先删除它。
不过，LRU 算法在实际实现时，需要用链表管理所有的缓存数据，这会带来额外的空间开销。而且，当有数据被访问时，需要在链表上把该数据移动到 MRU 端，如果有大量数据被访问，就会带来很多链表移动操作，会很耗时，进而会降低 Redis 缓存性能。
Redis 中的LRU 算法
为了减轻数据淘汰对缓存性能的影响。在 Redis 中，LRU 算法被做了简化。
Redis 默认会记录每个数据的最近一次访问的时间戳（由键值对数据结构RedisObject 中的 lru 字段记录）。
然后，Redis 在决定淘汰的数据时，第一次会随机选出N 个数据，把它们作为一个候选集合。接下来，Redis 会比较这 N 个数据的 lru 字段，把lru 字段值最小的数据从缓存中淘汰出去。(这里比较的时间戳，小代表时间早)
配置参数 maxmemory-samples 来觉得N
?
能进入候选集合的数据的 lru 字段值必须小于候选集合中最小的 lru 值(较久为被访问的数据)
有新数据进入候选数据集后，如果候选数据集中的数据个数达到了 maxmemory- samples，Redis 就把候选数据集中 lru 字段值最小的数据淘汰出去。
优势
Redis 缓存不用为所有的数据维护一个大链表，也不用在每次数据访问时都移动链表项，提升了缓存的性能。
如何处理被淘汰的数据？
这里主要讨论对脏数据的处理
?
什么是脏数据呢？
和最初从后端数据库里读取时的值相比，有被修改过。和最初从后端数据库里读取时的值相比，有没有被修改过
即使淘汰的数据是脏数据，Redis 也不会把它们写回数据库。所以，我们在使用 Redis 缓存时，如果数据被修改了，需要在数据修改时就将它写回数据库。
淘汰策略使用场景
业务数据中有明显的冷 热数据区分
优先使用 allkeys-lru 策略。
这样，可以充分利用 LRU 这一经典缓存算法的优势，把最近最常访问的数据留在缓存中，提升应用的访问性能。
数据访问频率相差不大，没有明显的冷热数据区分
使用allkeys-random 策略
业务中有置顶的需求
比如置顶新闻、置顶视频
使用 volatile-lru 策略，同时不给这些置顶数据设置过期时间。这样一来，这些需要置顶的数据一直不会被删除，根据 LRU 规则进行筛选删除。(不管是否有过期时间)
?