3、 节点与节点之间通过二进制协议进行通信

        4、数据按照 Slot 存储分布在多个 Redis 实例上

 

        5、集群节点挂掉会自动故障转移

        6、可以相对平滑扩/ 缩容节点

四、如果有大量的key需要设置同一时间过期，需要注意什么

        如果有大量的 key 在同一时间过期，那么可能同一秒都从数据库获取数据，给数据库造成很大的压力，导致数据库崩溃，系统出现 502 问题。也有可能同时失效，那一刻不用都访问数据库，压力不够大的话，那么 Redis 会出现短暂的卡顿问题。所以为了预防这种问题的发生，最好给 数据的过期 时间加一个随机值，让过期时间更加分散。

五、缓存和数据库的读写一致性问题

        这里比较简单的方法就是当一个更新请求过来的时候，先删除缓存数据，再更新数据库，最后再更新缓存。

        写请求删除缓存成功，则更新数据库，如果更新数据库失败，则直接返回，写请求结束，此 时数据库中的值依旧是旧值，读请求过来后，发现缓存中没有数据， 则会直接向数据库中请求， 同时将数据写入到缓存中，此时也不会出现数据一致性的问题。

        更新数据成功之后，再更新缓存，如果此时更新缓存失败，则缓存中没有数据，数据库中是 新值，写请求结束，此时读请求还是一样，发现缓存中没有数据，同样会从数据库中读取数据， 并且存入到缓存中，其实这里不管更新缓存成功还是失败，都不会出现数据一致性的问题。

       以上其实没啥问题，问题在于，如果一个更新请求还没有结束，比如刚删了缓存，读请求进来了，此时数据库还没有更新，那么读取的就是老的数据，这就要看是否容忍这种问题。如果不能容忍那么就必须要针对同id数据的读写请求进行排队，写请求进来先进入队列，读请求排在后面等写请求完成了，再处理读请求。

六、缓存雪崩、缓存穿透、缓存预热

缓存雪崩

        缓存雪崩就是大量的key在同一时间过期，此时大部分请求都打到了数据库上，造成了数据库CPU和内存的压力过大可能成为数据库宕机，此时会造成更大面积的系统瘫痪，就好像雪崩一样。

        解决的方法第一种就是在读数据的时候先加一层锁，比如redis的分布式锁，只让一个请求进入数据库去查询。第二种方法就是尽量不让大量的key在同一时间过期，比如过期时间上增加一个随机时间；

缓存穿透

        缓存穿透就是指查询一个在缓存中不存在的key，由于不存在会去查询数据库，如果大量的查询不存在的key，还是会对数据库造成大量的压力。

        解决的方法第一种是如果发现数据库中不存在的key，也在redis中缓存一份，过期时间5分钟，这样5分种内同样的key查询就不会进入数据库了；第二种方式是使用布隆过滤器，这需要将所有可能的数据都存到了一个足够大的bitmap中，通过布隆过滤器可以确定请求的key是否合法；

缓存预热

七、过期策略以及内存淘汰机制

过期策略        

        针对Key过期的情况，redis采用了定期删除配合惰性删除的策略；

        定期删除：每个100ms检查过期的key，如果由过期的key就删除，但每次不是全量的检查，而是随机抽取进行检查，比如抽取100个，发现其中由20个过期了，就把这20个key删除掉。如果过期 key 的占比超过可接受的过期 key 的百分比（比如20%），则重复删除的过程，直到过期key的比例降至可接受的过期 key 的百分比以下。

        惰性删除：惰性删除是指当客户端请求某个key的时候，会检查这个key是否过期，如果过期了就删除掉；

 内存淘汰机制      

        内存总会有用完的时候，如果内存已经占满了，怎么办呢？这就需要淘汰一部分的key，那么怎么淘汰呢？     

8种内存淘汰策略

1.noeviction（默认策略）： 不会删除任何数据，拒绝所有写入操作并返回客户端错误消息（error）OOM command not allowed when used memory，此时 Redis 只响应删和读操作；

2.allkeys-lru： 从所有 key 中使用 LRU 算法进行淘汰（LRU 算法：最近最少使用算法）；

3.allkeys-lfu： 从所有 key 中使用 LFU 算法进行淘汰（LFU 算法：最不常用算法，根据使用频率计算，4.0 版本新增）；

4.volatile-lru： 从设置了过期时间的 key 中使用 LRU 算法进行淘汰；

5.volatile-lfu： 从设置了过期时间的 key 中使用 LFU 算法进行淘汰；

6.allkeys-random： 从所有 key 中随机淘汰数据；

7.volatile-random： 从设置了过期时间的 key 中随机淘汰数据；

8.volatile-ttl： 在设置了过期时间的key中，淘汰过期时间剩余最短的。

注意： 当使用 volatile-lru、volatile-lfu、volatile-random、volatile-ttl 这四种淘汰策略时，如果没有 key 可以淘汰，则和 neoviction 一样返回错误。

怎么选择淘汰策略

一般根据经验来说：

使用 allkeys-lru 策略场景：

        1.当你期望元素的子集将比其他元素更频繁地被访问时，比如幂律分布，20%的数据占有80%的使用次数；

        2.当你不确定使用哪种策略时。

使用 allkeys-random 策略场景：

        1.当你有一个循环访问，其中所有 key 进行会被连续地访问；

        2.当你希望所有 key 的分布比较均匀。

使用 volatile-ttl 策略场景：

        1.当你大部分缓存都设有不同的 ttl 值，向 Redis 提供过期候选的提示时。

八、Redis的数据类型及使用场景

1、字符串

        String类型是一种最基本的数据类型，它是一个键值对的存储结构，其中键和值都是字符串类型。String类型的特点是快速存储和读取，适用于存储一些简单的数据，如字符串、整数或浮点数等。        

使用场景

• 缓存：经典使用场景，把常用信息，字符串，图片或者视频等信息放到Redis中，Redis作为缓存层，MySQL做持久化层，降低MySQL的读写压力
• 计数器：Redis是单线程模型，一个命令执行完才会执行下一个，同时数据可以一步落地到其他的数据源。
• Session：常见方案Spring Session + Redis实现Session共享。

2、List

        列表是简单的字符串列表，按照插入顺序排序，底层是双向列表（压缩列表），一种快速、高效、可靠的数据存储结构，适用于实现队列、栈等常见的数据结构。

• 消息队列:List类型的lpop和rpush(或者反过来,lpush和rpop）能实现队列的功能，故而可以用Redis的List类型实现简单的点对点的消息队列。

• 排行榜:List类型的range命令可以分页查看队列中的数据，但是只有顶式计算的排行榜才适合使用List类型存储。

• 最新列表:List类型的lpush命令和range命令能实现最新列表的功能.每次通过lpush的命令往列表里插入新的元素,然后通过lrange命令读取最新元素列表,如朋友圈的点赞列表、评论列表。

3、Set

        Set对外提供的功能与List类似是一个列表的功能，特殊之处在于Set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，Set是一个很好的选择，并且Set提供了判断某个成员是否在一个Set集合内的重要接口，这个也是List所不能提供的。Redis的Set是String类型的无序集合。它底层其实是一个Value为Null的Hash表，所以添加，删除，查找的复杂度都是O(1)

• 推荐：通过sinter命令计算交集,比如美团给你推荐附近外卖时就可以根据你的外卖记录与附近商家计算交集推送安全提示：
• 集合保存：微信群成员保存在一个set中,用户好友也保存在Set中。当用户加入群聊时可以提醒非好友用户注意安全

4、Hash

        hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。

• 结构化存储场景：一个hash结构中存储某个商品所有sku

5、ZSet（sortedSet）

        Zset与普通集合Set非常相似，是一个没有重复元素的字符串集合。不同之处是有序集合的每个成员都关联了一个评分（score）,这个评分（score）被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的，但是评分是可以重复的 。因为元素是有序的, 所以你也可以很快的根据评分（score）或者次序（position）来获取一个范围的元素。访问有序集合的中间元素也是非常快的,因此你能够使用有序集合作为一个没有重复成员的智能列表。

        排行榜：一个销量排行榜,就可以使用店家的订单做score,这个查询出来的结果就是有序的权重队列：score作为优先级,这样取出来的数据权重都是最大优先执行的

        延时任务：score作为任务启动执行时间,取值时判断该值执行即可。

        

 参考：

Redis学习（六）8种内存淘汰机制_redis淘汰策略-CSDN博客

redis的过期键删除策略_redis过期键删除策略-CSDN博客