Redis进阶：集群与企业级解决方案

樱花殿张公子

已于 2023-03-28 17:10:16 修改

阅读量375

点赞数

分类专栏：数据库中间件文章标签： redis 数据库分布式存储

于 2020-05-08 19:37:01 首次发布

本文链接：https://blog.csdn.net/qq_43243842/article/details/106004590

版权

数据库中间件专栏收录该内容

4 篇文章 0 订阅

订阅专栏

主从复制

构建一个高可用的系统，全年未宕机时间>99.999%

配置	作用
requirepass ******	设置数据库密码
masterauth ******	记住主数据库的密码
slaveof ip port	从机连接到主机
repl-backlog-size 1mb	slave端失连缓冲区，当一个slave要重连时，不需要完全同步，执行局部同步即可。backlog设置的越大，slave可以失连的时间就越长。
slave-read-only yes	从机只读
slave-serve-stale-data no	从机在主从复制的时候不提供服务
min-slaves-to-write 2	当slave数量少于某个值，master停止写入
min-slaves-max-lag 8	当所有slave的延迟大于等于10s时，master停止写入
repl-backlog-size	修改复制缓冲区大小，避免因为太小而丢数据反复全量复制，推荐设置为 2延迟时间每秒master写入量
repl-timeout 60	master的CPU占用过高/slave频繁断开slave接到了耗时很长的查询命令，master发现slave不响应，master设置合理的超时时间，超时则释放slave
repl-ping-slave-period	slave与master断开连接：master的ping丢包，ping频率低，超时时间很短，应该提高ping的频率，一般超时时间为ping的5-10倍
slave-server-atale-data yes/no	多个slave获取相同数据不同步：如果slave延迟过大，暂时屏蔽slave的数据访问，开启后仅响应info，slaveof等少数命令，慎用，建议slave和master在一个机房

复制缓冲区buffer类似aof格式，它有offset(偏移量)标记不同slave同步到哪个位置

首先slave创建socket连接master
全量复制发生在首次连接：slave发psync ？-1，主机发runid和offset，从机保存主机信息，主机发rdb和buffer，从机更新数据和持久化文件。

部分复制的流程：slave网络中断，数据丢失，向主节点发送psync offset runid，master通过自己的offset和slave的offset进行比对，找出缺失的命令，发给slave，如果缺失的命令过多或无法恢复，则进行全量复制。

命令传输阶段：正常运行时，master收到命令累加offset，slave收到命令累加offset，slave每秒心跳将offset告诉master，master每10秒心跳检测slave是否在线，master发现偏移量不一致则将复制缓冲区中相差的命令向slave传输。

redis4.0中：当slave掉线重连，发送psync2，其中包括原masterId和新msterId，主机检测Id1和Id2是否符合自己的id，如果有一个符合则考虑部分复制，否则认为不是自己的slave全量复制。

放两张图

哨兵

哨兵的任务

监控：哨兵不断地检查master和slave是否正常运行
通知：当某节点出问题向其他
节点发通知
自动故障转移：断开master和slave，选取一个slave作为master，将其他slave连接到新master，告知客户端新的服务器地址
特别的：哨兵也是一台redis服务器，但不提供数据服务，通常哨兵配置数量为单数3个起配

启动哨兵

redis-sentinel xxxx.conf

哨兵的配置

配置	作用
port 26379	端口
dir /tmp	存储目录
sentinel monitor masterName 127.0.0.1 6379 votes	设置监控的master信息判断宕机的哨兵票数
sentinel down-after-milliseconds masterName 30000	认为master掉线的超时时间
sentinel parallel-syncs masterName 1	新master上线后有多少主机进行同步
sentinel failover-timeout masterName 180000	认为数据同步超时的时间

master出现故障推举新master

当master宕机，哨兵开始选举，达到票数的节点升级为master，其他所有节点（包括原master）成为slave连接新master，原master设置为断联状态。

哨兵如何发现所有节点

哨兵监控自己的master，通过与master建立cmd连接，定时获取master的info
获取到master的slave信息后，与slave建立cmd连接
获取到监控master的其他哨兵的信息后，与其他哨兵建立订阅连接同步信息，互相ping

哨兵互相通知

每个哨兵定期获取master的信息，并且在哨兵群中共享，如果发现ping到master超时了，则认为master主观不可用，当一个哨兵被超过半数的哨兵通知“master挂了”，则认为客观上master挂了

故障转移阶段

哨兵互相竞争，广播故障主机的信息，根据收到其他哨兵信息的先后，给延迟最低的哨兵投票，最终多轮投票竞选出议会领袖，领袖负责选择新的master
新的master应该符合以下条件：
在线，响应快，更早与master断开的（树中更靠近根节点的），优先级，较大的offset，较小的runid
选出新master后，向新的master发slaveof no one
向其他slave发送slaveof新masterIP端口

集群

插入与查找底层实现

多个主从结构，master提供读写服务，slave作为备份，多个master分库存储数据，每个数据库存储一部分槽，存储key的时候根据key进行CRC16再%16384生成一个数字，这个数字就是16384个槽中的某个，每个库都记录槽的范围，从而知道这个槽应该是哪个库里的，第一次是随机访问一个库，如果有这个槽就存储，如果没有则查找这个槽在哪个库里面，再告诉客户端去对应的库里插入。
查找也是类似，找槽，如果没有这个槽则看这个槽在哪个库里，再去对应的库查找。

扩容

分出一部分槽到新的库里，然后重写槽分区表。

插入与查找命令实现

登录redis使用 redis-cli -c 集群登录redis，即可直接使用命令对不同的库中的id进行数据操作了

企业级解决方案

缓存预热

系统启动前，提前将热度高的缓存加载到redis中，避免刚开启服务的时候大规模请求数据库。

缓存雪崩

短时间内大量KEY集中过期，数据库收到大量请求无法及时处理，redis也收到大量请求，redis集群崩溃，应用服务器崩溃。
更多的页面静态化
多级缓存架构（Nginx，redis，ehcache）
数据库瓶颈排查（超时查询，耗时较高业务）
灾难预警监控（主机CPU/内存/QPS/线程数）
限流降级
LRU与LFU切换
数据有效期策略调整根据业务进行有效期错峰分类，过期时间使用固定时间+随机值，稀释集中到期的情况
超热数据使用永久key
定期维护，对数据实时检测，看访问量，访问量大则延长失效时间
加锁（慎用）