redis高可用

redis高可用

redis主从

即使有了RDB和AOF两种持久化方式，但是还是会有数据丢失的可能。

• 如果服务器发生了宕机，由于数据恢复是需要点时间，那么这个期间是无法服务新的请求的；
• 如果这台服务器的硬盘出现了故障，可能数据就都丢失了。

要避免这种单点故障，最好的办法是将数据备份到其他服务器上。

同mysql一样，redis也是主写，从读

主从命令

// 从服务器执行
slaveof {masterIp} {masterport}

第一次同步

第一次同步需要全量把主服务器的数据同步给从服务器。

1. 建立连接，协商同步
2. 主服务器生成RDB文件，传输RDB文件给从服务器，从服务器清空原数据，读入RDB文件
3. 主服务器把生成RDB时，主进程收到的其他命令从缓冲区中读出，发送给从服务器同步，完成数据一致性
   

命令传播

主从服务器在完成第一次同步后，双方之间就会维护一个 TCP 连接。避免频繁的网络IO

分摊主服务器压力

主服务器再同步过程中最耗时的就是生成RDB和传输RDB。如果有很多从服务器那样主服务器的压力就会很大。
我们可以将主从服务器设置成树状，例如A是BC的主服务器，BC是DEFG的主服务器，这样就缓解了A主服务器的压力

增量同步

如果从服务器突然宕机，主服务器任然有写入命令，此时主从数据不一致。

从服务器重启后需要重新同步主服务器数据，此时就需要增量同步

哨兵

在 Redis 的主从架构中，由于主从模式是读写分离的，如果主节点（master）挂了，那么将没有主节点来服务客户端的写操作请求，也没有主节点给从节点（slave）进行数据同步了。哨兵就是一个节点，他能监控「主节点」的状态，当发现主节点挂了 ，它自动将一个「从节点」切换为「主节点」

哨兵节点主要负责三件事情：监控、选主、通知。

监控

心跳机制，哨兵主动向所有节点发送ping请求，如果节点在down-after-milliseconds时间段内没有响应则判断为主观下线。

哨兵一般都是以集群存在的，因为一台哨兵容易出现判断错误，如果哨兵网络有问题就会将所有节点判断为下线。如果是多台集群，他们就会根据投票来完成判断。quorum 字段是配置文件中用来判断投票成立数的。

sentinel有自己的配置文件，不是redis.conf

选主

一顿操作，反正很复杂，具体看小林coding

通知

这主要通过 Redis 的发布者/订阅者机制来实现的。每个哨兵节点提供发布者/订阅者机制，客户端可以从哨兵订阅消息。

客户端和哨兵建立连接后，客户端会订阅哨兵提供的频道。主从切换完成后，哨兵就会向 +switch-master 频道发布新主节点的 IP 地址和端口的消息，这个时候客户端就可以收到这条信息，然后用这里面的新主节点的 IP 地址和端口进行通信了。

go服务是常驻内存的，所以需要订阅此消息来，如果收到了消息可以及时创建新连接
php服务非常驻进程，所以每次请求时都需要获取当前主服务的ip:port，来连接使用