主从 | Final

redis 主从

虽然 Redis 可以实现单机的数据持久化，但无论是 RDB 也好或者 AOF 也好，都解决不了单点宕机问题，即一旦 redis 服务器本身出现系统故障、硬件故障等问题后，就会直接造成数据的丢失，因此需要使用另外的技术来解决单点问题

配置 reids 主从主备模式，可以实现 Redis 数据的跨主机备份。程序端连接到高可用负载的 VIP，然后连接到负载服务器设置的 Redis 后端 real server，此模式不需要在程序里面配置 Redis 服务器的真实 IP 地址，当后期 Redis 服务器 IP 地址发生变更只需要更改 redis相应的后端 real server 即可，可避免更改程序中的 IP 地址设置

Slave 主要配置Redis Slave 也要开启持久化并设置和 master 同样的连接密码，因为后期 slave 会有提升为 master 的可能,Slave 端切换 master 同步后会丢失之前的所有数据 一旦某个 Slave 成为一个 master 的 slave，Redis Slave 服务会清空当前 redis 服务器上的所有数据并将master 的数据导入到自己的内存，但是断开同步关系后不会删除当前已经同步过的数据

命令行配置方法当前状态为 master，需要转换为 slave 角色并指向 master 服务器的 IP+PORT+Password

主从复制过程 Redis 支持主从复制分为全量同步和增量同步，首次同步是全量同步，主从同步可以让从服务器从主服务器备份数据，而且从服务器还可与有从服务器，即另外一台 redis 服务器可以从一台从服务器进行数据同步，redis 的主从同步是非阻塞的，其收到从服务器的 sync(2.8 版本之前是 PSYNC)命令会fork 一个子进程在后台执行 bgsave 命令，并将新写入的数据写入到一个缓冲区里面，bgsave 执行完成之后并生成的将 RDB 文件发送给客户端，客户端将收到后的 RDB 文件载入自己的内存，然后主 redis将缓冲区的内容在全部发送给从 redis，之后的同步从服务器会发送一个 offset 的位置(等同于 MySQL的 binlog 的位置)给主服务器，主服务器检查后位置没有错误将此位置之后的数据包括写在缓冲区的积压数据发送给 redis 从服务器，从服务器将主服务器发送的挤压数据写入内存，这样一次完整的数据同步，再之后再同步的时候从服务器只要发送当前的 offset 位置给主服务器，然后主服务器根据响应的位置将之后的数据发送给从服务器保存到其内存即可

Redis 全量复制一般发生在 Slave 初始化阶段，这时 Slave 需要将 Master 上的所有数据都复制一份。具体步骤如下 1）从服务器连接主服务器，发送 SYNC 命令； 2）主服务器接收到 SYNC 命名后，开始执行 BGSAVE 命令生成 RDB 快照文件并使用缓冲区记录此后执行的所有写命令； 3）主服务器 BGSAVE 执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； 4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； 5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； 6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令； 7）后期同步会先发送自己 slave\_repl\_offset 位置，只同步新增加的数据，不再全量同步

主从同步优化

slave切换master

Slave 节点再有 Slave 一主从从

常见问题汇总 master 密码不对即配置的 master 密码不对，导致验证不通过而无法建立主从同步关系

Redis 版本不一致不同的 redis 版本之间存在兼容性问题，因此各 master 和 slave 之间必须保持版本一致

无法远程连接在开启了安全模式情况下，没有设置 bind 地址和密码

上一个步骤的主从架构无法实现 master 和 slave 角色的自动切换，即当 master 出现 redis 服务异常、主机断电、磁盘损坏等问题导致 master 无法使用，而 redis 高可用无法实现自故障转移(将 slave 提升为 master)，需要手动改环境配置才能切换到 slave redis 服务器，另外也无法横向扩展 Redis 服务的并行写入性能，当单台 Redis 服务器性能无法满足业务写入需求的时候就必须需要一种方式解决以上的两个核心问题 1.master 和 slave 角色的无缝切换，让业务无感知从而不影响业务使用 2.可以横向动态扩展 Redis 服务器，从而实现多台服务器并行写入以实现更高并发的目的

Sentinel(哨兵)

Sentinel 进程是用于监控 redis 集群中 Master 主服务器工作的状态，在 Master 主服务器发生故障的时候，可以实现 Master 和 Slave 服务器的切换，保证系统的高可用，其已经被集成在 redis2.6+的版本中，Redis 的哨兵模式到了 2.8 版本之后就稳定了下来。一般在生产环境也建议使用 Redis 的 2.8 版本的以后版本。哨兵(Sentinel) 是一个分布式系统，你可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossipprotocols)来接收关于 Master 主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个 Slave 作为新的 Master。每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave 定时发送消息，以确认对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机” ，英文名称：Subjective Down，简称 SDOWN。有主观宕机，肯定就有客观宕机。当“哨兵群”中的多数 Sentinel 进程在对 Master 主服务器做出 SDOWN 的判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的 Master Server 下线判断，这种方式就是“客观宕机”，英文名称是：Objectively Down，简称 ODOWN。通过一定的 vote 算法，从剩下的 slave 从服务器节点中，选一台提升为 Master 服务器节点，然后自动修改相关配置，并开启故障转移（failover） Sentinel 机制可以解决 master 和 slave 角色的切换问题

手动配置master 需要手动先指定某一台 Redis 服务器为 master，然后将其他 slave 服务器使用命令配置为 master 服务器的 slave

3台机器，配置1主二从，哨兵每台机器都配置

应用程序如何连接 redis？ java 客户端连接 redis 是通过 jedis 来实现的，java 代码用的时候只要创建 jedis 对象就可以建多个 jedis 连接池来连接 redis，应用程序再直接调用连接池即可连接 Redis。而 Redis 为了保障高可用,服务一般都是 Sentinel 部署方式，当 Redis 服务中的主服务挂掉之后,会仲裁出另外一台 Slaves 服务充当 Master。这个时候,我们的应用即使使用了 Jedis 连接池,Master服务挂了,我们的应用奖还是无法连接新的 Master 服务，为了解决这个问题,Jedis 也提供了相应的Sentinel 实现,能够在 Redis Sentinel 主从切换时候,通知我们的应用,把我们的应用连接到新的Master 服务。 Jedis Sentinel 的使用也是十分简单的,只是在 JedisPool 中添加了 Sentinel 和 MasterName 参数，Jedis Sentinel 底层基于 Redis 订阅实现 Redis 主从服务的切换通知，当 Reids 发生主从切换时，Sentinel 会发送通知主动通知 Jedis 进行连接的切换，JedisSentinelPool 在每次从连接池中获取链接对象的时候,都要对连接对象进行检测,如果此链接和 Sentinel 的 Master 服务连接参数不一致,则会关闭此连接,重新获取新的 Jedis 连接对象

哨兵配置文件 sentinel.conf

哨兵日志

停止redis master测试故障转移

小结

主从模式，主挂了，从节点不会自动切换使用哨兵会自动切换，简单来说哨兵就是一个监控端 sentinel monitor mymaster 192.168.10.3 6379 2 #指明当有多少个 sentinel 认为一个 master 失效时，master 才算真正失效，简单来说就是当前集群的主机的一半

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 438803792@qq.com