redis正常停掉_并发编程之Redis：Redis主从架构及哨兵架构

思考

• 如何让Redis能够带来更高的QPS&＃xff1f; 十万&＃43;&＃xff1f;百万&＃43;&＃xff1f;亿并发&＃xff1f;一个系统、一个软件的并发数&＃xff0c;很难给他一个具体的值&＃xff0c;因为有很多的因素会影响到&＃xff1b;比如Redis&＃xff0c;你存的单Key的数据量&＃xff0c;保存数据的数据结构&＃xff0c;CPU的性能&＃xff0c;磁盘的性能等等...当我们需要承载更高访问量的时候&＃xff0c;很容易想到的就以下的方式

redis扩容方式

• 搞更好的机器(垂直扩容)

  • 优点&＃xff1a;简单&＃xff0c;只需要花钱配置一台更好的机器就可以了

  • 缺点&＃xff1a;成本高&＃xff0c;性能越好&＃xff0c;机器越贵&＃xff1b;很容易达到瓶颈&＃xff0c;假如最好的单机能承载20万QPS&＃xff0c;那我现在要达到40万&＃xff0c;怎么办&＃xff1f;&＃xff1b;

• 搞更多的机器(水平扩容)

  • 优点&＃xff1a;成本低&＃xff0c;很容易水平扩展&＃xff0c;随便搞台机器&＃xff0c;加上去就好了&＃xff0c;按需添加&＃xff1b;

  • 缺点&＃xff1a;使用&＃xff0c;维护成本更高&＃xff0c;需要管理一个大的集群&＃xff0c;需要维护更多的机器。

• Redis针对扩展提供的方案

  • 方案一&＃xff1a;主从架构(master slave)

  • 方案二&＃xff1a;集群架构(cluster)

主从架构(master slave)

• 基本结构图

• 作用

  • 实现读写分离&＃xff0c;降低单点服务的压力&＃xff1b;

  • 方便水平扩展&＃xff0c;带来更高的吞吐量&＃xff1b;

  • 为Redis的高可用打好基础&＃xff1b;就单纯的主从架构是没法做到高可用的&＃xff1b;

• 特点

1. master处理完消息之后&＃xff0c;就立马对客户端进行响应

2. 数据是通过异步的方式从master同步到slave

3. slave复制数据的时候&＃xff0c;不会阻塞master的服务

4. slave复制数据的时候&＃xff0c;也不会阻塞自己的读服务

5. slave复制完成之后&＃xff0c;将新的数据加载到内存期间&＃xff0c;会将对外服务暂停

主从架构Redis的搭建

• Redis安装(单机版) https://lupf.cn/articles/2020/04/06/1586153137483.html 当主从所有机器都按上面的方式安装好Redis&＃xff0c;且保证Redis本机下能正常启动之后&＃xff0c;就可以按以下当时做主从配置了

• 主节点配置调整(6379.conf)

  // 1. 第一个参数 bind 就是redis绑定的ip&＃xff0c;默认为127.0.0.1&＃xff1b;意味着只能本机访问&＃xff0c;其他机器访问不了
// 将本机的ip添加进去
bind 192.168.1.140 127.0.0.1

// 2. 第二个参数&＃xff0c;从节点只读&＃xff0c;默认就是打开的&＃xff0c;确认一下
slave-read-only yes

// 3. redis的认证密码
requirepass 123456789
// 设置之后&＃xff0c;客户端可以通过-a参数指定密码连接&＃xff1a;redis-cli -a 123456789
// 或者进去之后通过指令&＃xff1a;auth 123456789 进行认证

// 4. redis的master节点的连接口令
masterauth 123456789


• 从节点配置调整

  // 从节点添加以上主节点的所有配置

// 额外添加项
// 设置主节点的ip端口
// slaveof
slaveof 192.168.1.140 6379


• 检查防火墙

  // 第一种方式&＃xff0c;将防火墙关了

// 第二种方式&＃xff0c;添加端口开放&＃xff1b;如果防火墙开着&＃xff0c;又不配置端口开放&＃xff0c;从节点将无法连接主节点
iptables -A INPUT -ptcp --dport 6379 -j ACCEPT


• 启动服务&＃xff1b;优先启动主节点&＃xff0c;再次依次启动从节点

• 主备状态查看

  info replication


  

• 主备测试

  // 主节点修改&＃xff0c;从节点查询


  

• 压测

  // redis自带提供了压测工具&＃xff0c;位于&＃xff1a;redis-4.0.1/src 下
redis-benchmark -h 192.168.1.140


主从架构存在的问题

• 问题分析 是不是我们做到上面这种架构之后&＃xff0c;咱就可以应对基于redis的高并发、高可用了呢&＃xff1f;其实不然&＃xff01;上面的这种架构只是解决了高并发的问题&＃xff0c;一旦不够了&＃xff0c;水平加上机器(slave)就可以了&＃xff0c;但是还是会存在以下的问题&＃xff1a;

  • 如果是海量数据的Redis存储&＃xff0c;那就只能使用后面要说的Redis集群(Redis Cluster)

  • 如何解决呢&＃xff1f;能不能master挂了之后&＃xff0c;某个slave来接管呢&＃xff1f;当然是可以的&＃xff0c;这就是下面要说的 哨兵模式

  • 问题一&＃xff0c;高可用 上面的架构并没有解决高可用的问题&＃xff0c;假如说Master挂了&＃xff0c;整个Redis等于是不可能了&＃xff1b;虽然说还有从节点在&＃xff0c;但是从节点只能读数据&＃xff0c;没办法写数据&＃xff1b;redis既然主要是用来做缓存的&＃xff0c;缓存却没法更新了&＃xff0c;那就等于是没法正常使用了&＃xff1b;

  • 问题二&＃xff0c;无法应对海量数据 从上面的测试来看&＃xff0c;master和slave的数据是一样的&＃xff0c;slave保存的是master的一个备份&＃xff1b;这样也就意味着&＃xff0c;master能存储多少数据&＃xff0c;整个主从架构也就只能存储多少数据&＃xff1f;无法满足大数据量的要求。

哨兵(sentinal)架构

• 哨兵的功能

1. 集群监控&＃xff1b;负责监控master和slave是否健康存在

2. 消息通知&＃xff1b;当存在节点不可用时&＃xff0c;哨兵将消息通知给管理员

3. 故障迁移&＃xff1b;当master挂了之后&＃xff0c;哨兵会选举一个slave替代master&＃xff0c;实现故障迁移

4. 配置中心&＃xff1b;当slave提升为master&＃xff0c;会将迁移之后的master节点地址通知给客户端(client)

哨兵部署

• 创建配置

  // 创建用于保存哨兵配置文件的目录
mkdir -p /etc/sentinal
mkdir -p /var/sentinal/26379

// 拷贝哨兵
cp /usr/local/redis-4.0.1/sentinel.conf /etc/sentinal/26379.conf

vim /etc/sentinal/26379.conf

// 修改一下配置
// 以守护进程允许
daemonize yes
# 绑定的端口
port 26379
# 绑定的ip 本机IP
bind 192.168.1.140
# 持久化的目录
dir /var/sentinal/26379/
# 这里需要注意的是 所有哨兵节点的IP都是填master的地址
sentinel monitor mymaster 192.168.1.142 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster 123456789
// 在其他两台机器上采用以上相同的方式配置&＃xff0c;除了IP配置成本机


  • monitor 参数说明

    mymaster 给监控的master设置一个别名&＃xff1b;一个哨兵可以监控多个master
192.168.1.142 标识当前主节点
quorum
1. 至少达到多少个哨兵达成一致&＃xff0c;认为master挂了&＃xff0c;才做故障迁移
2. quorum只是作为一个故障识别&＃xff0c;最终的选举还是有哨兵集群一起完成的


  • down-after-milliseconds

    超过多久没连上master&＃xff0c;哨兵就主观认为他挂了


  • failover-timeout

    故障迁移&＃xff0c;切换新的master的超时时间


  • parallel-syncs

    当新的master选出来之后&＃xff0c;每次有多少个slaves去连接master做同步


• 启动

  redis-sentinel /etc/sentinal/26379.conf
// 或者
redis-server /etc/sentinal/26379.conf --sentinel


  

• Sentinel命令

  • PING sentinel回复PONG

  • SENTINEL masters 显示被监控的所有master以及它们的状态.

  • SENTINEL master  显示指定master的信息和状态

  • SENTINEL slaves  显示指定master的所有slave以及它们的状态

  • SENTINEL get-master-addr-by-name  返回指定master的ip和端口&＃xff0c;如果正在进行failover或者failover已经完成&＃xff0c;将会显示被提升为master的slave的ip和端口

  • SENTINEL reset  重置名字匹配该正则表达式的所有的master的状态信息&＃xff0c;清楚其之前的状态信息&＃xff0c;以及slaves信息

  • SENTINEL failover  强制sentinel执行failover&＃xff0c;并且不需要得到其他sentinel的同意。但是failover后会将最新的配置发送给其他sentinel

故障演练

当前192.168.1.142为master节点&＃xff0c;现在我们将其手动停掉&＃xff0c;用来测试故障迁移

redis-cli -h 192.168.1.142 -a 123456789 shutdown


• 故障迁移的步骤

  • 第一步&＃xff0c;单个哨兵主观认为Master挂了(sdown)&＃xff1b;不排除因为网络抖动导致误认为挂了

  • 第二步&＃xff0c;当达到quorum数量的哨兵都认为Master挂了之后&＃xff0c;哨兵集群客观认为Master挂了

  • 第三步&＃xff0c;准备开始做故障迁移

  • 第四步&＃xff0c;哨兵集群开始投票选举新的Master

  • 第五步&＃xff0c;故障迁移至新的Master

  • 第六步&＃xff0c;根据parallel-syncs开始做从节点挂载&＃xff0c;故障迁移完成可以看到&＃xff0c;master已经成功迁移到了新的节点&＃xff1b;

主备切换带来的数据丢失问题

异步复制

• 当客户端想master写了一条数据

• 异步同步还没有做&＃xff0c;master挂了

• 当哨兵集群发现并做了故障迁移

• 新的master中因为异步同步的原因&＃xff0c;导致了部分数据的丢失

脑裂问题

解决方式

min-slaves-to-write 1
min-slaves-max-lag 10
// 表示&＃xff0c;至少有一个salve&＃xff0c;数据复制和同步的延迟不能超过10s&＃xff0c;一旦超过&＃xff0c;master就停止接受任何写请求


码字不易&＃xff0c;感谢您的点赞&＃xff01;关注&＃xff01;评论&＃xff01;&＃xff01;&＃xff01;