Redis 集群

三高架构：并发，性能，可用

主从复制

主从复制：将 master 中的数据即时、有效的复制到 slave 中

特征：一个 master 可以拥有多个 slave，一个 slave 只对应一个 master

master 职责：写数据，执行写操作时，将出现变化的数据自动同步到 slave

slave 职责：读数据

主从复制的作用

• 读写分离：master 写、slave 读，提高服务器的读写
• 负载能力负载均衡：基于主从结构，配合读写分离，由 slave 分担 master 负载，并根据需求的变化，改变 slave 的数量，通过多个从节点分担数据读取负载，大大提高 Redis服务器并发量 与数据吞吐量
• 故障恢复：当 master 出现问题时，由 slave 提供服务，实现快速的故障恢复
• 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
• 高可用基石：基于主从复制，构建哨兵模式与集群，实现 Redis 的高可用方案

主从复制工作流程

一、建立连接阶段（即准备阶段）

# 关闭守护进程选项
# slave 连接 master

# 方式一：客户端发送命令
slaveof <masterip> <masterport>
# 方式二：启动服务器参数
redis-server --slaveof <masterip> <masterport>
# 方式三：服务器配置
slaveof <masterip> <masterport>

# slave 系统信息
info
master_link_down_since_seconds
masterhost
masterport

# master 系统信息
info
slave_listening_port(多个)

# 端口连接，客户端发送命令
slaveof no one

建立 slave 到 naster 的连接，使 master 能够识别 slave，并保存 slave 的端口号

1. 设置 master 的地址和端口，保存 master 信息
2. 建立 socket 连接
3. 发送 ping 命令（定时器任务）
4. 身份验证
5. 发送 slave 端口信息到此，主从连接成功！

最后状态：slave 保存了 master 的地址与端口。master 保存了 slave 的端口。主从之间创建了连接的 socket。

授权访问设置

# master 配置文件设置密码
requirepass <password>
# master 客户端发送命令设置密码
config set requirepass <password>
config get requirepass

# slave 客户端发送命令设置密码
auth <password>
# slave 配置文件设置密码
masterauth <password>
# 启动客户端设置密码
redis-cli -a <password>

二、数据同步阶段

在 slave 初次连接 master 后，复制 master 中的所有数据到 slave，将 slave 的数据库状态更新成 master 当前的数据库状态

1. 请求同步数据
2. 创建 RDB 同步数据
3. 恢复 RDB 同步数据
4. 请求部分同步数据
5. 恢复部分同步数据，至此，数据同步工作完成！

最后状态：slave 具有了 master 端全部数据，包含 RDB 过程接收的数据。master 保存了 slave 当前数据同步的位置。主从之间完成了数据克隆。

数据同步阶段 master 说明

• 如果 master 数据量巨大，数据同步阶段应避开流量高峰期，避免造成 master 阻塞，影响业务正常执行
• 复制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的情况，必须进行第二次全量复制，致使 slave 陷入死循环状态。
• 复制缓冲区大小配置：repl-backlog-size 1mb
• master 单机内存占用主机内存的比例不应过大，建议使用 50%-70% 的内存，留下 30%-50% 的内存用于执行 bgsave 命令和创建复制缓冲区

数据同步阶段 slave 说明

• 为避免slave进行全量复制、部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务
• 开启只读服务：slave-read-only yes
• 当主服务器挂掉时是否提供过期数据：slave-serve-stale-data yes I no
• 数据同步阶段，master 发送给 slave 信息可以理解 master 是 slave 的一个客户端，主动向 slave 发送命令
• 多个 slave 同时对 master 请求数据同步，master 发送的 RDB 文件增多，会对带宽造成巨大冲击，如果 master 带宽不足，因此数据同步需要根据业务需求，适量错峰
• slave 过多时，建议调整拓扑结构，由一主多从结构变为树状结构，中间的节点既是 master，也是 slave。注意使用树状结构时，由于层级深度，导致深度越高的 slave 与最顶层 master 间数据同步延迟较大，数据一致性变差，应谨慎选择

三、命令传播阶段

命令传播阶段出现了断网现象

• 网络闪断闪连：忽略
• 短时间网络中断：部分复制
• 长时间网络中断：全量复制

部分复制的三个核心要素

• 服务器的运行 id（run id）
  • 概念：服务器运行 ID 是每一台服务器每次运行的身份识别码，一台服务器多次运行可以生成多个运行 id
  • 组成：运行 id 由 40 位字符组成，是一个随机的十六进制字符例如：fdc9ff13b9dfgab28db42lo35sde52bb5e3fcdce
  • 作用：运行 id 被用于在服务 器间进行传输，识别身份如果想两次操作均对同一台服务器进行，必须每次操作携带对应的运行 id，用于对方识别
  • 实现方式：运行 id 在每台服务器启动时自动生成的，master 在首次连接 slave 时，会将自己的运行 ID 发送给 slave，slave 保存此 ID，通过 info server 命令，可以查看节点的 runid
• 主服务器的复制积压缓冲区
  • 概念：复制缓冲区，又名复制积压缓冲区，是一个先进先出（FIFO）的队列，用于存储服务器执行过的命令，每次传播命令，master 都会将传播的命令记录下来，并存储在复制缓冲区。复制缓冲区默认数据存储空间大小是1M，由于存储空间大小是固定的，当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列
  • 由来：每台服务器启动时，如果开启有 AOF 或被连接成为 master 节点，即创建复制缓冲区
  • 作用：用于保存 master 收到的所有指令（仅影响数据变更的指令，例如 set，select）
  • 数据来源：当 master 接收到主客户端的指令时，除了将指令执行，会将该指令存储到缓冲区中
  • 
• 主从服务器的复制偏移量（offset）
  • 概念：一个数字，描述复制缓冲区中的指令字节位置
  • 分类：
    • master 复制偏移量：记录发送给所有 slave 的指令字节对应的位置（多个）
    • slave 复制偏移量：记录 slave 接收 master 发送过来的指令字节对应的位置（一个）
  • 数据来源：
    • master 端：发送一次记录一次
    • slave 端：接收一次记录一次
  • 作用：同步信息，比对 master 与 slave 的差异，当 slave 断线后，恢复数据使用

心跳机制

进入命令传播阶段候，master 与 slave 间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线

master 心跳：

• 指令：PING
• 周期：由 repl-ping-slave-period 决定，默认 10 秒
• 作用：判断 slave 是否在线
• 查询：INFO replication 获取 slave 最后一次连接时间间隔，lag 项维持在 0 或 1 视为正常

slave 心跳任务

• 指令：REPLCONF ACK{offset}
• 周期：1 秒
• 作用 1：汇报 slave 自己的复制偏移量，获取最新的数据变更指令
• 作用 2：判断 master 是否在线

心跳阶段注意事项

• 当 slave 多数掉线，或延迟过高时，master 为保障数据稳定性，将拒绝所有信息同步操作
  • min-slaves-to-write 2
  • min-slaves-max-lag 8
  • slave 数量少于 2 个，或者所有 slave 的延迟都大于等于 10 秒时，强制关闭 master 写功能，停止数据同步
• slave 数量由 slave 发送 REPLCONF ACK 命令做确认
• slave 延迟由 slave 发送 REPLCONF ACK 命令做确认

综上主从复制完整工作流程

主从复制常见问题

频繁的全量复制

伴随着系统的运行，master 的数据量会越来越大，一旦 master 重启，runid 将发生变化，会导致全部 slave 的全量复制操作。内部优化调整方案：

1. master 内部创建 master_replid 变量，使用 runid 相同的策略生成，长度 41 位，并发送给所有 slave
2. 在 master 关闭时执行命令 shutdowm save，进行 RDB 持久化将 runid 与 offset 保存到 RDB 文件中。repl-id、repl-offset 可以通过 redis-check-rdb 命令查看该信息
3. master 重启后加载 RDB 文件，恢复数据。重启后，将 RDB 文件中保存的 repl-id 与 repl-offset 加载到内存中。master_repl_id = repl、master_repl_offset = repl-offset 可以通过 info 命令查看该信息

作用：本机保存上次 runid，重启后恢复该值，使所有 slave 认为还是之前的 master

频繁的全量复制

问题现象：网络环境不佳，出现网络中断，slave不提供服务

问题原因：复制缓冲区过小，断网后 slave 的 offset 越界，触发全量复制

最终结果：slave 反复进行全量复制

解决方案：修改复制缓冲区大小。repl--backlog-size 建议设置如下：

1. 测算从 master 到 slave 重连平均时长 second
2. 获取 master 平均每秒产生写命令数据总量 write_size_per_second
3. 最优复制缓冲区空间 = 2 * second * write_size_per_second

频繁的网络中断

问题现象：master 的 CPU 占用过高或 slave 频繁断开连接

问题原因：

• slave 每 1 秒发送 REPLCONE ACK 命令到 master
• 当 slave 接到了慢查询时（keys *，hgetall 等），会大量占用 CPU 性能
• master 每1秒调用复制定时函数 replicationCron()，比对 slave 发现长时间没有进行响应

最终结果：master 各种资源（输出缓冲区、带宽连接等）被严重占用

解决方案：通过设置合理的超时时间，确认是否释放 slave，repl-timeout 参数定义了超时时间的阈值（默认60秒），超过该值，释放 slave

频繁的网络中断

问题现象：slave 与 master 连接断开

问题原因：

• master 发送 ping 指令频度较低
• master 设定超时时间较短
• ping 指令在网络中存在丢包

解决方案：提高 ping 指令发送的频度，设置 repl-ping-slave-period。超时时间 repl-time 至少是 ping 指令频度的 5 到 10 倍，否则 slave 很容易判定超时

数据不一致

问题现象：多个 slave 获取相同数据不同步

问题原因：网络信息不同步，数据发送有延迟

解决方案：

• 优化主从间的网络环境，通常放置在同-一个机房部署，如使用阿里云等云服务器时要注意此现象
• 监控主从节点延迟（通过 offset）判断，如果 slave 延迟过大，暂时屏蔽程序对该 slave 的数据访问。slave-serve-stale-data yes | no，开启后仅响应 info、slaveof 等少数命令（慎用，除非对数据一致性要求很高）

哨兵

哨兵（sentinel）是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的 master 并将所有 slave 连接到新的 master。

哨兵作用

监控：不断的检查 master 和 slave 是否正常运行。master 存活检测、master 与 slave 运行情况检测

通知（提醒）：当被监控的服务器出现问题时，向其它（哨兵间，客户端）发送通知。

自动故障转移：断开 master 与 slave 连接，选取一个 slave 作为 master，将其它 slave 连接到新的 master，并告知客户端新的服务器地址。

注意：哨兵也是一台 redis 服务器，只是不提供数据服务，通常哨兵配置数量为单数(尽量避免投票持平的情况)。

哨兵搭建

cat sentinel.conf | grep -v '#' | grep -v '^$'
sed 's/要被取代的字串/新的字串/g' sentinel-6379.conf > sentinel-6380.conf

# 配置
port 26379
dir /opt/redis
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster1
sentinel failover-timeout mymaster 180000

# 启动
redis-sentinel sentinel-端口号.conf

哨兵工作流程

一、监控阶段

用于同步各个节点的状态信息

• 获取各个 sentinel 的状态（是否在线）
• 获取 master 的状态：master 属性(runid、role：master）、各个 slave 的详细信息
• 获取所有 slave 的状态（根据 master 中的 slave 信息）：slave 属性(runid、role：slave、master_host、master_port、offset...)

二、通知阶段

维护长期的信息对等

三、故障转移阶段

1、发现和确认节点已宕机

2、sentinel 集群会投票选举出一个 sentinel 去清除已宕机节点

3、被选出的 sentinel 去处理宕机情况

1. 服务器列表中挑选备选 master：在线的、响应快的、与原 master 断开时间久的、优先原则(优先级、offset、runid)
2. 发送指令(sentinel)：向新的 master 发送 slaveof no one，其它 slave 发送 slaveof 新 master IP 端口

集群

将多个主从连接在一起，分散单台服务器的访问压力，实现负载均衡。分散单台服务器的存储压力，实现可扩展性。降低单台服务器宕机带来的业务灾难。

存储设计

Redis 集群的分片特征在于通过算法(CRC16 再 %16384)设计，计算出 key 应该保存的位置。将所有的存储空间拆分为 16384 个槽位，某一个节点负责其中一些槽位。将 key 按照计算出的结果放到对应的槽位。

每个节点都知道其它节点槽的范围，当增加节点时，现有的节点会转移一部分槽到新节点上，对应的槽中的数据也会过去。所以增减节点只是改变槽的位置。

当要查找 key 不在当前节点时，会告诉客户端(重定向)去连接正确的节点查询 key，而不是充当中转的角色。即最多两次就能命中要查找的数据。

集群搭建

每台节点的配置都是一样的，然后启动 Redis 即可

port 6379
daemonize no
dir /opt/redis
dbfilename dump-6379.rdb
rdbcompression yes
rdbchecksum yes
save 10 2
appendonly yes
appendfsync always
appendfilename appendonly-6379.aof
bind 127.0.0.1
databases 16

# 集群节点配置
# 设置加入cluster，成为其中的节点
cluster-enabled yes
# 配置文件名，该文件属于自动生成，仅用于快速查找文件并查询文件内容
cluster-config-file nodes-6379.conf
# 节点服务响应超时时间，用于判定该节点是否下线或切换为从节点
cluster-node-timeout 10000
# master 连接的 slave 最小数量
# cluster-migration-barrier <count>

所有 Redis 启动好后，再配置集群

# 把所有节点的 IP 和 PORT 都写上，注意节点之间是否能连通
# --cluster-replicas 1：表示希望为集群中的每个主节点创建一个从节点(一主一从)
# --cluster-replicas 2：表示希望为集群中的每个主节点创建两个从节点(一主二从)
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1

# 期间会询问是否使用上述配置，输入 yes 即可
# 最后会看到所有的 slot 成功分配

# 连接集群
redis-cli -c -p 7000

# 查看集群节点信息
cluster nodes
# 进入一个从节点 redis，切换其主节点
cluster replicate <master-id>
# 发现一个新节点，新增主节点
cluster meet ip:port
# 忽略一个没有 solt 的节点
cluster forget <id>
# 手动故障转移
cluster failover

主从下线与切换

从节点下线后对集群不影响，只是标记一下从节点不能用了，当从节点恢复后就再修改一下标记为可用。

主节点下线后，从节点会按照配置文件的超时时间去连接主节点(一秒一次)，超过时间还连接不上主节点，就把自己升级为主节点。

当掉线的主节点重新连接后会变为从节点。

对于其它主从节点来说只是维护一下节点信息，但是对于掉线的主从节点还会进行数据同步操作。

解决方案

缓存预热

现象：服务器启动后迅速宕机

问题排查：请求数量较高。主从之间数据吞吐量较大，数据同步操作频度较高

解决方案：日常例行统计数据访问记录，统计访问频度较高的热点数据。利用 LRU 数据删除策略，构建数据留存队列，例如：storm 与 kafka 配合。将统计结果中的数据分类，根据级别，Redis 优先加载级别较高的热点数据。利用份布式多服务器同时进行数据读取，提速数据加载过程。使用脚本程序固定触发数据预热过程。如果条件允许，使用 CDN（内容分发网络），效果会更好

缓存预热就是系统启动前，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！

让用户直接查询事先被预热的缓存数据！

缓存雪崩

数据库服务器崩溃：系统平稳运行过程中，忽然数据库连接量激增。应用服务器无法及时处理请求。大量 408，500 错误页面出现。客户反复刷新页面获取数据。数据库崩溃。应用服务器崩溃。重启应用服务器无效。Redis 服务器崩溃。Redis 集群崩溃。重启数据库后再次被瞬间流量放倒

问题排查：在一个较短的时间内，缓存中较多的 key 集中过期。此周期内请求访问过期的数据，Redis 未命中，Redis 向数据库获取数据。数据库同时接收到大量的请求无法及时处理。Redis 大量请求被积压，开始出现超时现象。数据库流量激增，数据库崩溃。重启后仍然面对缓存中无数据可用。Redis 服务 器资源被严重占用，Redis 服务器崩溃。Redis 集群呈现崩塌，集群瓦解。应用服务器无法及时得到数据响应请求，来自客户端的请求数量越来越多，应用服务器崩溃。应用服务器、Redis、数据库全部重启，效果不理想

解决方案：

1. 更多的页面静态化处理
2. 构建多级缓存架构：Nginx 缓存 + Redis 缓存 + Ehcache 缓存
3. 检测Mysq|严重耗时业务进行优化：对数据库的瓶颈排查(例如超时查询、耗时较高事务等)
4. 灾难预警机制：监控 Redis 服务器性能指标(CPU占用、CPU使用率、内存容量、查询平均响应时间、线程数)
5. 限流、降级：短时间范围内牺牲一些客户体验，限制一部分请求访问，降低应用服务器压力，待业务 低速运转后再逐步放开访问
6. LRU 与 LFU 切换
7. 数据有效期策略调整：
   • 根据业务数据有效期进行分类错峰，A 类 90 分钟、B 类 80 分钟、C 类 70 分钟
   • 过期时间使用固定时间 + 随机值的形式，稀释集中到期的 key 的数量
8. 超热数据使用永久 key
9. 定期维护(自动 + 人工)：对即将过期数据做访问量分析，确认是否延时，配合访问量统计，做热点数据的延时
10. 加锁，慎用！

缓存雪崩就是瞬间过期数据量太大，导致对数据库服务器造成压力。如能够有效避免过期时间集中，可以有效解决雪崩现象的出现（约40%），配合其他策略一起使用，并监控服务器的运行数据，根据运行记录做快速调整。

缓存击穿

数据库服务器崩溃：系统平稳运行过程中。数据库连接量瞬间激增。Redis 服务 器无大量 key 过期。Redis 内存平稳，无波动。Redis 服务器 CPU 正常。数据库崩溃

问题排查：Redis 中某个 key 过期，该 key 访问巨大。多个数据请求从服务器直接压到 Redis 后，均未命中。Redis 在短时间内发起了大量对数据库中同一数据的访问

问题分析：单个 key 高热数据。key 过期

解决方案：

1. 预先设定：以电商为例，每个商家根据店铺等级，指定若干款主打商品，在购物节期间，加大此类信息 key 的过期时长。注意：购物节不仅仅指当天，以及后续若干天，访问峰值呈现逐渐降低的趋势
2. 现场调整：监控访问量，对自然流量激增的数据延长过期时间或设为久性 key
3. 后台刷新数据：启动定时任务，高峰期来临之前，刷新数据有效期，确保不丢失
4. 二级缓存：设置不同的失效时间，保障不会被同时淘汰就行
5. 加锁：分布式锁，防止被击穿，但是要注意也是性能瓶颈，慎重！

缓存击穿就是单个高热数据过期的瞬间，数据访问量较大，未命中 Redis 后，发起了大量对同一数据的数据库访问，导致对数据库服务器造成压力。应对策略应该在业务数据分析与预防方面进行，配合运行监控测试与即时调整策略，毕竟单个 key 的过期监控难度较高，配合雪崩处理策略即可。

缓存穿透

数据库服务器崩溃：系统平稳运行过程中。应用服务器流量随时间增量较大。Redis 服务器命中率随时间逐步降低。Redis 内存平稳，内存无压力。Redis 服务器 CPU 占用激增。数据库服务器压力激增。数据库崩溃

问题排查：Redis 中大面积出现未命中。出现非正常 URL 访问

问题分析：获取的数据在数据库中也不存在，数据库查询未得到对应数据。Redis 获取到 null 数据未进行持久化，直接返回。下次此类数据到达重复上述过程。出现黑客攻击服务器

解决方案：

1. 缓存 null：对查询结果为 null 的数据进行缓存（长期使用，定期清理），设定短时限，例如30-60秒，最高 5 分钟
2. 白名单策略：
   • 提前预热各种分类数据 id 对应的 bitmaps，id 作为 bitmaps 的 offset，相当于设置了数据白名单。当加载正常数据时，放行，加载异常数据时直接拦截（效率偏低）
   • 使用布隆过滤器（有关布隆过滤器的命中问题对当前状况可以忽略）
3. 实施监控：实时监控 Redis 命中率（业务正常范围时，通常会有一个波动值）与 null 数据的占比。
   • 非活动时段波动：通常检测 3-5 倍，超过 5 倍纳入重点排查对象。
   • 活动时段波动：通常检测 10-50 倍，超过 50 倍纳入重点排查对象。
   • 根据倍数不同，启动不同的排查流程。然后使用名单进行防控（运营）
4. key 加密：问题出现后，临时启动防灾业务 key，对 key 进行业务层传输加密服务，设定校验程序，过来的 key 校验。例如每天随机分配 60 个加密串，挑选 2-3 个，混淆到页面数据 id 中，发现访问 key 不满足规则，驳回数据访问

缓存击穿访问了不存在的数据，跳过了合法数据的 Redis 数据缓存阶段，每次访问数据库，导致对数据库服务器造成压力。通常此类数据的出现量是一个较低的值，当出现此类情况以毒攻毒，并及时报警。应对策略应该在临时预案防范方面多做文章。

无论是黑名单还是白名单，都是对整体系统的压力，警报解除后尽快移除。

性能监控

性能指标：Performance

• latency：Redis 响应一个请求的时间
• instantaneous_ops_per_sec：平均每秒处理请求总数
• hit rate（calculated）：缓存命中率（计算出来的）

内存指标：Memory

• used_memory：已使用内存
• mem_fragmentation_ratio：内存碎片率
• evicted_keys：由于最大内存限制被移除的 key 的数量
• blocked_clients：由于 BLPOP、BRPOP、or BRPOPLPUSH 而被阻塞的客户端

基本活动指标：Basic Activity

• connected_clients：客户端连接数
• connected slaves：Slave 数量
• master_last_io_seconds_ago：最近一次主从交互之后的秒数
• keyspace：数据库中的 key 值总数

持久性指标：Persistence

• rdb_last_save_time：最后一次持久化保存到磁盘的时间戳
• rdb_changes_since_last_save：自最后一次持久化以来数据库的更改数

错误指标：Error

• rejected_connections：由于达到 maxclient 限制而被拒绝的连接数
• keyspace_misses：Key 值查找失败（没有命中）次数
• master_link_down_since_seconds：主从断开的持续时间（以秒为单位）

监控方式

• 工具：Cloud Insight Redis、Prometheus、Redis-stat、Redis-faina、RedisLive、zabbix
• 命令：benchmark、redis cli、monitor、showlog

命令和配置

# benchmark，注意不是 Redis 命令
# -h 指定服务器主机名，默认值 127.0.0.1
# -p 指定服务器端口，默认值 6379
# -S 指定服务器 socket
# -C 指定并发连接数，默认值 50
# -n 指定请求数，默认值 10000
# -d 以字节的形式指定 SET/GET 值的数据大小，默认值 2
# -k 1=keepalive，0 = reconnect，默认值 1
# -r SET/GET/INCR 使用随机 key，SADD 使用随机值
# -P 通过管道传输 <numreq> 请求，默认值 1
# -q 强制退出 redis，仅显示 query/sec 值
# --CSV 以 CSV 格式输出
# -l 生成循环，永久执行测试
# -t 仅运行以逗号分隔的测试命令列表
# -i Idle模式。仅打开 N 个 Idle 连接并等待
# redis-benchmark [-h] [-P] [-c] [-n <requests]> [-k]

# 50 个连接，10000 次请求对应的性能
redis-benchmark
# 100 个连接，5000 次请求对应的性能
redis-benchmark -c 100 -n 5000

# 打印服务器调试信息，Redis 命令
monitor

# get：获取慢查询日志，len：获取慢查询日志条目数，reset：重置慢查询日志
s1ow1og [operator]

# Redis 相关配置
# 设置慢查询的时间下线，单位：微妙
slowlog-log-slower-than 1000
# 设置慢查询命令对应的日志显示长度，单位：命令数
slowlog-max-len 100

---

https://redis.io/topics/replication

https://redis.io/topics/sentinel

https://redis.io/topics/cluster-tutorial

https://redis.io/topics/cluster-spec