《Redis 开发与运维》¶

第 1 章 初识 Redis¶

对于大部分数据库来说，插入行操作的执行速度非常快（插入行只会在硬盘文件末尾进行写入）。不过，对表里面的行进行更新却是一个速度相当慢的操作，因为这种更新除了会引起一次随机读之外，还可能会引起一次随机写。

Redis 数据类型¶

• string(Bitmaps & HyperLogLog)
• hash
• list
• set
• zset

Redis 提供的功能¶

• 键过期
• 发布订阅（消息系统）
• 事务
• 流水线（一批命令一次发送到 Redis，避免网络开销）
• Lua 脚本

Redis 使用场景¶

• 缓存
• 排行榜
• 计数器（视频播放数，商品浏览量）
• 社交（共同好友、粉丝、点赞）
• 消息队列
• 共享 Session
• 限速（如，60s 获取一次手机验证码：redis.set(phoneNum, 1, "EX 60", "NX")）
• 使用哈希类型模拟关系型数据库（优点：用户信息内聚性较强，占用的键较少；缺点：哈希类型是稀疏的，难以做复杂的关系查询。注意：要控制哈希在 ziplist 和 hashtable 两种内部编码的转换，hashtable 会消耗更多的内存）

为什么 Redis 很快？¶

• 内存访问
• C 语言实现
• 单线程架构，避免线程切换与竞态产生的消耗
• I/O 多路复用模型（epoll）

安装软件时，为软件建立软连接是一种好习惯，避免将软件固定在指定版本上，有利于未来软件的版本升级。

Redis 借鉴了 Linux 对于版本号的命名规则：版本号第二位如果是奇数，则为非稳定版本（如 2.7、2.9、3.1），否则为稳定版本（如 2.6、2.8、3.0）

Redis 可执行文件说明¶

启动 Redis 的 3 种方式¶

1. 默认配置(redis-server)
2. 运行配置(redis-server --port 6380)
3. 配置文件(redis-server /opt/redis/redis.conf)

Python 的 redis 高性能扩展是 hiredis，PHP 则是 phpredis。

第 2 章 API 的理解和使用¶

判断键不存在的方法¶

1. exists 返回 0
2. del 返回 0
3. ttl 返回 -2
4. type 返回 none
5. get 返回 nil

设计合理的键名，有助于防止键冲突和项目的可维护性，比较推荐的方式是使用“业务名:对象名:id:[属性]”作为键名。如果键名较长，可以在能描述键含义的前提下适当减少键的长度，从而减少由于键名过长而导致的内存浪费。

列表的四种操作类型¶

列表的使用场景¶

• lpush + lpop = Stack（栈）
• lpush + rpop = Queue（队列）
• lpush + ltrim = Capped Collection（有限集合）
• lpush + brpop = Message Queue（消息队列）

集合的使用场景¶

• sadd = Tagging（标签）
• spop/srandmember = Random item（生成随机数，比如抽奖）
• sadd + sinter= Social Graph（社交需求）

列表、集合、有序集合的异同点¶

Redis 数据结构与内部编码¶

• 字符串
  • int: 8 个字节的长整型
  • embstr: <=39 Byte 的字符串
  • raw: >39 Byte 的字符串
• 哈希
  • ziplist: 当哈希类型元素个数小于 hash-max-ziplist-entries 配置（默认 512 个）、同时所有值都小于 hash-max-ziplist-value 配置（默认 64 字节）时，Redis 会使用 ziplist 作为哈希的内部实现，ziplist 使用更加紧凑的结构实现多个元素的连续存储，所以在 节省内存方面比 hashtable 更加优秀。
  • hashtable: 当哈希类型无法满足 ziplist 的条件时，Redis 会使用 hashtable 作为哈希的内部实现，因为此时 ziplist 的读写效率会下降，而 hashtable 的读写时间复杂度为 \(O(1)\)
• 列表
  • ziplist: 当列表元素个数小于 list-max-ziplist-entries 配置（默认 512 个）、同时每个元素值都小于 list-max-ziplist-value 配置（默认 64 字节）时，Redis 会使用 ziplist 来作为列表的内部实现来减少内存
  • linkedlist: 当无法满足 ziplist 条件时
• 集合
  • intset: 当集合中的元素都是整数且元素个数小于set-maxintset-entries配置（默认 512 个）时，Redis 会选用 intset 来作为集合的内部实现，从而减少内存的使用。
  • hashtable: 无法满足 intset 时
• 有序集合
  • ziplist: 当有序集合的元素个数小于zset-max-ziplistentries配置（默认 128 个），同时每个元素的值都小于zset-max-ziplist-value配置（默认 64 字节）时，Redis 会用 ziplist 来作为有序集合的内部实现来减少内存
  • skiplist: 当无法满足 ziplist 条件时（跳表视频讲解）

Redis 设计内部编码与外部结构有两个好处 ：

1. 改进内部编码而对外部数据结构和命令没有影响
2. 多种内部编码实现可以在不同场景下发挥各自的优势，如 ziplist 比较节省内存，但在列表元素较多的情况下，性能会有所下降，此时 Redis 会根据配置选项将列表类型的内部实现转换为 linkedlist。

可以通过object encoding key命令查询内部编码。

第 3 章 小功能大用处¶

慢查询¶

慢查询配置¶

• slowlog-log-slower-than 执行时间阈值
  • 单位为微秒，默认 10,000，为 0 表示记录所有命令，<0 不记录任何命令
  • 在高并发场景下，需要将该值向下调整
• slowlog-max-len
  • Redis 使用列表结构存储慢查询日志，该参数为列表最大长度
  • 当列表达最大长度时，最早插入的命令会被从列表中移出
  • 可定时将慢查询日志持久化处理，便于排查故障

慢查询命令¶

慢查询日志结构¶

127.0.0.1:6379> slowlog get
1) 1) (integer) 666         # (1)!
   2) (integer) 1456786500  # (2)!
   3) (integer) 11615       # (3)!
   4) 1) "BGREWRITEAOF"     # (4)!
2) 1) (integer) 665
   2) (integer) 1456718400
   3) (integer) 12006
   4) 1) "SETEX"
      2) "video_info_200"
      3) "300"
      4) "2"

1. 日志标识 ID
2. 执行命令时的 时间戳
3. 命令耗时（单位：微秒）
4. 执行命令和参数

Redis Shell¶

redis-cli¶

redis-server¶

redis-server --test-memory 1024 可用于检测当前 OS 是否能稳定分配指定容量内存给 Redis，该命令通常用于压测。

redis-benchmark¶

该命令会对各类数据结构的命令进行测试，并给出性能指标。

• -c(client) 可指定客户端并发数（默认 50）
• -n 指定客户端请求总量（默认 100,000）
• -q 仅显示每秒接收请求数
• -r(random) 随机插入键，以进行基准测试
• -P 每个请求 pipeline 的数据量（默认为 1）
• -k 客户端是否使用keepalive，1 为使用，0 为不使用，默认为 1
• -t 对指定命令进行基准测试，如redis-benchmark -t get,set -q
• --csv 将结果按照 csv 格式输出

Pipeline¶

由于 Redis 是单线程机制，当需要执行多条命令时，网络 I/O 成为了瓶颈，因此 pipeline 可将待执行命令“打包”，通过一次往返即可完成。

需要注意的是，如果 pipeline 数据量过大，将会导致网络阻塞。

事务与 Lua¶

Redis 中，将一组需要一起执行的事务命令放到multi(开始)和exec(结束)之间即可，如果要停止事务，可以使用discard。需要注意的是，Redis 不支持事务的回滚操作（即使事务执行中出现错误，仍然会执行之后的命令），但可以通过 Lua 来实现回滚。

由于 Redis 是单进程的，因此 支持隔离性。

有些应用场景需要在事务之前，确保事务中的key没有被其他客户端修改过，才执行事务，否则不执行（类似乐观锁）。Redis 提供了watch命令来解决这类问题。

Lua 的数据类型：

1. booleans(布尔)
2. numbers(数值)
3. strings(字符串)
4. tables(表格)

在 Redis 中执行 Lua 的方法¶

方式一：eval 脚本内容 key 个数 key 列表 参数列表

方式二：先将 Lua 脚本加载入 Redis，得到该脚本的 SHA1，evalsha使用SHA1执行对应的脚本。这样可以重复批处理。

• 加载脚本：redis-cli script load "$(cat lua_get.lua)"
• 执行脚本：evalsha 脚本 SHA1 值 key 个数 key 列表 参数列表
• 判断脚本是否已经被加载：scripts exists sha1 [sha1 …]，返回存在的脚本个数
• 清除所有脚本：script flush
• 强制终止脚本：script kill。如果当前脚本正在写入，则该命令不会生效，此时要么等待脚本执行结束，要么使用shutdown save停止 Redis 服务

Lua 脚本在 Redis 中是原子执行的，执行过程中不会插入其它命令。

Bitmaps¶

Bitmaps 本身不是一种数据结构，实际上它就是字符串，但是它可以对字符串的位进行操作。

当用户量很大时，使用 bitmaps 存储用户的活跃情况是非常好的一种方案，但活跃用户量较少时则不合理，大多数位都是 0。

HyperLogLog¶

HyperLogLog 并不是一种新的数据结构（实际类型为字符串类型），通过 HyperLogLog 可以利用极小的内存空间完成独立总数的统计，数据集可以是 IP、Email、ID 等。

相比于集合类型，HyperLogLog 内存占用量非常小，但是存在错误率，因此，在数据结构选型时，需要平衡误差与空间占用率。

发布订阅¶

GEO¶

GEO 底层由 zset 实现。

第 4 章 客户端¶

客户端常见异常¶

1. 无法从连接池获取到连接
   1. 连接池设置过小，默认为 8
   2. 客户端未正确使用连接池，如没有进行释放
   3. 存在慢查询操作
   4. Redis 服务造成命令执行过程阻塞
2. 客户端读写超时
   1. 读写时间设置过短
   2. 命令执行时间较长
   3. 网路异常
   4. Redis 自身发生阻塞
3. 客户端连接超时
   1. 超时时间过短
   2. Redis 发生阻塞，tcp-backlog已满，造成新的连接失败
   3. 网络异常
4. 客户端缓冲区异常
   1. 输出缓冲区满
   2. 长时间闲置连接被服务端主动断开
   3. 不正常并发读写
5. Lua 脚本正在执行
   1. 脚本正在执行，且执行时间超过了lua-time-limit，需等待脚本执行完成，或者使用shutdown save关闭 Redis 服务
6. Redis 正在加载持久化文件
7. Redis 使用的内存超过maxmemory配置
8. 客户端连接数过大
   1. 客户端：如果maxclients参数不是很小的话，应用方的客户端连接数基本不会超过maxclients，通常来看是由于应用方对于 Redis 客户端使用不当造成的。此时如果应用方是分布式结构的话，可以通过下线部分应用节点（例如占用连接较多的节点），使得 Redis 的连接数先降下来。从而让绝大部分节点可以正常运行，此时再通过查找程序 bug 或者调整maxclients进行问题的修复。
   2. 服务端：如果此时客户端无法处理，而当前 Redis 为高可用模式（例如 Redis Sentinel 和 Redis Cluster），可以考虑将当前 Redis 做故障转移。

客户端案例分析¶

第 5 章 持久化¶

RDB¶

• save命令：阻塞当前 Redis 服务器，直到 RDB 过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。
• bgsave命令：Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。阻塞只发生在 fork 阶段，一般时间很短。

自动触发场景：

1. 使用 save 相关配置，如save m n。表示 m 秒内数据集存在 n 次修改时，自动触发 bgsave
2. 如果从节点执行全量复制操作，主节点自动执行 bgsave 生成 RDB 文件并发送给从节点
3. 执行debug reload命令重新加载 Redis 时，也会自动触发 save 操作
4. 默认情况下执行shutdown命令时，如果没有开启 AOF 持久化功能则自动执行 bgsave

如果 Redis 加载损坏的 RDB 文件时拒绝启动，此时可以使用 Redis 提供的redis-check-dump工具检测 RDB 文件并获取对应的错误报告。

RDB 的优缺点¶

RDB 的优点：

• RDB 是一个紧凑压缩的二进制文件，代表 Redis 在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每 6 小时执行 bgsave 备份，并把 RDB 文件拷贝到远程机器或者文件系统中（如 HDFS），用于灾难恢复。
• Redis 加载 RDB 恢复数据远远快于 AOF 的方式。

RDB 的缺点：

• RDB 方式数据 无法做到实时持久化/秒级持久化。因为 bgsave 每次运行都要执行 fork 操作创建子进程，属于重量级操作，频繁执行成本过高。
• RDB 文件使用特定二进制格式保存，Redis 版本演进过程中有多个格式的 RDB 版本，存在老版本 Redis 服务无法兼容新版 RDB 格式的问题。

AOF¶

AOF（Append Only File）持久化：以独立日志的方式记录每次写命令(类似于 MySQL 的 Binlog)，重启时再重新执行 AOF 文件中的命令达到恢复数据的目的。目前已经是 Redis 持久化的主流方式。

开启 AOF 功能需要设置配置：appendonly yes，默认不开启。AOF 文件名通过appendfilename，配置设置，默认文件名是appendonly.aof。保存路径同 RDB 持久化方式一致，通过dir配置指定。

AOF 缓冲区同步文件策略(参数appendfsync)

aof 重写过程可通过手动与自动方式触发。手动通过直接调用bgrewriteaof命令，自动方式则根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage的参数确定触发时机。

重启加载¶

Redis 启动时会优先加载 AOF 文件，如果 AOF 不可加载，然后再加载 RDB 文件。其文件加载流程如图：

如果在加载 AOF 文件时发生错误，可以先进行备份，然后采用redis-check-aof --fix命令进行修复，修复后使用diff -u对比数据的差异，找出丢失的数据，有些可以人工修改补全。

AOF 文件可能存在结尾不完整的情况，比如机器突然掉电导致 AOF 尾部文件命令写入不全。Redis 为我们提供了aof-load-truncated配置来兼容这种情况，默认开启。加载 AOF 时，当遇到此问题时会忽略并继续启动，同时打印如下警告日志：

# !!! Warning: short read while loading the AOF file !!!
# !!! Truncating the AOF at offset 397856725 !!!
# AOF loaded anyway because aof-load-truncated is enabled

问题定位与优化¶

fork 操作¶

当 Redis 做 RDB 或 AOF 重写时，对于大多数操作系统来说 fork 是个重量级错误。fork 操作耗时跟进程总内存量息息相关，如果使用虚拟化技术，特别是 Xen 虚拟机，fork 操作会更耗时。

对于高并发 Redis 实例，如果 fork 操作耗时在秒级别将拖慢 Redis 几万条命令执行，对线上应用延迟影响非常明显。正常情况下 fork 耗时应该是每 GB 消耗 20 毫秒左右。可以在info stats统计中查latest_fork_usec指标获取最近一次 fork 操作耗时，单位微秒。

改善 fork 操作的耗时：

1. 优先使用物理机或者高效支持 fork 操作的虚拟化技术，避免使用 Xen。
2. 控制 Redis 实例最大可用内存，fork 耗时跟内存量成正比，线上建议每个 Redis 实例内存控制在 10GB 以内。
3. 合理配置 Linux 内存分配策略，避免物理内存不足导致 fork 失败。
4. 降低 fork 操作的频率，如适度放宽 AOF 自动触发时机，避免不必要的全量复制等。

子进程开销监控和优化¶

CPU¶

• CPU 开销分析。子进程负责把进程内的数据分批写入文件，这个过程属于 CPU 密集操作，通常子进程对单核 CPU 利用率接近 90%.
• CPU 消耗优化。Redis 是 CPU 密集型服务，不要做绑定单核 CPU 操作。由于子进程非常消耗 CPU，会和父进程产生单核资源竞争。
• 不要和其他 CPU 密集型服务部署在一起，造成 CPU 过度竞争。
• 如果部署多个 Redis 实例，尽量保证同一时刻只有一个子进程执行重写工作。

硬盘开销¶

• 不要和其他高硬盘负载的服务部署在一起。如：存储服务、消息队列服务等。
• AOF 重写时会消耗大量硬盘 IO，可以开启配置no-appendfsync-on-rewrite，默认关闭。表示在 AOF 重写期间不做fsync操作。
• 当开启 AOF 功能的 Redis 用于高流量写入场景时，如果使用普通机械磁盘，写入吞吐一般在 100MB/s 左右，这时 Redis 实例的瓶颈主要在 AOF 同步硬盘上。
• 对于单机配置多个 Redis 实例的情况，可以配置不同实例分盘存储 AOF 文件，分摊硬盘写入压力。

⚠️ 配置 no-appendfsync-on-rewrite=yes 时，在极端情况下可能丢失整个 AOF 重写期间的数据，需要根据数据安全性决定是否配置。

AOF 追加阻塞¶

当 Redis 执行fsync同步时，如果系统硬盘繁忙，会造成 Redis 主线程的阻塞。

每当发生 AOF 追加阻塞事件发生时，在info Persistence统计中，aof_delayed_fsync指标会累加，查看这个指标方便定位 AOF 阻塞问题。AOF 同步最多允许 2 秒的延迟，当延迟发生时说明硬盘存在高负载问题，可以通过监控工具如iotop，定位消耗硬盘 IO 资源的进程。

本章总结¶

• RDB 使用一次性生成内存快照的方式，产生的文件紧凑压缩比更高，因此读取 RDB 恢复速度更快。由于每次生成 RDB 开销较大，无法做到实时持久化，一般用于数据冷备和复制传输。
• AOF 通过追加写命令到文件实现持久化，通过appendfsync参数可以控制实时/秒级持久化。因为需要不断追加写命令，所以 AOF 文件体积逐渐变大，需要定期执行重写操作来降低文件体积。
• AOF 重写可以通过auto-aof-rewrite-min-size 和 auto-aof-rewritepercentage参数控制自动触发，也可以使用bgrewriteaof命令手动触发。
• 子进程执行期间使用copy-on-write机制与父进程共享内存，避免内存消耗翻倍。AOF 重写期间还需要维护重写缓冲区，保存新的写入命令避免数据丢失。

第 6 章 复制¶

建立复制¶

配置复制的三种方式

1. 在配置文件中加入slaveof {masterHost} {masterPort} 随 Redis 启动生效。
2. 在redis-server启动命令后加入--slaveof {masterHost} {masterPort} 生效。
3. 直接使用命令slaveof {masterHost} {masterPort}生效。

主从节点复制成功建立后，可以使用info replication命令查看复制相关状态。

断开复制¶

slaveof命令不但可以建立复制，还可以在从节点执行slaveof no one来断开与主节点复制关系。同时，slaveof {newMasterIp} {newMasterPort}还可以实现切主操作，更换主节点。

⚠️ 切主后从节点会清空之前所有的数据，线上人工操作时小心 slaveof 在错误的节点上执行或者指向错误的主节点。

对于数据比较重要的节点，主节点会通过设置requirepass参数进行密码验证，这时所有的客户端访问必须使用auth命令实行校验。

默认情况下，从节点使用slave-read-only=yes配置为只读模式。由于复制只能从主节点到从节点，对于从节点的任何修改主节点都无法感知，修改从节点会造成主从数据不一致。因此建议线上不要修改从节点的只读模式。

Redis 为我们提供了repl-disable-tcp-nodelay参数用于控制是否关闭TCP_NODELAY，默认关闭，说明如下：

• 当关闭时，主节点产生的命令数据无论大小都会及时地发送给从节点，这样主从之间延迟会变小，但增加了网络带宽的消耗。适用于主从之间的网络环境良好的场景，如同机架或同机房部署。
• 当开启时，主节点会合并较小的 TCP 数据包从而节省带宽。默认发送时间间隔取决于 Linux 的内核，一般默认为 40 毫秒。这种配置节省了带宽但增大主从之间的延迟。适用于主从网络环境复杂或带宽紧张的场景，如跨机房部署。

拓扑¶

根据拓扑的复杂性，可分为三种：一主一从、一主多从、树状主从结构。

一主一从¶

当应用写命令并发量较高且需要持久化时，可以只在从节点上开启 AOF，这样既保证数据安全性同时也避免了持久化对主节点的性能干扰。但需要注意的是，当主节点关闭持久化功能时，如果主节点脱机要避免自动重启操作。因为主节点之前没有开启持久化功能自动重启后数据集为空，这时从节点如果继续复制主节点会导致从节点数据也被清空的情况，丧失了持久化的意义。安全的做法是在从节点上执行slaveof no one断开与主节点的复制关系，再重启主节点从而避免这一问题。

一主多从¶

对于写并发量较高的场景，多个从节点会导致主节点写命令的多次发送从而过度消耗网络带宽，同时也加重了主节点的负载影响服务稳定性。

树状主从结构¶

当主节点需要挂载多个从节点时为了避免对主节点的性能干扰，可以采用树状主从结构降低主节点压力。

原理¶

数据同步¶

Redis 在初次复制时，会进行全量复制，之后便会根据主从节点的复制偏移量进行psync增量复制。

psync命令运行需要以下组件支持：

• 主从节点各自复制偏移量。
• 主节点复制积压缓冲区。
• 主节点运行 id。

复制偏移量¶

参与复制的主从节点都会维护自身复制偏移量。主节点在理完写入命令后，会把命令的字节长度做累加记录，统计信息在info relication中的master_repl_offset指标中，从节点会每秒钟上报自身的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量。从节点在接收到主节点发送的命令后，也会累加记录自身的偏移量。统计信息在info relication中的slave_repl_offset指标中。

可以通过主节点的统计信息，计算出master_repl_offset_slave_offset字节量，判断主从节点复制相差的数据量，根据这个差值判定当前复制的健康度。如果主从之间复制偏移量相差较大，则可能是网络延迟或命令阻塞等原因引起。

复制积压缓冲区¶

主节点响应从节点的同步时，不但会把命令发送给从节点，还会写入复制积压缓冲区。由于缓冲区本质上是先进先出的定长队列，所以能实现保存最近已复制数据的功能，用于部分复制和复制命令丢失的数据补救。复制缓冲区相关统计信息保存在主节点的info replication中。

主节点运行 ID¶

每个 Redis 节点启动后都会动态分配一个 40 位的十六进制字符串作为运行 ID。运行 ID 的主要作用是用来唯一识别 Redis 节点，比如从节点保存主节点的运行 ID 识别自己正在复制的是哪个主节点。如果只使用 ip+port 的方式识别主节点，那么主节点重启变更了整体数据集（如替换 RDB/AOF 文件），从节点再基于偏移量复制数据将是不安全的，因此当运行 ID 变化后从节点将做全量复制。可以运行info server命令查看当前节点的运行 ID。

当需要调优一些内存相关配置，例如：hash-max-ziplist-value等，这些配置需要 Redis 重新加载才能优化已存在的数据，这时可以使用debug reload命令重新加载 RDB 并保持运行 ID 不变，从而有效避免不必要的全量复制。

debug reload 命令会阻塞当前 Redis 节点主线程，阻塞期间会生成本地 RDB 快照并清空数据之后再加载 RDB 文件。因此对于大数据量的主节点和无法容忍阻塞的应用场景，谨慎使用。

psync 命令¶

从节点使用psync命令完成部分复制和全量复制功能，命令格式：psync {runId} {offset}

主节点回复+FULLRESYNC {runId} {offset}会触发全量复制，+CONTINUE则触发增量复制。

全量同步 & 增量同步¶

对于从节点开始接收 RDB 快照到接收完成期间，主节点仍然响应读写命令，因此主节点会把这期间写命令数据保存在复制客户端缓冲区内，当从节点加载完 RDB 文件后，主节点再把缓冲区内的数据发送给从节点，保证主从之间数据一致性。如果 RDB 文件过大，超过预设的 timeout，则会终止全量同步，并清除已下载临时文件。如果在高并发写的场景，主节点的缓冲区被写满，同样会导致同步的失败。

全量复制的主要时间开销在：

• 主节点 bgsave 时间
• RDB 文件网络传输时间
• 从节点清空数据时间
• 从节点加载 RDB 时间
• 可能的 AOF 重写时间

心跳¶

主从心跳判断机制：

• 通过client list命令查看复制相关客户端信息，主节点的连接状态为flags=M，从节点连接状态为flags=S。
• 主节点默认每隔 10 秒对从节点发送ping命令，判断从节点的存活性和连接状态。可通过参数repl-ping-slave-period控制发送频率。
• 从节点在主线程中每隔 1 秒发送replconf ack{offset}命令，给主节点上报自身当前的复制偏移量。replconf命令主要作用如下：
  • 实时监测主从节点网络状态
  • 上报自身复制偏移量，检查复制数据是否丢失，如果从节点数据丢失，再从主节点的复制缓冲区中拉取丢失数据
  • 实现保证从节点的数量和延迟性功能，通过 min-slaves-to-write、minslaves-max-lag 参数配置定义

我们经常会遇到数据同步的问题，但如何在消耗最少的资源下保证数据的一致性是我们一直会遇到的问题，好在，很多成熟的 软件已经为我们提供了借鉴的方案，如 Git 的 hash chain，Redis 的 psync 偏移量增量复制与缓冲区，以及 MySQL 的 binlog。没有最好的方案，只有最合适的方案，或许我们能从中得到启发，找到最适合自己的增量同步方式。

开发与运维中的问题¶

数据延时¶

Redis 复制数据的延迟由于异步复制特性是无法避免的，延迟取决于网络带宽和命令阻塞情况。需要业务场景允许短时间内的数据延迟。对于无法容忍大量延迟场景，可以编写外部监控程序监听主从节点的复制偏移量，当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点。

读到过期数据¶

惰性删除：主节点将过期的键同步给从节点 定时删除：主节点轮询采样一定数量的键，当采样的键过期后，同步给从节点。 Redis 3.2+ 在从节点读取键时会校验是否过期以判断是否返回数据。

从节点故障¶

下线故障节点。

当主节点优化空间不大时再考虑扩展。笔者建议大家在做读写分离之前，可以考虑使用 Redis Cluster 等分布式解决方案，这样不止扩展了读性能还可以扩展写性能和可支撑数据规模，并且一致性和故障转移也可以得到保证，对于客户端的维护逻辑也相对容易。

规避全量复制¶

• 第一次建立复制：由于是第一次建立复制，从节点不包含任何主节点数据，因此必须进行全量复制才能完成数据同步。对于这种情况全量复制无法避免。当对数据量较大且流量较高的主节点添加从节点时，建议在低峰时进行操作，或者尽量规避使用大数据量的 Redis 节点。
• 节点运行 ID 不匹配：当主从复制关系建立后，从节点会保存主节点的运行 ID，如果此时主节点因故障重启，那么它的运行 ID 会改变，从节点发现主节点运行 ID 不匹配时，会认为自己复制的是一个新的主节点从而进行全量复制。对于这种情况应该从架构上规避，比如提供故障转移功能。当主节点发生故障后，手动提升从节点为主节点或者采用支持自动故障转移的哨兵或集群方案。
• 复制积压缓冲区不足：当主从节点网络中断后，从节点再次连上主节点时会发送psync {offset} {runId}命令请求部分复制，如果请求的偏移量不在主节点的积压缓冲区内，则无法提供给从节点数据，因此部分复制会退化为全量复制。此时需要保证repl_backlog_size > net_break_time*write_size_per_minute以避免缓冲区不足引发的全量复制。

规避复制风暴¶

单主节点复制风暴¶

一般发生在主节点挂载多个从节点的场景。当主节点重启恢复后，从节点会发起全量复制流程，这时主节点就会为从节点创建 RDB 快照，如果在快照创建完毕之前，有多个从节点都尝试与主节点进行全量同步，那么其他从节点将共享这份 RDB 快照，同时向多个从节点发送 RDB 快照，可能使主节点的网络带宽消耗严重，造成主节点的延迟变大，极端情况会发生主从节点连接断开，导致复制失败。 解决方案可以减少主节点挂载的从节点数量，或者采用树形复制结构(这种树状结构也带来了运维的复杂性，增加了手动和自动处理故障转移的难度)。

单机器复制风暴¶

• 应该把主节点尽量分散在多台机器上，避免在单台机器上部署过多的主节点。
• 当主节点所在机器故障后提供故障转移机制，避免机器恢复后进行密集的全量复制。

第 7 章 阻塞¶

发生阻塞会有内在与外在原因：

• 内在原因：不合理地使用 API 或数据结构、CPU 饱和、持久化阻塞等
• 外在原因：CPU 竞争、内存交换、网络问题等

内因¶

如何发现慢查询¶

执行slowlog get {n}获取最近的 n 条慢查询命令，线上实例建议设置为 1 毫秒便于及时发现毫秒级以上的命令。如果命令执行时间在毫秒级，则实例实际 OPS 只有 1000 左右。慢查询队列长度默认 128，可适当调大。慢查询本身只记录了命令执行时间，不包括数据网络传输时间和命令排队时间，因此客户端发生阻塞异常后，可能不是当前命令缓慢，而是在等待其他命令执行。需要重点比对异常和慢查询发生的时间点，确认是否有慢查询造成的命令阻塞排队。

解决慢查询

• 修改为低算法度的命令，如hgetall改为hmget等，禁用keys、sort等命令。
• 调整大对象：缩减大对象数据或把大对象拆分为多个小对象，防止一次命令操作过多的数据。大对象拆分过程需要具体的业务决定，如用户好友集合存储在 Redis 中，有些热点用户会关注大量好友，这时可以按时间或其他维度拆分到多个集合中。

如何发现大对象¶

Redis 本身提供发现大对象的工具redis-cli -h{ip} -p{port} bigkeys。内部原理采用分段进行scan操作，把历史扫描过的最大对象统计出来便于分析优化，

CPU 饱和¶

使用top命令很容易识别出对应 Redis 进程的 CPU 使用率。CPU 饱和是非常危险的，将导致 Redis 无法处理更多的命令，严重影响吞吐量和应用方的稳定性。对于这种情况，首先判断当前 Redis 的并发量是否达到极限，建议使用统计命令redis-cli -h{ip} -p{port} --stat获取当前 Redis 使用情况，该命令每秒输出一行统计信息。

持久化阻塞¶

持久化引起主线程阻塞的操作主要有：

• fork 阻塞 fork 阻塞可以执行info stats命令获取到latest_fork_usec指标，表示 Redis 最近一次 fork 操作耗时，如果耗时很大，比如超过 1 秒，则需要做出优化调整，如避免使用过大的内存实例和规避 fork 缓慢的操作系统等。
• AOF 刷盘阻塞 AOF 刷盘阻塞主要是硬盘压力引起，可以查看 Redis 日志识别出这种情况。硬盘压力可能是 Redis 进程引起的，也可能是其他进程引起的，可以使用iotop查看具体是哪个进程消耗过多的硬盘资源。
• HugePage 写操作阻塞 子进程在执行重写期间利用 Linux 写时复制技术降低内存开销，因此只有写操作时 Redis 才复制要修改的内存页。对于开启 Transparent HugePages 的操作系统，每次写命令引起的复制内存页单位由 4K 变为 2MB，放大了 512 倍，会拖慢写操作的执行时间，导致大量写操作慢查询。例如简单的 incr 命令也会出现在慢查询中。关于 Transparent HugePages 的细节见第 12 章的 12.1 节“Linux 配置优化”。

Redis 对阻塞问题的说明：https://redis.io/topics/latency

外因¶

CPU 竞争¶

进程竞争：Redis 是典型的 CPU 密集型应用，不建议和其他多核 CPU 密集型服务部署在一起。当其他进程过度消耗 CPU 时，将严重影响 Redis 吞吐量。可以通过top、sar等命令定位到 CPU 消耗的时间点和具体进程，这个问题比较容易发现，需要调整服务之间部署结构。 绑定 CPU：部署 Redis 时为了充分利用多核 CPU，通常一台机器部署多个实例。常见的一种优化是把 Redis 进程绑定到 CPU 上，用于降低 CPU 频繁上下文切换的开销。但当 Redis 父进程创建子进程进行 RDB/AOF 重写时，如果做了 CPU 绑定，会与父进程共享使用一个 CPU。子进程重写时对单核 CPU 使用率通常在 90%以上，父进程与子进程将产生激烈 CPU 竞争，极大影响 Redis 稳定性。因此对于开启了持久化或参与复制的主节点不建议绑定 CPU。

内存交换¶

内存交换（swap）对于 Redis 来说是非常致命的，Redis 保证高性能的一个重要前提是所有的数据在内存中。如果操作系统把 Redis 使用的部分内存换出到硬盘，由于内存与硬盘读写速度差几个数量级，会导致发生交换后的 Redis 性能急剧下降。

判断 Redis 是否内存交换的方法：

1. 查询 Redis 的进程号：# redis-cli -p 6379 info server | grep process_id // process_id:4476
2. 根据进程号查询内存交换信息：# cat /proc/4476/smaps | grep Swap 如果交换量都是 0KB 或者个别的是 4KB，则是正常现象，说明 Redis 进程内存没有被交换。

预防 Redis 的内存交换

• 保证机器可用内存充足
• 确保所有 Redis 实例设置最大可用内存(maxmemory)
• 降低系统使用 swap 优先级，如echo10>/proc/sys/vm/swappiness

网络问题¶

Redis 连接拒绝：Redis 通过 maxclients 参数控制客户端最大连接数，默认 10000。当 Redis 连接数大于maxclients时会拒绝新的连接进入，info stats的rejected_connections统计指标记录所有被拒绝连接的数量。客户端访问 Redis 时尽量采用 NIO 长连接或者连接池的方式。Redis 默认不会主动关闭长时间闲置连接或检查关闭无效的 TCP 连接，因此会导致 Redis 连接数快速消耗且无法释放的问题，此时可设置tcp-keepalive和timeout参数让 Redis 主动检查和关闭无效连接。

连接溢出：OS 一般会对进程使用的资源做限制，其中一项是对进程可打开最大文件数控制，默认 1024，对需要支撑高并发的 Redis 需要调大该限制。

常见的物理拓扑按网络延迟由快到慢可分为：同物理机>同机架>跨机架>同机房>同城机房>异地机房。但它们容灾性正好相反。

第 8 章 理解内存¶

内存消耗可以分为进程自身消耗和子进程消耗。

内存消耗¶

内存消耗统计¶

通过info memory命令获取内存相关指标，指标说明如下表：

当mem_fragmentation_ratio > 1时，说明used_memory_rss-used_memory多出的部分内存并没有用于数据存储，而是被内存碎片所消耗，如果两者相差很大，说明碎片率严重。 当mem_fragmentation_ratio < 1时，这种情况一般出现在操作系统把 Redis 内存交换（Swap）到硬盘导致，出现这种情况时要格外关注，由于硬盘速度远远慢于内存，Redis 性能会变得很差，甚至僵死。

内存消耗划分¶

内存碎片问题虽然是所有内存服务的通病，但是 jemalloc 针对碎片化问题专门做了优化，一般不会存在过度碎片化的问题，正常的碎片率（mem_fragmentation_ratio）在 1.03 左右。但是当存储的数据长短差异较大时，以下场景容易出现高内存碎片问题：

• 频繁做更新操作，例如频繁对已存在的键执行append、setrange等更新操作。
• 大量过期键删除，键对象过期删除后，释放的空间无法得到充分利用，导致碎片率上升。

出现高内存碎片问题时常见的解决方式如下：

• 数据对齐：在条件允许的情况下尽量做数据对齐，比如数据尽量采用数字类型或者固定长度字符串等，但是这要视具体的业务而定，有些场景无法做到。
• 安全重启：重启节点可以做到内存碎片重新整理，因此可以利用高可用架构，如 Sentinel 或 Cluster，将碎片率过高的主节点转换为从节点，进行安全重启。

子进程内存消耗¶

• Redis 产生的子进程并不需要消耗 1 倍的父进程内存，实际消耗根据期间写入命令量决定，但是依然要预留出一些内存防止溢出。
• 需要设置sysctl vm.overcommit_memory = 1允许内核可以分配所有的物理内存，防止 Redis 进程执行 fork 时因系统剩余内存不足而失败。
• 排查当前系统是否支持并开启 THP，如果开启，建议关闭，防止copy-onwrite期间内存过度消耗。如果在高并发写的场景下开启 THP，子进程内存消耗可能是父进程的数倍，极易造成机器物理内存溢出，从而触发 SWAP 或 OOM killer。

内存管理¶

Redis 主要通过控制内存上限和回收策略实现内存管理。

设置内存上限¶

Redis 使用maxmemory参数限制最大可用内存。需要注意，maxmemory限制的是 Redis 实际使用的内存量，也就是used_memory统计项对应的内存。由于内存碎片率的存在，实际消耗的内存可能会比maxmemory设置的更大，实际使用时要小心这部分内存溢出。通过设置内存上限可以非常方便地实现一台服务器部署多个 Redis 进程的内存控制。比如一台 24GB 内存的服务器，为系统预留 4GB 内存，预留 4GB 空闲内存给其他进程或 Redis fork 进程，留给 Redis16GB 内存，这样可以部署 4 个maxmemory=4GB的 Redis 进程。得益于 Redis 单线程架构和内存限制机制，即使没有采用虚拟化，不同的 Redis 进程之间也可以很好地实现 CPU 和内存的隔离性，

动态调整内存上限¶

Redis 的内存上限可以通过config set maxmemory进行动态修改。该方式过于简单，推荐使用哨兵或者集群来处理。

Redis 默认无限使用服务器内存，为防止极端情况下导致系统内存耗尽，建议所有的 Redis 进程都要配置maxmemory。

内存回收策略¶

Redis 的内存回收机制分为删除过期的键对象，与内存使用达到 maxmemory 上限时触发内存溢出控制策略。

Redis 所有的键都可以设置过期属性，内部保存在过期字典中。由于进程内保存大量的键，维护每个键精准的过期删除机制会导致消耗大量的 CPU，对于单线程的 Redis 来说成本过高，因此 Redis 采用惰性删除和定时任务删除机制实现过期键的内存回收。

Redis 的内存溢出有 6 种控制策略，可通过config set maxmemory-policy {policy}配置

1. noeviction：默认策略，不会删除任何数据，拒绝所有写入操作并返回客户端错误信息（error）OOM command not allowed when used memory，此时 Redis 只响应读操作。
2. volatile-lru：根据 LRU 算法删除设置了超时属性（expire）的键，直到腾出足够空间为止。如果没有可删除的键对象，回退到 noeviction 策略。
3. allkeys-lru：根据 LRU 算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
4. allkeys-random：随机删除所有键，直到腾出足够空间为止。
5. volatile-random：随机删除过期键，直到腾出足够空间为止。
6. volatile-ttl：根据键值对象的 ttl 属性，删除最近将要过期数据。如果没有，回退到 noeviction 策略。

频繁执行回收内存成本很高，会导致 Redis 的性能下降，如果当前 Redis 有从节点，回收内存操作对应的删除命令会同步到从节点，导致写放大的问题。

内存优化¶

redisObject 对象¶

Redis 存储的所有值对象在内部定义为 redisObject 结构体，内部结构如图：

• type 字段：表示当前对象使用的数据类型，可以使用type {key}命令查看对象所属类型
• encoding 字段：Redis 内部编码类型
• lru 字段：记录对象最后一次被访问的时间，当配置了maxmemory和maxmemory-policy=volatile-lru或者allkeys-lru时，用于辅助 LRU 算法删除键数据。可以使用object idletime {key}命令在不更新 lru 字段情况下查看当前键的空闲时间。
• refcount 字段：记录当前对象被引用的次数，用于通过引用次数回收内存，当refcount=0时，可以安全回收当前对象空间。
• *ptr字段：与对象的数据内容相关，如果是整数，直接存储数据；否则表示指向数据的指针。Redis 在 3.0 之后对值对象是字符串且长度<=39 字节的数据，内部编码为embstr类型，字符串sds和redisObject一起分配，从而 只要一次内存操作即可。

缩减键值对象¶

降低 Redis 内存使用最直接的方式就是缩减键（key）和值（value）的长度。

• key 长度：如在设计键时，在完整描述业务情况下，键值越短越好。如user：{uid}：friends：notify：{fid}可以简化为u：{uid}：fs：nt：{fid}
• value 长度：值对象缩减比较复杂，常见需求是把业务对象序列化成二进制数组放入 Redis。首先应该 在业务上精简业务对象，去掉不必要的属性避免存储无效数据。其次在序列化工具选择上，应该 选择更高效的序列化工具来降低字节数组大小。值对象除了存储二进制数据之外，通常还会使用通用格式存储数据比如：json、xml 等作为字符串存储在 Redis 中。这种方式优点是方便调试和跨语言，但是同样的数据相比字节数组所需的空间更大，在内存紧张的情况下，可以使用通用压缩算法压缩 json、xml 后再存入 Redis，从而降低内存占用，例如使用 GZIP 压缩后的 json 可降低约 60%的空间。（当频繁压缩解压 json 等文本数据时，开发人员需要考虑压缩速度和计算开销成本，这里推荐使用 Google 的 Snappy 压缩工具，在特定的压缩率情况下效率远远高于 GZIP 等传统压缩工具，且支持所有主流语言环境。）

字符串优化¶

Redis 没有采用原生 C 语言的字符串类型而是自己实现了字符串结构，内部简单动态字符串（simple dynamic string，SDS）。

Redis 自身实现的字符串结构有如下特点：

• \(O(1)\)时间复杂度获取：字符串长度、已用长度、未用长度。
• 可用于保存字节数组，支持安全的二进制数据存储。
• 内部实现空间预分配机制，降低内存再分配次数。
• 惰性删除机制，字符串缩减后的空间不释放，作为预分配空间保留。

字符串之所以采用预分配的方式是防止修改操作需要不断重分配内存和字节数据拷贝。但同样也会造成内存的浪费。我们需要尽量减少字符串频繁修改操作如append、setrange可能导致的预分配容量翻倍（内存碎片率上升）的问题。

字符串重构：指 不一定把每份数据作为字符串整体存储，像 json 这样的数据可以使用 hash 结构，使用二级结构存储也能帮我们节省内存。同时可以使用hmget、hmset命令支持字段的部分读取修改，而不用每次整体存取。如下面的 json 数据：

{
    "vid": "413368768",
    "title": "搜狐屌丝男士",
    "videoAlbumPic": "http://photocdn.sohu.com/60160518/vrsa_ver8400079_ae433_pic26.jpg",
    "pid": "6494271",
    "type": "1024",
    "playlist": "6494271",
    "playTime": "468"
}

测试内存表现

根据测试结构，第一次默认配置下使用 hash 类型，内存消耗不但没有降低反而比字符串存储多出 2 倍，而调整hash-max-ziplist-value=66之后内存降低为 535.60M。因为 json 的videoAlbumPic属性长度是 65，而hash-max-ziplist-value默认值是 64，Redis 采用hashtable编码方式，反而消耗了大量内存。调整配置后 hash 类型内部编码方式变为ziplist，相比字符串更省内存且支持属性的部分操作。

编码优化¶

Redis 对一种数据结构实现多种编码方式主要原因是 Redis 作者想通过不同编码实现效率和空间的平衡。比如当我们的存储只有 10 个元素的列表，当使用双向链表数据结构时，必然需要维护大量的内部字段如每个元素需要：前置指针，后置指针，数据指针等，造成空间浪费，如果采用连续内存结构的压缩列表（ziplist），将会节省大量内存，而由于数据长度较小，存取操作时间复杂度即使为 \(O(n^2)\) 性能也可满足需求。

ziplist 编码主要目的是为了节约内存，因此所有数据都是采用线性连续的内存结构。ziplist 编码是应用范围最广的一种，可以分别作为 hash、list、zset 类型的底层数据结构实现。其内部结构如图：

ziplist 特点如下：

• 内部表现为数据紧凑排列的一块连续内存数组。
• 可以模拟双向链表结构，以 \(O(1)\) 时间复杂度入队和出队。
• 新增删除操作涉及内存重新分配或释放，加大了操作的复杂性。(ziplist 压缩编码的原则：追求空间和时间的平衡)
• 读写操作涉及复杂的指针移动，最坏时间复杂度为 \(O(n^2)\)。
• 适合存储小对象和长度有限的数据。

我们可以看到，Redis 通过多种手段来保障性能，如单线程、epoll、基于内存操作、内存预分配、自动切换合理的数据结构等，作者在这方便做了很多的努力，所以才会有很多 O(1)复杂度方法，日后才能大行其道，这其中我们可以借鉴的经验俯拾皆是，足见作者是一个有追求的 coder，相信 Redis 的源码会给与我们更多的启发。

控制键的数量¶

对于存储相同的数据内容利用 Redis 的数据结构(如 hash)降低外层键的数量，也可以节省大量内存。

建议使用 Redis 存储大量数据时，把内存优化环节加入到前期设计阶段，否则数据大幅增长后，开发人员需要面对重新优化内存所带来开发和数据迁移的双重成本。当 Redis 内存不足时，首先考虑的问题不是加机器做水平扩展，应该先尝试做内存优化，当遇到瓶颈时，再去考虑水平扩展。即使对于集群化方案，垂直层面优化也同样重要，避免不必要的资源浪费和集群化后的管理成本。

优化总结¶

内存是相对宝贵的资源，通过合理的优化可以有效地降低内存的使用量，内存优化的思路包括

• 精简键值对大小，使用高效二进制序列化工具。
• 使用对象共享池优化小整数对象。
• 数据优先使用整数，比字符串类型更节省空间。
• 优化字符串使用，避免预分配造成的内存浪费。
• 使用ziplist压缩编码优化hash、list等结构，注重效率和空间的平衡。
• 使用intset编码优化整数集合。
• 使用ziplist编码的hash结构降低小对象链规模。

第 9 章 哨兵¶

基础概念¶

主从模式下存在的问题：

1. 主节点宕机的故障转移需要人工介入恢复（👉 哨兵）
2. 主节点的写能力与存储能力受到单机的限制（👉 集群）

Redis Sentinel 具有以下几个功能：

• 监控：Sentinel 节点会定期检测 Redis 数据节点、其余 Sentinel 节点是否可达。
• 通知：Sentinel 节点会将故障转移的结果通知给应用方。
• 主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系。
• 配置提供者：在 Redis Sentinel 结构中，客户端在初始化的时候连接的是 Sentinel 节点集合，从中获取主节点信息。

部署¶

从节点的部署与主节点的基本一致，只是添加了slaveof配置。 可通过info replication命令查看从节点或所属主节点。

哨兵节点配置信息如下：

redis-sentinel-26379.conf
port 26379                                                      // 哨兵默认端口
daemonize yes
logfile "26379.log"                                             // 日志文件
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2                      // 该哨兵监控 mymaster 127.0.0.1 6379 的主节点，同时需要 2 个哨兵判断故障才会进行故障转移。故障判定参数 quorum 建议设置为哨兵节点数量的一般加 1，同时该参数还与哨兵节点的领导者选举有关，至少需要有 `max(quorum, num(sentinels)/2 + 1)`个节点参与选举，才能选出哨兵领导者
sentinel down-after-milliseconds mymaster 30000                 // 监控节点的超时时间
sentinel parallel-syncs mymaster 1                              // 用于限制一次故障转移后，每次向新的主节点发起复制操作的从节点个数。同时向主节点发起复制，必然会对主机诶单所在机器造成网络与磁盘开销
sentinel failover-timeout mymaster 180000                       // 故障转移超时时间
# sentinel auth-pass <master-name> <password>
# sentinel notification-script <master-name> <script-path>      // 在故障转移期间的告警事件脚本
# sentinel client-reconfig-script <master-name> <script-path>   // 在故障转移结束后的事件脚本

启动 Sentinel 节点的命令：redis-sentinel或redis-server redis-sentinel-26379.conf --sentinel。 可通过info sentinel命令查看哨兵节点信息 哨兵节点会通过主节点发现从节点以及其它哨兵节点，从而实现对所有节点的监控。

部署技巧

• 哨兵节点不应该部署在同一台物理机上
• 部署至少三个且奇数个哨兵节点
• 如果哨兵节点集合监控的是同一个业务的多个主节点集合，那么采用一套哨兵节点监控多个主从节点，否则采用多个哨兵节点监控多个主从节点的方案。

哨兵节点的 API¶

Redis Sentinel 客户端基本实现原理：

1. 遍历 Sentinel 节点集合获取一个可用的 Sentinel 节点(Sentinel 节点之间可以共享数据)，所以可以从任意一个 Sentinel 节点获取主节点信息

2. 通过sentinel get-master-addr-by-name master-name这个 API 来获取对应主节点的相关信息

3. 验证当前获取的“主节点”是真正的主节点(通过 role 或者 info replication 判定)，这样做的目的是为了防止故障转移期间主节点的变化

4. 保持和 Sentinel 节点集合的“联系”，时刻获取关于主节点的相关“信息”

Redis Sentinel 的实现原理¶

三个定时监控任务¶

1. 每隔 10 秒，每个 Sentinel 节点会向主节点和从节点发送info命令获取最新的拓扑结构。该任务的作用表现在：
   1. 通过向主节点执行info命令，获取从节点的信息
   2. 当有新的从节点加入时都可以立刻感知出来
   3. 节点不可达或者故障转移后，可以通过info命令实时更新节点拓扑信息。
2. 每隔 2 秒，每个 Sentinel 节点会向 Redis 数据节点的__sentinel__：hello频道上发送该 Sentinel 节点对于主节点的判断以及当前 Sentinel 节点的信息，同时每个 Sentinel 节点也会订阅该频道，来了解其他 Sentinel 节点以及它们对主节点的判断，所以这个定时任务可以完成以下两个工作：
   1. 发现新的 Sentinel 节点：通过订阅主节点的__sentinel__：hello了解其他的 Sentinel 节点信息，如果是新加入的 Sentinel 节点，将该 Sentinel 节点信息保存起来，并与该 Sentinel 节点创建连接。
   2. Sentinel 节点之间交换主节点的状态，作为后面客观下线以及领导者选举的依据。Sentinel 节点 publish 的消息格式：<Sentinel 节点 IP> <Sentinel 节点端口> <Sentinel 节点 runId> <Sentinel 节点配置版本> <主节点名字> <主节点 Ip> <主节点端口> <主节点配置版本>
3. 每隔 1 秒，每个 Sentinel 节点会向主节点、从节点、其余 Sentinel 节点发送一条 ping 命令做一次心跳检测，来确认这些节点当前是否可达。这个定时任务是节点失败判定的重要依据。

主观下线与客观下线¶

• 主观下线：单个哨兵节点判断主节点超过down-after-milliseconds时，该哨兵节点即认为该主节点已下线
• 客观下线：为了防止主观下线的误判，因此还需要发送过 sentinel ismaster-down-by-addr命令向其他 Sentinel 节点询问对主节点的判断，当超过<quorum>个数，即判定该主节点确实已下线

领导者 Sentinel 节点选举¶

Redis 使用了 Raft 算法 实现领导者选举。该算法的思路为：每个节点均有选举与被选举资格，且每个节点有且只有 1 票。当哨兵节点完成主观下线后，向其它哨兵节点询问客观下线时，会提议自身作为哨兵领导者，若被询问者尚未投票，则取得该被询问者的票数，如果询问者的票数大于等于 \(max(quorum, num(sentinels)/2 + 1)\)，则该询问者成为领导，选举结束，同时终止其它节点的询问。

Raft 作为一致性协议，提供了以下几个重要的功能：

1. Leader 选举
2. 成员变更
3. 日志复制

故障转移¶

故障转移的具体步骤如下：

1. 在从节点列表中选出一个节点作为新的主节点，选择方法如下
   1. 过滤：“不健康”（主观下线、断线）、5 秒内没有回复过 Sentinel 节点 ping 响应、与主节点失联超过down-after-milliseconds * 10秒。
   2. 选择slave-priority（从节点优先级）最高的从节点列表，如果存在则返回，不存在则继续。
   3. 选择复制偏移量最大的从节点（复制的最完整），如果存在则返回，不存在则继续。
   4. 选择 runid 最小的从节点。
2. Sentinel 领导者节点会对第一步选出来的从节点执行slaveof no one 命令让其成为主节点
3. Sentinel 领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点，复制规则和parallel-syncs参数有关
4. Sentinel 节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复后命令它去复制新的主节点。

开发与运维问题¶

模拟故障的方式：

• 方法一，强制杀掉对应节点的进程号，这样可以模拟出宕机的效果。
• 方法二，使用 Redis 的debug sleep命令，让节点进入睡眠状态，这样可以模拟阻塞的效果。
• 方法三，使用 Redis 的shutdown命令，模拟正常的停掉 Redis。

Sentinel 节点只支持如下命令：ping、sentinel、subscribe、unsubscribe、psubscribe、punsubscribe、publish、info、role、client、shutdown。

第 10 章 集群¶

数据分布¶

常见的分区规则有哈希分区与顺序分区两种。Redis 集群采用了哈希分区。

常见的哈希分区规则¶

• 节点取余
  • 使用特定的数据，如 Redis 的键或用户 ID，再根据节点数量 N 使用公式：hash(key)%N计算出哈希值，用来决定数据映射到哪一个节点上。这种方案存在一个问题：当节点数量变化时，如扩容或收缩节点，数据节点映射关系需要重新计算，会导致数据的重新迁移。常用于数据库的分库分表规则，一般采用预分区的方式，提前根据数据量规划好分区数。
• 一致性哈希分区
  • 一致性哈希分区（Distributed Hash Table）实现思路是为系统中每个节点分配一个 token，范围一般在 0~2，这些 token 构成一个哈希环。数据读写执行节点查找操作时，先根据 key 计算 hash 值，然后顺时针找到第一个大于等于该哈希值的 token 节点 32
  • 一致性哈希分区存在几个问题：
    1. 加减节点会造成哈希环中部分数据无法命中，需要手动处理或者忽略这部分数据，因此 一致性哈希常用于缓存场景
    2. 当使用少量节点时，节点变化将大范围影响哈希环中数据映射，因此这种方式 不适合少量数据节点的分布式方案
    3. 普通的一致性哈希分区在增减节点时需要增加一倍或减去一半节点才能保证数据和负载的均衡。
• 虚拟分区槽
  • 虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有数据映射到一个固定范围的整数集合中，整数定义为槽（slot），计算公式为slot=CRC16(key)&16383。如 Redis Cluster 槽范围是 0~16383。槽是集群内数据管理和迁移的基本单位。采用大范围槽的主要目的是为了方便数据拆分和集群扩展。每个节点会负责一定数量的槽

Redis 虚拟槽分区的特点：

• 解耦数据和节点之间的关系，简化了节点扩容和收缩难度。
• 节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据。
• 支持节点、槽、键之间的映射查询，用于数据路由、在线伸缩等场景。

集群功能限制¶

1. key 批量操作支持有限。如 mset、mget，目前只支持具有相同 slot 值的 key 执行批量操作。对于映射为不同 slot 值的 key 由于执行 mget、mget 等操作可能存在于多个节点上因此不被支持。
2. key 事务操作支持有限。同理只支持多 key 在同一节点上的事务操作，当多个 key 分布在不同的节点上时无法使用事务功能。
3. key 作为数据分区的最小粒度，因此不能将一个大的键值对象如 hash、list 等映射到不同的节点。
4. 不支持多数据库空间。单机下的 Redis 可以支持 16 个数据库，集群模式下只能使用一个数据库空间，即 db0。
5. 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。

集群搭建¶

搭建集群需要三个步骤：

1. 准备节点
   • Redis 集群一般由多个节点组成，节点数量至少为 6 个才能保证组成完整高可用的集群。每个节点需要开启配置 cluster-enabled yes，让 Redis 运行在集群模式下。建议为集群内所有节点统一目录，一般划分三个目录：conf、data、log，分别存放配置、数据和日志相关文件。
   • 节点 ID 用于唯一标识集群内一个节点，之后很多集群操作都要借助于节点 ID 来完成。需要注意是，节点 ID 不同于运行 ID。节点 ID 在集群初始化时只创建一次，节点重启时会加载集群配置文件进行重用，而 Redis 的运行 ID 每次重启都会变化。在节点 6380 执行cluster nodes命令获取集群节点状态。
   • Redis 自动维护集群配置文件，不要手动修改，防止节点重启时产生集群信息错误。
2. 节点握手
   • 由客服端发起命令cluster meet {ip} {port}建立连接，该命令为异步命令。
   • 节点建立握手后，集群此时处于下线状态，所有的数据读写都被禁止。可以通过cluster info查看当前集群状态。
3. 分配槽
   • 通过cluster addslots命令为节点分配槽。作为一个完整的集群，每个负责处理槽的节点应该具有从节点，保证当它出现故障时可以自动进行故障转移。集群模式下，Reids 节点角色分为主节点和从节点。首次启动的节点和被分配槽的节点都是主节点，从节点负责复制主节点槽信息和相关的数据。使用cluster replicate{nodeId}命令让一个节点成为从节点。

由于手动创建集群过于繁琐，且随着集群规模的扩大会加大复杂度与运维成本，因此可以通过redis-trib.rb来搭建集群，该工具支持集群创建、检查、修复、均衡等命令行工具。

当集群创建完成后，我们还需要进行完整性检查。集群完整性指所有的槽都分配到存活的主节点上，只要 16384 个槽中有一个没有分配给节点则表示集群不完整。可以使用redis-trib.rb check命令检测之前创建的两个集群是否成功，check命令只需要给出集群中任意一个节点地址就可以完成整个集群的检查工作。当持有槽的主节点下线时，从故障发现到自动完成转移期间整个集群是不可用状态，对于大多数业务无法容忍这种情况，因此建议将参数cluster-require-full-coverage配置为 no，当主节点故障时只影响它负责槽的相关命令执行，不会影响其他主节点的可用性。

节点通信¶

常见的元数据维护方式分为：集中式和 P2P 方式。Redis 集群采用 P2P 的 Gossip（流言）协议，Gossip 协议工作原理就是节点彼此不断通信交换信息，一段时间后所有的节点都会知道集群完整的信息，这种方式类似流言传播。其通信过程如下：

1. 集群中的每个节点都会单独开辟一个 TCP 通道，用于节点之间彼此通信，通信端口号在基础端口上加 10000。
2. 每个节点在固定周期内通过特定规则选择几个节点发送 ping 消息。
3. 接收到 ping 消息的节点用 pong 消息作为响应。

我们经常在网络中使用 ping 作为探活命令，使用 pong 作为响应，这个两个词在一次正好为 ping-pong 乒乓球，可以理解为发送方发出去的球得到响应才认为对方存活。不知道创建这一对命令的人是否也是基于这个理念创建的。

常用的 Gossip 消息可分为：ping 消息、pong 消息、meet 消息、fail 消息等。

• meet 消息：用于通知新节点加入
• ping 消息：用于检测节点是否在线和交换彼此状态信息。ping 消息发送封装了自身节点和部分其他节点的状态数据。
• pong 消息：作为响应消息回复给发送方确认消息正常通信。pong 消息内部封装了自身状态数据。节点也可以向集群内广播自身的 pong 消息来通知整个集群对自身状态进行更新。
• fail 消息：当节点判定集群内另一个节点下线时，会向集群内广播一个 fail 消息，其他节点接收到 fail 消息之后把对应节点更新为下线状态。

所有消息格式划分为消息头和消息体。消息头包含发送节点自身状态数据（如节点 id、槽映射、节点标识（主从角色，是否下线）等），接收节点根据消息头就可以获取到发送节点的相关数据；消息体则包含了发送节点所了解的其他节点信息。消息的类型则根据消息头的 type 属性区分。

typedef struct {
    char sig[4];                            /* 信号标示 */
    uint32_t totlen;                        /* 消息总长度 */
    uint16_t ver;                           /* 协议版本*/
    uint16_t type;                          /* 消息类型,用于区分 meet,ping,pong 等消息 */
    uint16_t count;                         /* 消息体包含的节点数量，仅用于 meet,ping,ping 消息类型*/
    uint64_t currentEpoch;                  /* 当前发送节点的配置纪元 */
    uint64_t configEpoch;                   /* 主节点/从节点的主节点配置纪元 */
    uint64_t offset;                        /* 复制偏移量 */
    char sender[CLUSTER_NAMELEN];           /* 发送节点的 nodeId */
    unsigned char myslots[CLUSTER_SLOTS/8]; /* 发送节点负责的槽信息 */
    char slaveof[CLUSTER_NAMELEN];          /* 如果发送节点是从节点，记录对应主节点的 nodeId */
    uint16_t port;                          /* 端口号 */
    uint16_t flags;                         /* 发送节点标识,区分主从角色，是否下线等 */
    unsigned char state;                    /* 发送节点所处的集群状态 */
    unsigned char mflags[3];                /* 消息标识 */
    union clusterMsgData data               /* 消息正文 */;
} clusterMsg;

typedef struct {
    char nodename[CLUSTER_NAMELEN];          /* 节点的 nodeId */
    uint32_t ping_sent;                      /* 最后一次向该节点发送 ping 消息时间 */
    uint32_t pong_received;                  /* 最后一次接收该节点 pong 消息时间 */
    char ip[NET_IP_STR_LEN];                 /* IP */
    uint16_t port;                           /* port*/
    uint16_t flags;                          /* 该节点标识 */
} clusterMsgDataGossip;

如果节点间频繁通信，则会加重带宽和计算的负担，过慢又会导致信息更新不及时，因此 Redis 集群的 Gossip 协议需要兼顾信息交换实时性和成本开销。

从 Gossip 的通信机制中我们看到，影响带宽的主要因素在于通信的节点数与发送的消息数据量，因此，我们从这两方面进行优化：

• 选择发送消息的节点数量：集群内每个节点维护定时任务默认每秒执行 10 次，每秒会随机选取 5 个节点找出最久没有通信的节点发送 ping 消息，用于保证 Gossip 信息交换的随机性。每 100 毫秒都会扫描本地节点列表，如果发现节点最近一次接受 pong 消息的时间大于cluster_node_timeout/2，则立刻发送 ping 消息，防止该节点信息太长时间未更新。根据以上规则得出每个节点每秒需要发送 ping 消息的数量=1+10*num（node.pong_received>cluster_node_timeout/2，因此cluster_node_timeout参数对消息发送的节点数量影响非常大。当我们的带宽资源紧张时，可以适当调大这个参数。
• 消息数据量：消息头主要占用空间的字段是myslots[CLUSTER_SLOTS/8]，占用 2KB，这块空间占用相对固定。消息体携带数据量跟集群的节点数息息相关，更大的集群每次消息通信的成本也就更高，因此对于 Redis 集群来说并不是大而全的集群更好。

集群伸缩¶

集群的水平伸缩的上层原理：集群伸缩 = 槽和数据在节点之间的移动。

扩容集群¶

槽迁移数据流程如下：

1. 对目标节点发送cluster setslot {slot} importing {sourceNodeId}命令，让目标节点准备导入槽的数据。
2. 对源节点发送cluster setslot {slot} migrating {targetNodeId}命令，让源节点准备迁出槽的数据。
3. 源节点循环执行cluster getkeysinslot {slot} {count}命令，获取 count 个属于槽{slot}的键。
4. 在源节点上执行migrate {targetIp} {targetPort} "" 0 {timeout} keys {keys...}命令，把获取的键通过流水线机制批量迁移到目标节点。
5. 重复执行步骤 3 和步骤 4 直到槽下所有的键值数据迁移到目标节点。
6. 向集群内所有主节点发送cluster setslot {slot} node {targetNodeId}命令，通知槽分配给目标节点。为了保证槽节点映射变更及时传播，需要遍历发送给所有主节点更新被迁移的槽指向新节点。

redis-trib槽重分片功能命令如下：redis-trib.rb reshard host:port --from <arg> --to <arg> --slots <arg> --yes --timeout <arg> --pipeline <arg>

• host:port：必传参数，集群内任意节点地址，用来获取整个集群信息。
• --from：制定源节点的 id，如果有多个源节点，使用逗号分隔，如果是 all 源节点变为集群内所有主节点，在迁移过程中提示用户输入。
• --to：需要迁移的目标节点的 id，目标节点只能填写一个，在迁移过程中提示用户输入。
• --slots：需要迁移槽的总数量，在迁移过程中提示用户输入。
• --yes：当打印出 reshard 执行计划时，是否需要用户输入 yes 确认后再执行reshard。
• --timeout：控制每次 migrate 操作的超时时间，默认为 60000 毫秒。
• --pipeline：控制每次批量迁移键的数量，默认为 10。

迁移之后建议使用redis-trib.rb rebalance命令检查节点之间槽的均衡性。

收缩集群¶

1. 首先需要确定下线节点是否有负责的槽，如果是，需要把槽迁移到其他节点，保证节点下线后整个集群槽节点映射的完整性。
2. 当下线节点不再负责槽或者本身是从节点时，就可以通知集群内其他节点忘记下线节点，当所有的节点忘记该节点后可以正常关闭。

下线节点需要把自己负责的槽迁移到其他节点，原理与之前节点扩容的迁移槽过程一致。在此不做赘述。

由于集群内的节点不停地通过 Gossip 消息彼此交换节点状态，因此需要通过一种健壮的机制让集群内所有节点忘记下线的节点。也就是说让其他节点不再与要下线节点进行 Gossip 消息交换。Redis 提供了cluster forget{downNodeId}命令实现该功能。（此处的 Gossip 对忘记节点造成了阻碍）

当节点接收到cluster forget{down NodeId}命令后，会把 nodeId 指定的节点加入到禁用列表中，在禁用列表内的节点不再发送 Gossip 消息。禁用列表有效期是 60 秒，超过 60 秒节点会再次参与消息交换。也就是说当第一次 forget 命令发出后，我们有 60 秒的时间让集群内的所有节点忘记下线节点。线上操作不建议直接使用cluster forget命令下线节点，需要跟大量节点命令交互，实际操作起来过于繁琐并且容易遗漏 forget 节点。建议使用redistrib.rb del-node{host:port}{downNodeId}命令，内部实现的伪代码如下：

def delnode_cluster_cmd(downNode):
    # 下线节点不允许包含 slots
    if downNode.slots.length != 0
        exit 1
    end
    # 向集群内节点发送 cluster forget
    for n in nodes:
        if n.id == downNode.id:
            # 不能对自己做 forget 操作
            continue;
        # 如果下线节点有从节点则把从节点指向其他主节点
        if n.replicate && n.replicate.nodeId == downNode.id :
            # 指向拥有最少从节点的主节点
            master = get_master_with_least_replicas();
            n.cluster("replicate",master.nodeId);
        #发送忘记节点命令
        n.cluster('forget',downNode.id)
# 节点关闭
downNode.shutdown();

当下线主节点具有从节点时需要把该从节点指向到其他主节点，因此对于主从节点都下线的情况，建议先下线从节点再下线主节点，防止不必要的全量复制。

请求路由¶

请求重定向¶

在集群模式下，Redis 接收任何键相关命令时首先计算键对应的槽，再根据槽找出所对应的节点，如果节点是自身，则处理键命令；否则回复 MOVED 重定向错误，通知客户端请求正确的节点。这个过程称为 MOVED 重定向。

可以通过cluster keyslot{key}命令返回 key 所对应的槽，该命令采用key_hash_slot()函数实现。 使用redis-cli命令时，可以加入-c参数支持自动重定向，简化手动发起重定向操作。

键命令执行步骤主要分两步：计算槽，查找槽所对应的节点。

1. Redis 首先需要计算键所对应的槽。根据键的有效部分使用 CRC16 函数计算出散列值，再取对 16383 的余数，使每个键都可以映射到 0~16383 槽范围内。
2. 节点对于判定键命令是执行还是 MOVED 重定向，都是借助slots [CLUSTER_SLOTS]数组实现。根据 MOVED 重定向机制，客户端可以随机连接集群内任一 Redis 获取键所在节点，这种客户端又叫 Dummy（傀儡）客户端，它优点是代码实现简单，对客户端协议影响较小，只需要根据重定向信息再次发送请求即可。但是它的弊端很明显，每次执行键命令前都要到 Redis 上进行重定向才能找到要执行命令的节点，额外增加了 IO 开销，这不是 Redis 集群高效的使用方式。正因为如此通常集群客户端都采用另一种实现：Smart（智能）客户端。Smart 客户端通过在内部维护 slot→node 的映射关系，本地就可实现键到节点的查找，从而保证 IO 效率的最大化，而 MOVED 重定向负责协助 Smart 客户端更新 slot→node 映射。

hash_tag¶

hash_tag 允许用 key 的部分字符串来计算 hash。当一个 key 包含 {} 的时候，就不对整个 key 做 hash，而仅对 {} 包括的字符串做 hash。

在集群模式下使用 mget 等命令优化批量调用时，键列表必须具有相同的 slot，否则会报错。这时可以利用 hash_tag 让不同的键具有相同的 slot 达到优化的目的。命令如下：

127.0.0.1:6385> mget user:10086:frends user:10086:videos
(error) CROSSSLOT Keys in request don't hash to the same slot
127.0.0.1:6385> mget user:{10086}:friends user:{10086}:videos
1) "friends"
2) "videos"

Pipeline 同样可以受益于 hash_tag，由于 Pipeline 只能向一个节点批量发送执行命令，而相同 slot 必然会对应到唯一的节点，降低了集群使用 Pipeline 的门槛。

ASK 重定向¶

当 slot 对应的数据从源节点到目标节点迁移过程中，客户端需要做到智能识别，保证键命令可正常执行。例如当一个 slot 数据从源节点迁移到目标节点时，期间可能出现一部分数据在源节点，而另一部分在目标节点。

ASK 与 MOVED 虽然都是对客户端的重定向控制，但是有着本质区别。ASK 重定向说明集群正在进行 slot 数据迁移，客户端无法知道什么时候迁移完成，因此只能是临时性的重定向，客户端不会更新 slots 缓存。但是 MOVED 重定向说明键对应的槽已经明确指定到新的节点，因此需要更新 slots 缓存。

为了支持 ASK 重定向，源节点和目标节点在内部的 clusterState 结构中维护当前正在迁移的槽信息，用于识别槽迁移情况。

• 如果键所在的槽由当前节点负责，但键不存在则查找migrating_slots_to数组查看槽是否正在迁出，如果是返回 ASK 重定向。
• 如果客户端发送asking命令打开了CLIENT_ASKING标识，则该客户端下次发送键命令时查找importing_slots_from数组获取clusterNode，如果指向自身则执行命令。
  • 需要注意的是，asking 命令是一次性命令，每次执行完后客户端标识都会修改回原状态，因此每次客户端接收到 ASK 重定向后都需要发送 asking 命令。
• ASK 重定向对单键命令支持得很完善。当槽处于迁移状态时，批量操作会受到影响。

使用 smart 客户端批量操作集群时，需要评估mget/mset、Pipeline 等方式在 slot 迁移场景下的容错性，防止集群迁移造成大量错误和数据丢失的情况。

集群环境下对于使用批量操作的场景，建议优先使用 Pipeline 方式，在客户端实现对 ASK 重定向的正确处理，这样既可以受益于批量操作的 IO 优化，又可以兼容 slot 迁移场景。

故障转移¶

当某个节点被主观下线后，ping/pong 消息的消息体会携带集群 1/10 的其他节点状态数据在集群内传播。当半数以上持有槽的主节点都标记某个节点是主观下线时，触发客观下线流程。

每个下线报告都存在有效期(cluster-node-time*2)，每次在尝试触发客观下线时，都会检测下线报告是否过期，对于过期的下线报告将被删除。

如果在cluster-node-time*2时间内无法收集到一半以上槽节点的下线报告，那么之前的下线报告将会过期，也就是说主观下线上报的速度追赶不上下线报告过期的速度，那么故障节点将永远无法被标记为客观下线从而导致故障转移失败。因此不建议将cluster-node-time设置得过小。

故障恢复流程： 资格检查 -> 准备选举时间 -> 发起选举 -> 选举投票 -> 替换主节点

投票作废：每个配置纪元代表了一次选举周期，如果在开始投票之后的cluster-node-timeout*2时间内从节点没有获取足够数量的投票，则本次选举作废。从节点对配置纪元自增并发起下一轮投票，直到选举成功为止。

故障转移时间：failover-time(毫秒) ≤ cluster-node-timeout + cluster-node-timeout/2 + 1000

集群运维¶

集群倾斜

• 数据倾斜
  • 节点和槽分配严重不均。可以使用 redis-trib.rb info{host:ip} 进行定位
  • 不同槽对应键数量差异过大。键通过 CRC16 哈希函数映射到槽上，正常情况下槽内键数量会相对均匀。但当大量使用 hashtag 时，会产生不同的键映射到同一个槽的情况。特别是选择作为 hashtag 的数据离散度较差时，将加速槽内键数量倾斜情况。通过命令 cluster countkeysinslot{slot} 可以获取槽对应的键数量，识别出哪些槽映射了过多的键。再通过命令 clustergetkeysinslot{slot}{count} 循环迭代出槽下所有的键。从而发现过度使用 hash_tag 的键。
  • 集合对象包含大量元素。
  • 内存相关配置不一致。
• 请求倾斜
  • 合理设计键，热点大集合对象做拆分或使用 hmget 替代 hgetall 避免整体读取。
  • 不要使用热键作为 hash_tag，避免映射到同一槽。
  • 对于一致性要求不高的场景，客户端可使用本地缓存减少热键调用。

集群模式下从节点不接受任何读写请求，发送过来的键命令会重定向到负责槽的主节点上。当需要使用从节点分担主节点读压力时，可以使用readonly命令打开客户端连接只读状态。readonly命令是连接级别生效，因此每次新建连接时都需要执行readonly开启只读状态。执行readwrite命令可以关闭连接只读状态。

第 11 章 缓存设计¶

缓存更新策略¶

最佳实践：

1. 低一致性业务建议配置最大内存和淘汰策略的方式使用。
2. 高一致性业务可以结合使用超时剔除和主动更新，这样即使主动更新出了问题，也能保证数据过期时间后删除脏数据。

缓存穿透¶

缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中。造成缓存穿透的基本原因有两个：

1. 自身业务代码或者数据出现问题
2. 一些恶意攻击、爬虫等造成大量空命中

缓存穿透的解决方案¶

缓存空对象¶

缓存空对象会有两个问题：

1. 空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间（如果是攻击，问题更严重），比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。
2. 缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5 分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

String get(String key) {
    // 从缓存中获取数据
    String cacheValue = cache.get(key);
    // 缓存为空
    if (StringUtils.isBlank(cacheValue)) {
        // 从存储中获取
        String storageValue = storage.get(key);
        cache.set(key, storageValue);
        // 如果存储数据为空，需要设置一个过期时间(300 秒)
        if (storageValue == null) {
            cache.expire(key, 60 * 5);
        }
        return storageValue;
    } else {
        // 缓存非空
        return cacheValue;
    }
}

布隆过滤器拦截¶

如图所示，在访问缓存层和存储层之前，将存在的 key 用布隆过滤器提前保存起来，做第一层拦截。例如：一个推荐系统有 4 亿个用户 id，每个小时算法工程师会根据每个用户之前历史行为计算出推荐数据放到存储层中，但是最新的用户由于没有历史行为，就会发生缓存穿透的行为，为此可以将所有推荐数据的用户做成布隆过滤器。如果布隆过滤器认为该用户 id 不存在，那么就不会访问存储层，在一定程度保护了存储层。

可以利用 Redis 的 Bitmaps 实现布隆过滤器。类似开源方案可查看 https://github.com/erikdubbelboer/redis-lua-scaling-bloom-filter

无底洞优化¶

无底洞是指，采用分布式提升缓存的能力，但分布式架构又引发了mget等批量操作命令的多次网络连接造成的性能下降。因此，更多的节点不代表更高的性能，所谓“无底洞”就是说投入越多不一定产出越多。但是分布式又是不可以避免的，因为访问量和数据量越来越大，一个节点根本抗不住，所以如何高效地在分布式缓存中批量操作是一个难点。

无底洞问题的优化方案：

• 命令本身的优化，例如优化 SQL 语句等。
• 减少网络通信次数。
  • 客户端 n 次 get (串行执行)：n 次网络 + n 次 get 命令本身。
    • 即逐次执行 n 个 get 命令，这种操作时间复杂度较高，但实现也最简单。
  • 客户端 1 次 pipeline get (串行 I/O)：1 次网络 + n 次 get 命令本身。
    • Redis Cluster 使用 CRC16 算法计算出散列值，再取对 16383 的余数就可以算出 slot 值，同时 Smart 客户端会保存 slot 和节点的对应关系，有了这两个数据就可以将属于同一个节点的 key 进行归档，得到每个节点的 key 子列表，之后对每个节点执行 mget 或者 Pipeline 操作，它的操作时间 = node 次网络时间 + n 次命令时间，网络次数是 node 的个数，很明显这种方案比第一种要好很多，但是如果节点数太多，还是有一定的性能问题。
  • 客户端 1 次 mget (并行 I/O)：1 次网络 + 1 次 mget 命令本身。
    • 此方案是将方案 2 中的最后一步改为多线程执行，网络次数虽然还是节点个数，但由于使用多线程网络时间变为 \(O (1)\)，这种方案会增加编程的复杂度。其操作时间为：max_slow(node 网络时间)+n 次命令时间
  • Redis Cluster 的 hash_tag 可以将多个 key 强制分配到一个节点上，它的操作时间 = 1 次网络时间 + n 次命令时间。
• 降低接入成本，例如客户端使用长连 / 连接池、NIO (Non-blocking I/O) 等。

雪崩优化¶

缓存雪崩：如果缓存层由于某些原因不能提供服务，于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会级联宕机的情况。

优化方案如下：

1. 保证缓存层服务高可用性。Redis Sentinel 和 Redis Cluster 都实现了高可用。
2. 依赖隔离组件为后端限流并降级。作为并发量较大的系统，假如有一个资源不可用，可能会造成线程全部阻塞在这个资源上，造成整个系统不可用。降级机制在高并发系统中是非常普遍的：比如推荐服务中，如果个性化推荐服务不可用，可以降级补充热点数据，不至于造成前端页面是开天窗。在实际项目中，我们需要对重要的资源（例如 Redis、MySQL、HBase、外部接口）都进行隔离，让每种资源都单独运行在自己的线程池中，即使个别资源出现了问题，对其他服务没有影响。
3. 提前演练。在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，在此基础上做一些预案设定。

热点 key 重建优化¶

在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃。

解决热点 key 重建的思路：

• 减少重建缓存的次数。
• 数据尽可能一致。
• 较少的潜在危险。

解决方案¶

互斥锁(mutex key)¶

此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。

String get(String key) {
    // 从 Redis 中获取数据
    String value = redis.get(key);
    // 如果 value 为空，则开始重构缓存
    if (value == null) {
        // 只允许一个线程重构缓存，使用 nx，并设置过期时间 ex
        String mutexKey = "mutext:key:" + key;
        if (redis.set(mutexKey, "1", "ex 180", "nx")) {
            // 从数据源获取数据
            value = db.get(key);
            // 回写 Redis，并设置过期时间
            redis.setex(key, timeout, value);
            // 删除 key_mutex
            redis.delete(mutexKey);
        }
        // 其他线程休息 50 毫秒后重试
        else {
            Thread.sleep(50);
            get(key);
        }
    }
    return value;
}

永不过期¶

永不过期包含两层含义：

• 从缓存层面来看，确实没有设置过期时间，所以不会出现热点 key 过期后产生的问题，也就是 “物理” 不过期。
• 从功能层面来看，为每个 value 设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存。

作为一个并发量较大的应用，在使用缓存时有三个目标：

1. 加快用户访问速度，提高用户体验。
2. 降低后端负载，减少潜在的风险，保证系统平稳。
3. 保证数据“尽可能”及时更新。

两种热点 key 的解决方法：

第 12 章 Devops 的陷阱¶

Redis 攻击¶

攻击者充分利用 Redis 的 dir 和 dbfilename 两个配置可以使用 config set 动态设置，以及 RDB 持久化的特性，将自己的公钥写入到目标机器的 /root/.ssh/authotrized_keys 文件中，从而实现了对目标机器的攻陷。攻击过程如图。

命令重写¶

Redis 中提供了rename-command命令来重命名命令，我们可以通过该命令将一些危险命令改写，如keys、flushall/flushdb、save、debug(debug reload会重启 Redis)、config、shutdown。同时，rename-command不支持config set，如果 AOF 和 RDB 文件包含了 rename-command 之前的命令，Redis 将无法启动。

rename-command的最佳实践：

• 对于一些危险的命令（例如 flushall），不管是内网还是外网，一律使用 rename-command 配置
• 建议第一次配置 Redis 时，就应该配置 rename-command，因为 renamecommand 不支持 config set。
• 如果涉及主从关系，一定要保持主从节点配置的一致性，否则存在主从数据不一致的可能性。

防火墙¶

可以使用防火墙限制输入和输出的 IP 或者 IP 范围、端口或者端口范围。

很多开发者在一开始看到 bind 的这个配置时都是这么认为的：指定 Redis 只接收来自于某个网段 IP 的客户端请求，但 事实上 bind 指定的是 Redis 和哪个网卡进行绑定，和客户端是什么网段没有关系。

• 如果机器有外网 IP，但部署的 Redis 是给内部使用的，建议去掉外网网卡或者使用 bind 配置限制流量从外网进入。
• 如果客户端和 Redis 部署在一台服务器上，可以使用回环地址（127.0.0.1）。
• bind 配置不支持 config set，所以尽可能在第一次启动前配置好

bigkey¶

危害：

• 内存空间不均匀
• 超时阻塞
• 网络拥塞

bigkey 的存在并不是完全致命的，如果这个 bigkey 存在但是几乎不被访问，那么只有内存空间不均匀的问题存在，相对于另外两个问题没有那么重要紧急，但是如果 bigkey 是一个热点 key（频繁访问），那么其带来的危害不可想象，所以在实际开发和运维时一定要密切关注 bigkey 的存在。

查找热点 Key¶

Redis 中值得我们关注的地方：

• 基础数据类型
• 主从复制
• 哨兵
• 集群
• 如何做到高性能、低复杂度
• 如何保障主从、哨兵、集群的数据一致性

评论