Redis高可用
https://www.cnblogs.com/bingshu/p/9776610.html
Redis高可用概述
在 Web
服务器中,高可用 是指服务器可以 正常访问 的时间,衡量的标准是在 多长时间 内可以提供正常服务(99.9%
、99.99%
、99.999%
等等)。
在 Redis
层面,高可用 的含义要宽泛一些,除了保证提供 正常服务(如 主从分离、快速容灾技术 等),还需要考虑 数据容量扩展、数据安全 等等。
在 Redis
中,实现 高可用 的技术主要包括 持久化、复制、哨兵 和 集群,下面简单说明它们的作用,以及解决了什么样的问题:
-
持久化:持久化是 最简单的 高可用方法。它的主要作用是 数据备份,即将数据存储在 硬盘,保证数据不会因进程退出而丢失。
-
复制:复制是高可用
Redis
的基础,哨兵 和 集群 都是在 复制基础 上实现高可用的。复制主要实现了数据的多机备份以及对于读操作的负载均衡和简单的故障恢复。缺陷是故障恢复无法自动化、写操作无法负载均衡、存储能力受到单机的限制。 -
哨兵:在复制的基础上,哨兵实现了 自动化 的 故障恢复。缺陷是 写操作 无法 负载均衡,存储能力 受到 单机 的限制。
-
集群:通过集群,
Redis
解决了 写操作 无法 负载均衡 以及 存储能力 受到 单机限制 的问题,实现了较为 完善 的 高可用方案。
Redis主从复制搭建
准备三台服务器
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
192.168.31.128 192.168.31.129 192.168.31.130
安装Redis,详细参考https://www.cnblogs.com/miye/p/12165165.html
将128服务期设为主服务器
主节点需加入一下配置
# 主节点认证密码,如果设置了密码,就要设置
masterauth 123456
将129 130 服务器设置为从服务器
从节点需要加入以下配置
# 从节点要跟随的主节点 slaveof 192.168.31.128 6397 # 主节点认证密码,如果设置了密码,就要设置 masterauth 123456
如果要做 自动故障转移,建议所有的 redis.conf
都设置 masterauth
。因为 自动故障 只会重写 主从关系,即 slaveof
,不会自动写入 masterauth
。如果 Redis
原本没有设置密码,则可以忽略。
配置完成后重启三台服务器Redis服务
查看master信息
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
192.168.31.128:0>INFO Replication "# Replication role:master connected_slaves:2 slave0:ip=192.168.31.129,port=6379,state=online,offset=950,lag=1 slave1:ip=192.168.31.130,port=6379,state=online,offset=950,lag=1 master_replid:1464d0fb6b8c7b19e104fb09f2de573191c2513c master_replid2:0000000000000000000000000000000000000000 master_repl_offset:950 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:950
查看slave信息
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
192.168.31.129:0>INFO Replication "# Replication role:slave master_host:192.168.31.128 master_port:6379 master_link_status:up master_last_io_seconds_ago:8 master_sync_in_progress:0 slave_repl_offset:1020 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:1464d0fb6b8c7b19e104fb09f2de573191c2513c master_replid2:0000000000000000000000000000000000000000 master_repl_offset:1020 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:1020
Redis主从复制的问题
Redis
主从复制 可将 主节点 数据同步给 从节点,从节点此时有两个作用:
- 一旦 主节点宕机,从节点 作为 主节点 的 备份 可以随时顶上来。
- 扩展 主节点 的 读能力,分担主节点读压力。
主从复制 同时存在以下几个问题:
-
一旦 主节点宕机,从节点 晋升成 主节点,同时需要修改 应用方 的 主节点地址,还需要命令所有 从节点 去 复制 新的主节点,整个过程需要 人工干预。
-
主节点 的 写能力 受到 单机的限制。
-
主节点 的 存储能力 受到 单机的限制。
-
原生复制 的弊端在早期的版本中也会比较突出,比如:
Redis
复制中断 后,从节点 会发起psync
。此时如果 同步不成功,则会进行 全量同步,主库 执行 全量备份 的同时,可能会造成毫秒或秒级的 卡顿。
启用redis-sentinel
复制redis解压后的文件夹下的sentinel.conf至 /usr/local/redis/etc目录下
修改sentinel.conf文件
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
# bind注释掉,需要在外网访问,将protected-model改为no protected-mode no # 后台运行 daemonize yes # sentinel monitor <master-name> <ip> <redis-port> <quorum> # 配置sentinel监控的master # sentinel监控的master的名字叫做mymaster,地址为127.0.0.1:6379 # sentinel在集群式时,需要多个sentinel互相沟通来确认某个master是否真的死了; # 数字2代表,当集群中有2个sentinel认为master死了时,才能真正认为该master已经不可用了。 sentinel monitor mymaster 192.168.31.128 6379 2 # sentinel auth-pass <master-name> <password> # sentinel author-pass定义服务的密码,mymaster是服务名称,123456是Redis服务器密码 sentinel auth-pass mymaster 123456 # sentinel down-after-milliseconds <master-name> <milliseconds> # sentinel会向master发送心跳PING来确认master是否存活 # 如果master在“一定时间范围”内不回应PONG或者是回复了一个错误消息 # 那么这个sentinel会主观地认为这个master已经不可用了(SDOWN) # 而这个down-after-milliseconds就是用来指定这个“一定时间范围”的,单位是毫秒。 sentinel down-after-milliseconds mymaster 30000 # sentinel parallel-syncs <master-name> <numreplicas> # 在发生failover主备切换时,这个选项指定了最多可以有多少个slave同时对新的master进行同步 # 这个数字越小,完成failover所需的时间就越长 # 但是如果这个数字越大,就意味着越多的slave因为replication而不可用。 # 可以通过将这个值设为 1 来保证每次只有一个slave处于不能处理命令请求的状态。 sentinel parallel-syncs mymaster 1 # sentinel failover-timeout <master-name> <milliseconds> # 实现主从切换,完成故障转移的所需要的最大时间值。 # 若Sentinel进程在该配置值内未能完成故障转移的操作,则认为本次故障转移操作失败。 sentinel failover-timeout mymaster 180000 # 指定Sentinel进程检测到Master-Name所指定的“Master主服务器”的实例异常的时候,所要调用的报警脚本。 # sentinel notification-script mymaster <script-path> # 安全 # 避免脚本重置,默认值yes # 默认情况下,SENTINEL SET将无法在运行时更改notification-script和client-reconfig-script。 # 这避免了一个简单的安全问题,客户端可以将脚本设置为任何内容并触发故障转移以便执行程序。 sentinel deny-scripts-reconfig yes
启动
bin/redis-sentinel /usr/local/redis/etc/sentinel.conf &
其他两台节点相同操作
reids-sentinel相关https://www.cnblogs.com/miye/p/12166851.html
redis-sentinel解决了redis主从复制主节点宕机 需要人工干预恢复 的缺点 未解决单机存储能力和写能力受限制的缺点