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

最新推荐文章于 2023-02-26 11:10:04 发布

weixin_39970166

最新推荐文章于 2023-02-26 11:10:04 发布

阅读量118

点赞数

文章标签： redis 正常停掉

本文链接：https://blog.csdn.net/weixin_39970166/article/details/111615779

版权

思考

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

redis扩容方式

搞更好的机器(垂直扩容)
- 优点：简单，只需要花钱配置一台更好的机器就可以了
- 缺点：成本高，性能越好，机器越贵；很容易达到瓶颈，假如最好的单机能承载20万QPS，那我现在要达到40万，怎么办？；
搞更多的机器(水平扩容)
- 优点：成本低，很容易水平扩展，随便搞台机器，加上去就好了，按需添加；
- 缺点：使用，维护成本更高，需要管理一个大的集群，需要维护更多的机器。
Redis针对扩展提供的方案
- 方案一：主从架构(master slave)
- 方案二：集群架构(cluster)

主从架构(master slave)

基本结构图
作用
- 实现读写分离，降低单点服务的压力；
- 方便水平扩展，带来更高的吞吐量；
- 为Redis的高可用打好基础；就单纯的主从架构是没法做到高可用的；
特点

master处理完消息之后，就立马对客户端进行响应
数据是通过异步的方式从master同步到slave
slave复制数据的时候，不会阻塞master的服务
slave复制数据的时候，也不会阻塞自己的读服务
slave复制完成之后，将新的数据加载到内存期间，会将对外服务暂停

主从架构Redis的搭建

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

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

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

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

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

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

从节点配置调整

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

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

检查防火墙

// 第一种方式，将防火墙关了

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

启动服务；优先启动主节点，再次依次启动从节点
主备状态查看
```
info replication
```
主备测试
```
// 主节点修改，从节点查询
```

压测

// redis自带提供了压测工具，位于：redis-4.0.1/src 下
redis-benchmark -h 192.168.1.140

主从架构存在的问题

问题分析是不是我们做到上面这种架构之后，咱就可以应对基于redis的高并发、高可用了呢？其实不然！上面的这种架构只是解决了高并发的问题，一旦不够了，水平加上机器(slave)就可以了，但是还是会存在以下的问题：
- 如果是海量数据的Redis存储，那就只能使用后面要说的Redis集群(Redis Cluster)
- 如何解决呢？能不能master挂了之后，某个slave来接管呢？当然是可以的，这就是下面要说的 哨兵模式
- 问题一，高可用上面的架构并没有解决高可用的问题，假如说Master挂了，整个Redis等于是不可能了；虽然说还有从节点在，但是从节点只能读数据，没办法写数据；redis既然主要是用来做缓存的，缓存却没法更新了，那就等于是没法正常使用了；
- 问题二，无法应对海量数据从上面的测试来看，master和slave的数据是一样的，slave保存的是master的一个备份；这样也就意味着，master能存储多少数据，整个主从架构也就只能存储多少数据？无法满足大数据量的要求。

哨兵(sentinal)架构

哨兵的功能

集群监控；负责监控master和slave是否健康存在
消息通知；当存在节点不可用时，哨兵将消息通知给管理员
故障迁移；当master挂了之后，哨兵会选举一个slave替代master，实现故障迁移
配置中心；当slave提升为master，会将迁移之后的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
// 在其他两台机器上采用以上相同的方式配置，除了IP配置成本机

monitor 参数说明

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

down-after-milliseconds

超过多久没连上master，哨兵就主观认为他挂了

failover-timeout

故障迁移，切换新的master的超时时间

parallel-syncs

当新的master选出来之后，每次有多少个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和端口，如果正在进行failover或者failover已经完成，将会显示被提升为master的slave的ip和端口
- SENTINEL reset 重置名字匹配该正则表达式的所有的master的状态信息，清楚其之前的状态信息，以及slaves信息
- SENTINEL failover 强制sentinel执行failover，并且不需要得到其他sentinel的同意。但是failover后会将最新的配置发送给其他sentinel

故障演练

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

redis-cli -h 192.168.1.142 -a 123456789 shutdown

故障迁移的步骤
- 第一步，单个哨兵主观认为Master挂了(sdown)；不排除因为网络抖动导致误认为挂了
- 第二步，当达到quorum数量的哨兵都认为Master挂了之后，哨兵集群客观认为Master挂了
- 第三步，准备开始做故障迁移
- 第四步，哨兵集群开始投票选举新的Master
- 第五步，故障迁移至新的Master
- 第六步，根据parallel-syncs开始做从节点挂载，故障迁移完成可以看到，master已经成功迁移到了新的节点；

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

异步复制

当客户端想master写了一条数据
异步同步还没有做，master挂了
当哨兵集群发现并做了故障迁移
新的master中因为异步同步的原因，导致了部分数据的丢失

脑裂问题

解决方式

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

码字不易，感谢您的点赞！关注！评论！！！

weixin_39970166

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
redis 正常停掉_并发编程之Redis：Redis主从架构及哨兵架构

思考如何让Redis能够带来更高的QPS？十万+？百万+？亿并发？一个系统、一个软件的并发数，很难给他一个具体的值，因为有很多的因素会影响到；比如Redis，你存的单Key的数据量，保存数据的数据结构，CPU的性能，磁盘的性能等等...当我们需要承载更高访问量的时候，很容易想到的就以下的方式redis扩容方式搞更好的机器(垂直扩容)优点：简单，只需要花钱配置一台更好的机器就可以了缺点：...
复制链接

扫一扫