9 redis架构

• 单机版本
• replication（主从）架构
• Sentinel（哨兵）模式 配置

单机版本

仅使用一台服务器

replication（主从）架构

• ⼀个master可以拥有多个slave，⼀个slave⼜可以拥有多个slave，如此下去，形成了强⼤的多级服务器集群架构
• master用来写数据，slave用来读数据，经统计：网站的读写比率是10:1
• 通过主从配置可以实现读写分离
• master和slave都是一个redis实例(redis服务)
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fkLy2nWJ-1581686306751)(:storage\d9e4d188-08c3-454a-bd6e-421e6c278dd8\29d5b0b3.png)]

配置主
1、修改绑定ip和端

bind zhu_IP

2、重启服务器

配置从
复制配置文件为slave.conf
修改从配置文件

bind （本机）IP
slaveof IP port(主)
port (本机)6378

启动redis服务

• 查看主从关系

redis-cli -h 192.168.26.128 info Replication

数据操作
1、在master和slave分别执⾏info命令，查看输出信息 进入主客户端
redis-cli -h 192.168.26.128 -p 6379
2、进入从的客户端
redis-cli -h 192.168.26.128 -p 6378
3、在master上写数据
4、从客户端读取数据

• 缺点：主从复制架构不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复

Sentinel（哨兵）模式

在主从复制的支持下，搭建哨兵系统，执行一下三个任务：

• 监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常
• 提醒(Notification):当被监控的某个Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知
• 自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master

哨兵本质上是一个分布式系统，可以在一个架构中运行多个哨兵进程，这些进程通过流言协议接收关于master的信息，并使用投票协议来决定是否自动故障迁移，以及决定哪个slave作为master

• 每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown)
• 多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.

配置

1. 修改sentinel.conf文件

sentinel monitor mymaster 10.211.55.3 6379 1
#主服务器名称 IP 端口号 选举次数(redis集群服务器不多时可以配置成1)

1. sentinel auth-pass mymaster 123456 # 第一个参数mymaster为主节点名称，123456为主服务器密码

2. 修改心跳检测 5000毫秒[]默认为30秒]

sentinel down-after-milliseconds mymaster 5000

1. sentinel parallel-syncs mymaster 2 — 指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长

2. 启动哨兵模式 [cd到redis安装根目录下启动，因为需要运行redis-server]

• 启动后如果打印+ monitor master 主节点名 ip 和 +slave slave ip则表示启动成功

• 点赞
• 收藏
• 分享
• 文章举报