提到 Redis，也许大家第一印象是：高性能的 K-V 缓存。其除了缓存业务上的热点数据还能做队列以及分布式锁。可大部分的我们在使用的时候也许都是公司封装好的 Redis，对于整个 Redis 的集群以及内部核心实现一知半解。只专注业务开发，那久而久之，在个人成长上变得帮组甚少。最明显的就是当业务量级上来后，在极端情况下，许多问题暴露出来，如果没有对 Redis 的底层有深入的了解，很难快速定位并解决问题

Redis 基础数据结构

• string

• Redis 里的 Redis 的字符串是动态字符串，是可以修改的。类似于 Go 里面的切片 Silence，如果长度不够则自动扩容，至于如何扩容：length 小于 1M 的时候，扩容规则讲目前的字符串翻倍；如果大雨 1M 的话，则每次只会扩容 1M，直到 512M。

• 
  

• list

• Redis 里的 list 是一个链表，由于链表本身插入和删除比较块，但是查询的效率比较低，所以常常被用于做异步队列

• Redis 里的 List 设计非常牛逼，当数据量比较小的时候，数据结构是压缩链表，如果数据量比较多的时候就是快速链表

• 可运用场景：异步队列，使用 rpush/lpush 操作队列，使用 lpop 和 rpop 出队列

• 
  

• set

• Redis 中的 set 是一个无序 Map，由于 Go 中没有 set 结构，所以这里只能类比 Java 中的 HashSet。set 底层也是一个 Map 结构，只是里面的 Value 是一个 NULL，由于 set 的特性可以用于去重逻辑

• 可运用场景：活动抽奖去重

• hash

• Redis 中的字典类型大家不陌生，也许其他语言都有这种结构，不同的稍微提一点就是 hash 的扩容 rehash 过程中和 Go 里面的设计颇有类似，就是维护了两个 hash 结构，如果需要扩容的时候，就把新的数据写入新字典中，然后后端起一个线程来逐步迁移，总体上来说就是采用了空间换时间的思想

• 可运用场景：记录业务中的不同用户/不同商品/不同场景的信息：如某个用户的名称，或者用户的历史行为

• zset

• Redis 中的 zset 是一个比较特殊的数据结构（跳跃列表），也就是我们了解到的跳表，底层由于 set 的特性保证了 value 唯一，同时也给了 value 一个得分，所谓的有序就是根据这个的得分排序。

• 至于跳跃表如何插入，其实内部采用了一个随机策略：L0:100%-L2:50%-L3:25%-....Ln:(n-1)value/2%

• 可运用场景：榜单，总榜，热榜

• 
  

Redis 进阶使用

布隆过滤器

redis 在 4.0 以后支持布隆过滤，给 Redis 提供了强大的去重功能。在业务中，我们可能需要查询数据库判断历史数据是否存在，数据库的并发能力有限，这个时候我们采用了 Redis 中的 set 去做去重，这个时候如果缓存的数据过大，这个时候就需要遍历所以缓存数据，另外如果我们的历史数据缓存写不下，终究要去查询数据库，这个时候我们就可以使用布隆过滤器。当然布隆过滤器精确度不是 100%准确，对于存在的数据也许这个值不一定存在。当然如果不存在肯定 100%不存在了。

命令使用

bf.add #添加元素
bf.exists #判断元素是否存在
bf.madd #批量添加
bf.mexists #批量判断是否存在

原理

布隆过滤的组成可以当作一个位数组和几个无偏的 hash 函数（计算的 hash 比较均匀），每次添加 key 的时候，会把 key 通过多次 hash 来计算所的到的位置，如果当前位置不是 0 则表示存在，这也正式它的不准确性。

分布式锁

也许不陌生，现在主流实现分布锁的可以使用 ZK 或者 Redis；本文就简单的介绍一下 Redis 实现分布式锁；

命令

setnx lock:mutex ture #加锁del  lock:mutex #删除锁

实现锁的核心就是请求的时候占用这个 key，如果其他请求设置失败的时候，即拿不到锁，但是存在一个问题就是如果业务 panic 或者忘记调用 del 的话，这样就会产生死锁了；这个时候大家很容易想到我们可以 expire 一个过期时间，这样就可以保证请求不会一直独占锁并无法释放锁的逻辑；但是业务存在一种情况就是 A 请求在获取锁后，处理逻辑，由于逻辑过长，这个时候锁到期释放了，A 这个时候刚刚处理完成，而 B 又去改这个数据，这就存在一个锁失效的问题，解决这种问题参考了 CAS 的方式，对锁设置一个随机数可以理解为版本号，如果释放的时候版本号不一致的时候，则表示数字已经在释放那一刻改掉了。

深入原理

IO 模型

Redis 是单线程模型（这里的单线程指的是 IO 和键值对的读写是一个线程完成的），当然如果严谨的说以多线程，之所以多线程不过是在数据备份的时候会 fork 一个子进程对数据进行从磁盘读取数据并组装 RDB，然后同步给 slaver 节点。问题来了，单线程的模型能这么快？原因很简单 Redis 本身就是在内存运算，而对于上游的客户端请求，采用了多路复用的原理。Redis 会给每一个客户端端套接字都关联一个指令队列。客户端的指令队列通过队列排队来进行顺序处理。同时 Reids 给米一个客户端的套件字关联一个响应队列。Redis 服务器通过响应队列来将指令的接口返回回复给客户端。

Redis IO 处理模型

通信协议

Redis 采用了 Gossip 协议作为通信协议。Gossip 是一种传播消息的方式，灵感来自于：瘟疫、社交网络等。使用 Gossip 协议的有：Redis Cluster、Consul、Apache Cassandra 等。简单点意思就是类似病毒扩散的方式一样，将信息传播到其他的节点，这种协议效率很高，只需要广播到附件到节点，然后被广播的节点继续做同样的操作即可。当然这种协议也有一个弊端就是：存在浪费。

持久化

RDB

对当前 Redis 的存储数据进行一次快照（具体如何做和原理，这里不做过多复述）

AOF

日志只记录 Redis 对内存修改的指令记录；Redis 提供了一个 bgrewriteaif 的指令对 AOF 进行压缩，原理就是开辟一个子进程对内存进行遍历后转换成一系列对 Redis 的操作指令，序列化到一个新的 AOF 的日志文件中。系列化完成后再将发送的增量的 AOF 日志追加到这个新的 AOF 的日志中，追加完成后用新的 AOF 日志代替旧的

混合持久化

Redis 大概是 4.0 之后，采用混合持久化，也就是每次启动时候通过 RDB+增量的 AOF 文件来进行回复；由于增量的 AOF 仅记录了开始持久化到持久化结束期间发生的增量，这样日志不会太大，性能相对较高

主从同步

Redis 的同步方式：主从同步；从从同步（由于全部都由 master 同步的化，会损耗性能，所部分的 slave 会通过 slave 之间进行同步）

同步过程

• 建立连接，然后从库告诉主库我要同步啦，你给我准备好，然后主库和从库说知道了知道了。

• 从库拿到数据了，然后要把他保存到库里。这个时候就会在本地完成数据的加载，这个时候会用到 RDB

• 主库把新来的数据，AOF 同步给从库

也许有人会提问到如果在同步的时候主挂了或者从挂了，这样怎么办，其实上图主里面维护了一个环形的缓冲区，会记录主写的位置和从读的位置，如果从同步时候挂了，这个时候环形换从区就不会更新，再次重新同步。另外这个缓冲区会进行持久化。

Sentinel

Redis 的主从切换通过哨兵来解决。这里哨兵主要解决的就是当主挂了的情况下，如果在短时间内重新选举出一个新的主。

Sentinel 集群是一个 3-5 个节点组成的集群，监听整个 redis 的集群，如果 master 发现不可用的时候，则会关闭全部与主的旧的链接，并断开。这个时候 sentinel 会完成选举和故障转移。新的请求则会到新到 master 中。

Redis 集群工作原理

Redis 集群通过槽指派机制来决定写命令应该被分配到那个节点。整个集群对应的槽是由 16384 大小的二进制数组组成，集群中每个主节点分配一部分槽，每条写命令落到二级制数组中的某个位置，该位置被分配给了那个节点则对应的命令就由该节点去执行。槽指派对应的二进制数组如下图所示：

从上图可以看到节点 1 执行 0 - 4999，节点 2 执行 5000 - 9999，节点 3 执行 9999- 16383， set key1 value1 命令通过 CRC16(key1) & 16383 = 8876，即认为该命令最后落到二级制数组的 8876 位置，则该命令最终由节点 2 执行。在比如在节点 2 执行一条命令时，假设通过 CRC 计算后得到的值为 589，则其应该有节点 1 执行，此时命令会发生一个转向操作，将要执行的命令转向到节点 1 上去执行。

集群中每个主节点都会定时发送信息到其他主节点，如果其他主节点在规定时间内响应了发送消息的主节点，则发送消息的主节点认为响应了消息的这些主节点在正常工作，反之则认为响应消息的主节点疑似下线，则发送消息的主节点在其节点上将其标记疑似下线；当集群中超过半数的节点认为某个主节点被标记为疑似下线，则其中某个主节点将疑似下线节点标记为下线状态，并向集群广播一条下线消息，当下线节点对应的从节点接收到该消息时，则从从节点中选举出一个节点作为主节点继续对外提供服务。

Redis 为什么变慢了

业务场景中，不知道是否碰到过 Redis 变慢的情况：

• 执行 SET、DEL 命令耗时也很久

• 偶现卡顿，之后又恢复正常了

• 在某个时间点开始变慢了

原因分析

查看慢查询，由于我本身机器没有慢查询，所以这里看到是空

• 由于 Redis 在 IO 操作和对键值对的操作是单线程的，所以在执行的 Redis 命令有可能会导致操作延迟变大：

• 经常使用 O(N) 以上复杂度的命令，，所以使用复杂的命令会对 redis 的处理变慢，以及 CPU 过高，例如 SORT、SUNION、ZUNIONSTORE 聚合类命令

• 查询的数据量过大，更多时间花费在数据协议的组装和网络传输过程中。

• 大 key

• 比如一个很大的 hash，一个很大的 zset 这都是经常出现的。这样的对象对 Redis 的集群数据迁移带来了很大的问题，因为在集群环境下，如果某个 key 太大，会数据导致迁移卡顿。

• 另外在内存分配上，如果一个 key 太大，那么当它需要扩容时，会一次性申请更大的一块内存，这也会导致卡顿。如果这个大 key 被删除，内存会一次性回收，卡顿现象会再一次产生。

• 集中过期，变慢的时间统一，每间隔多久就会发生一波延迟

• 内存使用达到上限，当内存达到内存上限的时候，就不许淘汰一些数据，这个时候也可能导致 Redis 查询效率低；具体淘汰策略如下：

1. allkeys-lru：不管 key 是否设置了过期，淘汰最近最少访问的 key

2. volatile-lru：只淘汰最近最少访问、并设置了过期时间的 key

3. allkeys-random：不管 key 是否设置了过期，随机淘汰 key

4. volatile-random：只随机淘汰设置了过期时间的 key

5. allkeys-ttl：不管 key 是否设置了过期，淘汰即将过期的 key

6. noeviction：不淘汰任何 key，实例内存达到 maxmeory 后，再写入新数据直接返回错误

7. allkeys-lfu：不管 key 是否设置了过期，淘汰访问频率最低的 key

8. volatile-lfu：只淘汰访问频率最低、并设置了过期时间 key

• 碎片整理，Redis 在 4.0 版本后会自动整理碎片，而在整理碎片的过长中会消耗 CPU 的资源，从而影响了请求得到性能

• 网络带宽，Redis 集群和业务混部，或者并发量过大以及每次返回的数据也很大，网卡带宽跑满的情况导致网络阻塞

• AOF 的频率过高，由于 AOF 需要将全部的写命令同步，如果同步的间隔比较短，也会影响到 Redis 的性能

• Redis 提供了 flushdb 和 flushall 指令，用来清空数据库，这也是极其缓慢的操作。

Redis 安全

• 默认会监听 6379 端口，最好在 Redis 的配置文件中指定监听的 IP 地址，更进一步，还可以增加 Redis 的 ACL 访问控制，对客户指定群组，并限限制用户对数据的读写权限。

• 访问 Redis 尽量走公司代理，由于 Redis 不慎不支持 SSL 的链接，所以走公司代理可以保证我们的安全