Redis主从复制+哨兵机制

424次阅读

共计 1850 个字符，预计需要花费 5 分钟才能阅读完成。

redis 的复制功能是支持多个数据库之间的数据同步。一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。

通过 redis 的复制功能可以很好的实现数据库的读写分离，提高服务器的负载能力。主数据库主要进行写操作，而从数据库负责读操作。

Redis 主从复制 + 哨兵机制

过程：

1：当一个从数据库启动时，会向主数据库发送 sync 命令，

2：主数据库接收到 sync 命令后会开始在后台保存快照（执行 rdb 操作），并将保存期间接收到的命令缓存起来

3：当快照完成后，redis 会将快照文件和所有缓存的命令发送给从数据库。

4：从数据库收到后，会载入快照文件并执行收到的缓存的命令。

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 主从复制 + 哨兵机制