原创 itcats_cn 最后发布于 2018-09-05 21:07:27 阅读数 5135 收藏
展开
实现 Redis 高可用机制的一些方法:
保证 Redis 高可用机制需要 Redis 主从复制, Redis 持久化机制, 哨兵机制, keepalived 等的支持.
主从复制的作用: 数据备份, 读写分离, 分布式集群, 实现高可用, 宕机容错机制等.
Redis 主从复制原理
首先主从复制需要分为两个角色: master(主) 和 slave(从) , 注意: Redis 里面只支持一个主, 不像 MySQL,Nginx 主从复制可以多主多从.
1,Redis 的复制功能是支持多个数据库之间的数据同步. 一类是主数据库 (master) 一类是从数据库(slave), 主数据库可以进行读写操作, 当发生写操作的时候自动将数据同步到从数据库, 而从数据库一般是只读的, 并接收主数据库同步过来的数据, 一个主数据库可以有多个从数据库, 而一个从数据库只能有一个主数据库.
2, 通过 Redis 的复制功能可以很好的实现数据库的读写分离, 提高服务器的负载能力. 主数据库主要进行写操作, 而从数据库负责读操作.
主从复制全量同步的过程: 见下图
Redis 主从复制可以根据是否是全量分为全量同步和增量同步
Redis 全量复制一般发生在 Slave 初始化阶段, 这时 Slave 需要将 Master 上的所有数据都复制一份.
全量同步过程:
1: 当一个从数据库启动时, 会向主数据库发送 sync 命令,
2: 主数据库接收到 sync 命令后会开始在后台保存快照(执行 rdb 操作), 并用缓存区记录后续的所有写操作
3: 当主服务器快照保存完成后, Redis 会将快照文件发送给从数据库.
4: 从数据库收到快照文件后, 会丢弃所有旧数据, 载入收到的快照.
5: 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令.
6: 从服务器完成对快照的载入, 开始接收命令请求, 并执行来自主服务器缓冲区的写命令.
增量同步的过程:
Redis 增量复制是指 slave 初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程.
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令, 从服务器接收并执行收到的写命令.
Redis 主从复制全量与增量同步的选择:
主从服务器刚刚连接的时候, 会先进行全量同步; 全同步结束后, 再进行增量同步. 当然, 如果有需要, slave 在任何时候都可以发起全量同步. Redis 策略是, 无论如何, 首先会尝试进行增量同步, 如不成功, 要求从机进行全量同步.
Redis 主从复制如何配置呢?
修改从服务器 Redis/conf 中的 Redis.conf 文件
修改 IP 地址和端口号为主服务器的 IP 和端口
slaveof 10.211.55.9 6379
masterauth 123456--- 如果主 Redis 服务器配置了密码, 则需要配置
只需要配置从服务器的 Redis.conf 即可, 主服务器无需配置. 验证是否成功可以通过 1, 先登录主服务器 Redis-cli 客户端, 输入 info. 若 role 显示 master,slave0 能正常显示从服务器的 ip, 则表示主从服务配置成功, 主从复制配置成功了, 也同时实现了读写分离, 不信? 你看看试试看你的从服务器还能不能写入操作了? 答案是: 不能. 从服务器只有读操作!
Redis 哨兵机制
哨兵机制需要主从复制的支持.
Redis 的哨兵(sentinel) 系统用于管理多个 Redis 服务器, 该系统执行以下三个任务:
. 监控(Monitoring): 哨兵(sentinel) 会不断地检查你的 Master 和 Slave 是否运作正常.
. 提醒(Notification): 当被监控的某个 Redis 出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知.
. 自动故障迁移(Automatic failover): 当一个 Master 不能正常工作时, 哨兵(sentinel) 会开始一次自动故障迁移操作, 它会将失效 Master 的其中一个 Slave 升级为新的 Master, 并让失效 Master 的其他 Slave 改为复制新的 Master; 当客户端试图连接失效的 Master 时, 集群也会向客户端返回新 Master 的地址, 使得集群可以使用 Master 代替失效 Master.
哨兵 (sentinel) 是一个分布式系统, 你可以在一个架构中运行多个哨兵(sentinel) 进程, 这些进程使用流言协议(gossipprotocols) 来接收关于 Master 是否下线的信息, 并使用投票协议 (agreement protocols) 来决定是否执行自动故障迁移, 以及选择哪个 Slave 作为新的 Master.
每个哨兵 (sentinel) 会向其它哨兵(sentinel),master,slave 定时发送消息, 以确认对方是否 "活" 着, 如果发现对方在指定时间(可配置) 内未回应, 则暂时认为对方已挂(所谓的 "主观认为宕机" Subjective Down, 简称 sdown).
若 "哨兵群" 中的多数 sentinel, 都报告某一 master 没响应, 系统才认为该 master"彻底死亡"(即: 客观上的真正 down 机, Objective Down, 简称 odown), 通过一定的 vote 算法, 从剩下的 slave 节点中, 选一台提升为 master, 然后自动修改相关配置.
虽然哨兵(sentinel) 释出为一个单独的可执行文件 Redis-sentinel , 但实际上它只是一个运行在特殊模式下的 Redis 服务器, 你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel).
哨兵(sentinel) 的一些设计思路和 zookeeper 非常类似
单个哨兵(sentinel)
哨兵模式如何配置?
注意: 哨兵机制是 Redis 自带的功能, 不需要接入第三方实现
实现步骤: 哨兵机制端口号默认为 26379
配置之前注意防火墙是否关闭
1. 修改 sentinel.conf 配置文件(该文件存在于 Redis 安装包根目录下)
注意: 初次配置, 不需要打开 #sentinel monitor mymaster 注释, 因为后几行有默认当台服务器为主服务器
原配置: sentinel monitor mymaster 127.0.0.1 6379 2 通过这句来修改为:
sentinel monitor mymaster 10.211.55.3 6379 1 #主服务器名称 IP 端口号 选举次数(Redis 集群服务器不多时可以配置成 1)
2. 修改下一行: sentinel auth-pass mymaster 123456 # 第一个参数 mymaster 为主节点名称, 123456 为主服务器密码.
3. 修改心跳检测 5000 毫秒[默认为 30 秒]
sentinel down-after-milliseconds mymaster 5000
4.sentinel parallel-syncs mymaster 2 --- 指定了在执行故障转移时, 最多可以有多少个从 Redis 实例在同步新的主实例, 在从 Redis 实例较多的情况下这个数字越小, 同步的时间越长, 完成故障转移所需的时间就越长
5. 启动哨兵模式[cd 到 Redis 安装根目录下启动, 因为需要运行 Redis-server]
./Redis-server sentinel.conf --sentinel &
启动后如果打印 + monitor master 主节点名 ip 和 +slave slave ip 则表示启动成功
6. 可以通过模拟 -- 主服务器进入 Redis-cli, 输入 shutdown, 观察哨兵所在服务器日志打印. 原从服务器本不能写操作, 后由于哨兵自动故障迁移把某一个 slave 服务器升级为 master 服务器, 则该升级后的服务器又可以进行写操作.
光靠 Redis 主从复制和哨兵机制不足以实现 Redis 高可用. 为什么呢?
因为若某一节点宕机后, 不会实现自动重启. 最稳健实现高可用的做法 :
Redis 主从复制 + 哨兵机制(监控, 提醒, 自动故障迁移)+keepalived(自动重启), 若重启多次仍不成功, 可以通过邮件短信等方式通知.
----------------
来源: http://www.bubuko.com/infodetail-3478709.html