作者:默然b并不是我的选择 | 来源:互联网 | 2023-09-25 20:25
文章目录
- 一. 主从复制
- 二. 哨兵
- 三. 集群
- 四. 常见问题
- 1. 缓存预热
- 2. 缓存雪崩
- 3. 缓存击穿
- 4. 缓存穿透
一. 主从复制
1. 概念
采用多台服务器连接的方案,避免单台服务器宕机导致服务不可用问题。
master(主节点):写,收集数据;
slave (从节点):读,提供数据(写数据禁止);
需要解决的问题:数据同步,需要将master中的数据复制到slave中。
2. 作用
- 实现读写分离,提高服务器读写负载能力;
- 负载均衡,基于主从结构,配合读写分离,由slave分担master负载,提高redis服务器并发量与数据吞吐量;
- 故障恢复,当master出问题,由某一个slave提供服务,当slave出现问题,还有其他的slave;
- 数据冗余,实现数据热备份,是持久化之外的数据冗余方式;
- 高可用:基于主从复制,构建哨兵模式与集群,实现redis的高可用方案。
3. 工作流程
1. 建立连接;(slave连接master)
a. 命令行连接
slaveof masterip masterport
b. 配置文件连接
slaveof masterip masterport
2. 数据同步;master同步slave,包括全量复制 + 部分复制两个部分。
全量复制通过 RDB 进行全量复制后同步,部分复制是将 bgsave 过程中存入复制缓冲区的指令同步给从节点。
在从节点连接上主节点后,数据同步过程会自动执行。
注意,当master数据量很大,bgsave 占用时间过长,导致复制缓冲区指令溢出,则最先存入复制缓冲区的指令将会丢失,后续进行部分复制时发现数据丢失,则redis会重新进行全量复制,导致服务器陷入死循环。因此数据同步尽量避开流量高峰期。
复制缓冲区大小设置:
repl-backlog-size 1mb
3. 命令传播
数据同步之后,后续是通过命令传播来保证数据一致性的。命令传播阶段也可能出现全部复制或部分复制,如网络中断导致数据长时间未同步。
master 接收写指令后,会将指令以字节的形式存储在复制缓冲区(FIFO队列)中,复制缓冲区由偏移量(offset) + 字节值组成,通过offset区分不同slave的数据传播差异。master 记录当前缓冲区的 offset,slave 记录自己接收到数据的 offset。
数据同步 + 命令传播 详细版:
心跳机制:
进入命令传播阶段,master 与 slave 需要进行信息交换,使用心跳机制进行维护,实现双方连接保持在线。
master 心跳:ping 指令,用于判断 slave是否在线;
slave 心跳:replconf ack (offset),汇报自己的 offset,并获取最新的同步数据;同时判断 master 是否在线。
4. 常见问题
频繁的全量复制
缓冲区过小,导致经常进行全量复制,可修改复制缓冲区大小;
频繁的网络中断
a. master CPU过高,或者 slave 频繁下线。
slave 接收到了大量慢查询,如 keys,master 发送心跳时 slave 无响应,导致 master 频繁发送连接请求,CPU占用过高。可设置合理的超时时间(repli-timeout),确认是否释放 slave。
b. slave 与 master 连接断开
master 发送 ping 指令频度较低,master 设置的超时时长过短,ping指令存在丢包等。
数据不一致
多个 slave 数据不同步。可能是网络信息不同步,导致数据发送有延时。
可优化主从间的网络环境,监控主从节点延时(查看offset)。
二. 哨兵
1. 架构搭建
哨兵是一个分布式系统,用来监控 master 的运行情况,并在 master 宕机以后选择一个 slave 作为 master。哨兵也是一台 redis 服务器,只是不对外提供数据服务。哨兵配置数量为通常为单数,保证投票时不会打平。
创建哨兵的配置文件:
port 26379
dir /tmp
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
分别启动1 个 master、2 个 slave、1 个 sentinel,然后将 master 关闭,日志打印情况如下。可以看到哨兵监测到 master 宕机以后选择了 slave 6381 作为master,并完成了master 与 slave 之间的连接和同步。重新启动 6379 以后,该节点变成了 slave。
master 6379:
slave 6380 :
slave 6381:
sentinel 26379:
重新启动 6379:
2. 原理简析
监控阶段
哨兵启动后会向 master、slave 获取状态信息,并同步给其他哨兵。
通知阶段
哨兵不断向 master、slave 发送心跳确认节点健康状态,收到正常状态返回后同步给其他哨兵。
故障转移阶段
- 当 master 宕机以后,sentinel 通知其他 sentinel master 已宕机,当超过半数的 sentinel 都认为 master 宕机后,sentinel 之间会竞选并最后票选出一个哨兵进行故障转移处置。
- sentinel 从服务器列表中寻找节点,排除不在线、响应慢、与 master 断开时间久的,再按照优先原则(比如 offset 小的、runid 小的)选择某个节点作为新的 master。
- 之后 sentinel 向新的 master 发送 slave of no one 指令,向其他 slave 发送 slave of 新 IP 端口。
三. 集群
作用:分散单台服务器的访问及存储压力,并降低宕机带来的业务风险。
方式:将各个 master 相连,对外呈现出单机的效果。
1. 存储设计
集群的每个master都会被分配一段槽编号,数据存储时通过算法设计,将要存储的 key 计算出一个槽值,再放入对应的 master(类似于数据库分库分表操作)。每台 redis 服务器都会存储自己的槽编号以及其他服务器的槽编号,根据此编号进行数据存储。
2. 搭建集群
配置三套一主一从建立集群,端口分别为主(从)—— 6379(6382)、6380(6383)、6381(6384)。
1. 集群配置
redis-6379.conf 配置文件中添加以下配置,然后复制成6份:
cluster-enabled yes
cluster-config-file node-6379.conf
cluster-node-timeout 10000
查看启动情况:
2. 集群连接
redis 5.0.0 以上版本使用 redis-cli 进行集群连接(以下版本使用 redis-trib.rb 太难装了)。其中 –cluster-replicas 1 表示集群连接是一拖一模式,即一个主节点带一个从节点,create 后面则是所有要互连的主从节点IP端口,前半部分是主节点,后半部分是从节点:
redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 --cluster-replicas 1
执行完以后可以看到 logs 文件夹下已经自动生成了 node-6379.conf 配置文件。集群模式下,主节点下线,从节点将在连接超时后自动晋级为主节点,后续主节点上线后,将重新变成从节点。
3. 数据存储
集群模式下,需要使用 redis-cli -c 参数,否则,如果key hash 后计算出的槽值不属于当前连接的主节点,将无法set,-c 之后将会自动重定向到对应的主节点:
四. 常见问题
1. 缓存预热
在 redis 作为数据库缓存的情况下,当 redis 刚启动时,由于 redis 中没有数据,如果此时请求量较大,容易对数据库造成压力。
缓存预热就是将一些高频访问的数据提前加载到 redis 中,避免大量请求同时访问数据库。实际操作过程可以使用脚本导入。
2. 缓存雪崩
缓存雪崩是指系统在运行过程中短时间内出现大量过期 key,redis 无数据向数据库获取数据,从而对数据库造成压力。数据库无法及时响应,从而 redis 请求堆积,数据库请求激增而崩溃,接着 redis 崩溃,应用服务器崩溃。重启无法解决上述问题,因为雪崩的本质是由于 redis 中无缓存数据可用,必须从数据库获取。
解决方式:
- 构造多级缓存(Nginx + redis + ehcache);
- 错开 key 的过期时间,比如设置过期时间为某个时间 + 随机数;
- 监控 key 的访问量,刷新过期时间;
- 超热数据使用永久 key;
- 加锁限流(不推荐)或其他限流方式。
3. 缓存击穿
与缓存雪崩不同的是,缓存击穿是指某个时刻单个高热 key 过期,导致大量请求同时访问数据库中的同一数据,从而对数据库造成压力。
解决方式与雪崩类似:
- 预先错开高峰期的高热 key 过期;
- 监控 key 的访问量,刷新过期时间;
- 多级缓存设置不同的 key 过期时间;
- 加锁限流(不推荐)或其他限流方式。
4. 缓存穿透
缓存穿透通常是短时间内出现大量未命中 key,而这些数据在数据库中也不存在。由于获取不到值这些 key 访问之后也不会存储在 redis 中,下次请求时还将继续请求数据库,导致数据库崩溃。
解决方式:
- 将未获取到的值以 null 的形式存储,可解决单一错误 key 的访问攻击;
- 设置数据白名单,正常数据放行,错误数据拒绝;(比如bitmaps、布隆过滤器,加在 redis 与数据库中间);
- 监控未命中率,使用黑名单防控;
- 对 key 值加密,不符合加密规则的 key 直接过滤(在 redis 前处理)。