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 的端口号
- 设置 master 的地址和端口，保存 master 信息
- 建立 socket 连接
- 发送 ping 命令（定时器任务）
- 身份验证
- 发送 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 当前的数据库状态
- 请求同步数据
- 创建 RDB 同步数据
- 恢复 RDB 同步数据
- 请求部分同步数据
- 恢复部分同步数据，至此，数据同步工作完成！
最后状态：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 的全量复制操作。内部优化调整方案：
- master 内部创建 master_replid 变量，使用 runid 相同的策略生成，长度 41 位，并发送给所有 slave
- 在 master 关闭时执行命令 shutdowm save，进行 RDB 持久化将 runid 与 offset 保存到 RDB 文件中。repl-id、repl-offset 可以通过 redis-check-rdb 命令查看该信息
- 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 建议设置如下：
- 测算从 master 到 slave 重连平均时长 second
- 获取 master 平均每秒产生写命令数据总量 write_size_per_second
- 最优复制缓冲区空间 = 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 去处理宕机情况
- 服务器列表中挑选备选 master：在线的、响应快的、与原 master 断开时间久的、优先原则(优先级、offset、runid)
- 发送指令(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、数据库全部重启，效果不理想
解决方案：
- 更多的页面静态化处理
- 构建多级缓存架构：Nginx 缓存 + Redis 缓存 + Ehcache 缓存
- 检测Mysq|严重耗时业务进行优化：对数据库的瓶颈排查(例如超时查询、耗时较高事务等)
- 灾难预警机制：监控 Redis 服务器性能指标(CPU占用、CPU使用率、内存容量、查询平均响应时间、线程数)
- 限流、降级：短时间范围内牺牲一些客户体验，限制一部分请求访问，降低应用服务器压力，待业务 低速运转后再逐步放开访问
- LRU 与 LFU 切换
- 数据有效期策略调整：
- 根据业务数据有效期进行分类错峰，A 类 90 分钟、B 类 80 分钟、C 类 70 分钟
- 过期时间使用固定时间 + 随机值的形式，稀释集中到期的 key 的数量
- 超热数据使用永久 key
- 定期维护(自动 + 人工)：对即将过期数据做访问量分析，确认是否延时，配合访问量统计，做热点数据的延时
- 加锁，慎用！
缓存雪崩就是瞬间过期数据量太大，导致对数据库服务器造成压力。如能够有效避免过期时间集中，可以有效解决雪崩现象的出现（约40%），配合其他策略一起使用，并监控服务器的运行数据，根据运行记录做快速调整。
缓存击穿
数据库服务器崩溃：系统平稳运行过程中。数据库连接量瞬间激增。Redis 服务 器无大量 key 过期。Redis 内存平稳，无波动。Redis 服务器 CPU 正常。数据库崩溃
问题排查：Redis 中某个 key 过期，该 key 访问巨大。多个数据请求从服务器直接压到 Redis 后，均未命中。Redis 在短时间内发起了大量对数据库中同一数据的访问
问题分析：单个 key 高热数据。key 过期
解决方案：
- 预先设定：以电商为例，每个商家根据店铺等级，指定若干款主打商品，在购物节期间，加大此类信息 key 的过期时长。注意：购物节不仅仅指当天，以及后续若干天，访问峰值呈现逐渐降低的趋势
- 现场调整：监控访问量，对自然流量激增的数据延长过期时间或设为久性 key
- 后台刷新数据：启动定时任务，高峰期来临之前，刷新数据有效期，确保不丢失
- 二级缓存：设置不同的失效时间，保障不会被同时淘汰就行
- 加锁：分布式锁，防止被击穿，但是要注意也是性能瓶颈，慎重！
缓存击穿就是单个高热数据过期的瞬间，数据访问量较大，未命中 Redis 后，发起了大量对同一数据的数据库访问，导致对数据库服务器造成压力。应对策略应该在业务数据分析与预防方面进行，配合运行监控测试与即时调整策略，毕竟单个 key 的过期监控难度较高，配合雪崩处理策略即可。
缓存穿透
数据库服务器崩溃：系统平稳运行过程中。应用服务器流量随时间增量较大。Redis 服务器命中率随时间逐步降低。Redis 内存平稳，内存无压力。Redis 服务器 CPU 占用激增。数据库服务器压力激增。数据库崩溃
问题排查：Redis 中大面积出现未命中。出现非正常 URL 访问
问题分析：获取的数据在数据库中也不存在，数据库查询未得到对应数据。Redis 获取到 null 数据未进行持久化，直接返回。下次此类数据到达重复上述过程。出现黑客攻击服务器
解决方案：
- 缓存 null：对查询结果为 null 的数据进行缓存（长期使用，定期清理），设定短时限，例如30-60秒，最高 5 分钟
- 白名单策略：
- 提前预热各种分类数据 id 对应的 bitmaps，id 作为 bitmaps 的 offset，相当于设置了数据白名单。当加载正常数据时，放行，加载异常数据时直接拦截（效率偏低）
- 使用布隆过滤器（有关布隆过滤器的命中问题对当前状况可以忽略）
- 实施监控：实时监控 Redis 命中率（业务正常范围时，通常会有一个波动值）与 null 数据的占比。
- 非活动时段波动：通常检测 3-5 倍，超过 5 倍纳入重点排查对象。
- 活动时段波动：通常检测 10-50 倍，超过 50 倍纳入重点排查对象。
- 根据倍数不同，启动不同的排查流程。然后使用名单进行防控（运营）
- 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
