Redis系列之高可用集群

Redis，一个完全免费开源的缓存软件，它是使用C语言编写，基于内存的高性能key-value数据库。Redis在互联 存储技术中得到非常广泛的应用，它作为缓存中间件，能够解决互联 应用中的一些技术瓶颈，且具有使用简单，性能强悍，功能应用场景丰富的特点。

Redis如何打造高可用的架构呢化+主从+哨兵

持久化

Redis持久化的方式有两种：RDB和AOF

RDB是把Redis存储在内存的数据以快照的形式通过fork子进程写入磁盘的，采用二进制压缩存储。RDB一般是以5分钟一次的频率进行持久化，因此每5分钟保存一次快照，就会出现在两个5分钟之间的数据将会丢失；当然在写入磁盘的过程中如果宕机了同样也会导致数据丢失。

AOF是Redis把每一条执行的命令以append-only追加方式写入日志文件，以追加的方式写入磁盘的好处是消除了磁盘寻址的过程，速度快。在配置文件可以进行配置每隔多久写入日志文件，最小是1秒，也就是说AOF最多会丢失1秒中的数据；并且AOF的日志文件还支持修改，比如在操作不当的情况下不小心把数据误删掉了，此时可以找到AOF的日志文件，把最后一条删除的命令删除掉再进行数据恢复。

RDB与AOF的比较

AOF文件的数据比RDB的更加完整，所以AOF比RDB的文件更大。

AOF最多丢失1秒的数据（eveysec配置），而RDB会丢失快照间隔时间内的数据。

RDB可以做异地容灾，也就是在快照完成后可以将RDB文件放到其他地区保存，避免灾难性的自然现象造成数据丢失。

那么在实际工程中又如何选择这两种持久化方式呢strong>

两者都有各自的优点与缺点，当然是两者结合使用啦，最大程度的保证数据的完整性。如果机器宕机了，可以选择RDB文件快速进行数据恢复，然后在AOF对数据进行补全。

ps：当两种机制全部开启的时候，Redis在重启的时候会默认用AOF去重新构建内存的数据，因为AOF的数据比RDB的数据更完整。

主从同步

为了进一步提高Redis的性能和单点故障的问题，Redis可以采用主从同步的架构。

主从同步就是开启两个Redis实例，一个是主master，一个从slave，主从的数据是同步的。

主从同步有两个好处： 

1、读写分离

背景：如果单单只是一个Redis实例，读写操作都在一个Redis实例上操作，自然而然的单个Redis的压力是很大的，这时候应该采取读写分离，进一步提高Redis性能。

实现方式：以开启两个Redis实例为例，一个主Redis，一个从Redis，从Redis数据是根据主Redis数据同步的，写操作打到主上，读操作打到从上，从而实现读写分离，让不同的主从分担不同的读写操作，从而提高架构的并发。

Q:客户端是如何知道哪个是主哪个是从再进行读写操作的p>

A:客户端可以通过info命令，查到主从配置的关系，从而确定哪个是主，哪个是从。

Q:读的操作可以通过实现一主多从的方式减少压力，但是写的操作呢操作始终在一个Redis实例上。

A:分片存储

2、故障转移

背景：单独部署一个Redis实例往往是不够的，会出现单点故障问题，假如这个Redis挂了，缓存全盘皆崩。因此，需要搭建主从架构解决单点故障的问题。

实现方式：Redis提供了哨兵实现主从故障转移的功能。以两个Redis为例，一个是主，一个是从。当主出现问题了，从会升级为主，把原来有问题的主替代掉，就完成了故障转移，假如原来的主恢复了实例，那么就会以从加入到主从架构中。

Redis主从同步的原理

每一个Redis实例都有一个run id，表示Redis实例源id。master表示主，slave表示从。

1、当master搭建好了，slave需要同步master的数据时，会通过psync命令向master发送当前Redis实例（也就是salve）上的数据同步信息情况，其包括run id，offset同步偏移量等。

2、master收到slave的同步数据情况，master会分析：如果slave发送的同步源run id是master自己，那么就根据offset增量同步给slave；如果slave发送的同步源run id不是master自己，那么master就会生成RDB文件发给slave，slave清空自身数据并全量同步发来的RDB数据，此时slave是阻塞的，这时候master有新的数据更新时，再slave加载完RDB数据后会通过AOF方式同步数据。

主从同步的注意要点

1、Redis默认使用的是异步复制，master和slave之间异步地进行数据同步

2、一个master可以有多个slave

3、slave可以接受其他slave的连接，也就是说slave也可以有sub slave（下下级的意思）

4、主从同步在master是非阻塞的，如果是全量同步，在slave是阻塞的，因此slave需要同步全部来自master的RDB数据

5、slave初次同步来自master的数据时会删除旧数据，此时slave会是阻塞到来的连接请求

6、为了避免master的性能开销，一般持久化在slave上做。

7、master故障重启了，如果master有很多slave节点，那么会导致大量slave复制的情况，从而形成复制风暴，大大影响性能。

8、建议不要设置redis故障重启，master故障重启后没有备份数据（一般master没有持久化，持久化在slave），那么slave会跟着master数据清空，出现严重的数据丢失。

哨兵Sentinel

顾名思义，负责看哨的，对Redis master进行看哨，并起到监控，提醒 警，故障转移的作用，哨兵通过info replication命令可以查看redis集群的信息，发现不可用的Redis会进行一些处理，并通知客户端。

为了保证哨兵的高可用，哨兵也需要集群。建议哨兵之间物理分开部署，避免同 段或硬件的哨兵出现问题，导致哨兵全部崩盘，哨兵之间没有软硬件依赖。

当一个哨兵不可用的时候，客户端会重试几次，发现仍不可用，才会去找下一个哨兵。

当客户端连接redis实例正常的时候，哨兵挂了也不会有影响，因为当客户端不知道连接谁的时候才会去找哨兵。

当master挂掉之后，哨兵会把slave选举为master，其他slave跟着新的master，如果原来的master恢复了会以slave的身份加入集群。

哨兵Sentinel的一些要点

每个Sentinel节点都需要定期执行以下任务：每个Sentinel以每秒一次的频率，向它所知的主服务器、从服务器以及其他的Sentinel实例发送一个PING命令。

主观下线：当有一个哨兵通过ping命令（redis自身实现的ping）发送到master，有效回复PING命令的时间超过down-after-milliseconds所指定的值，则认为master不可用了，不能提供服务了。

客观下线：当一定数量（可配置）的哨兵通过ping命令（同上）认为master不可用，不能提供服务了。客观下线才是真的不能提供服务了，节点的状态会变为SDOWN状态。当没有足够数量的哨兵同意主服务器下线时，主服务器的客观下线状态就会被移除。当主服务器重新向哨兵的PING命令返回有效回复时，主服务器的主观下线状态就会被移除。一般哨兵会每十秒用info命令去检查master节点，当master节点标记为主观下线的时候，哨兵就以每秒一次的info命令去检查节点。

哨兵之间的通信：

哨兵即没有软硬件的依赖，都是单独部署的那么哨兵之间是如何通信的呢p>

通过哨兵的配置文件来看，哨兵是通过监控master的，他们是通过 Pub/Sub机制来通信的。

哨兵之间是通过订阅master来互相通信的，哨兵们在master上同时订阅着一个__sentinel__:hello 通道，因此哨兵是通过master进行通信发送信息的。

哨兵领导选举：

在哨兵集群中，当master挂了，领导哨兵不可用的时候，其他哨兵会选举一个哨兵为领导哨兵负责对接客户端。

哨兵选举机制是基于Raft算法实现的。

1、首先有个拉票环节：哨兵都希望自己成为领导者

2、哨兵收到其他哨兵的拉票后，就会同意其他哨兵的拉票。（每个哨兵只有一个同意票数）

3、当哨兵获得同意的票数超过一半的哨兵数时，那么就会选举它为领导哨兵去执行故障转移。

4、投票结束后，若在超时时间内仍然没有执行故障转移会重新进行选举。

slave选举：

当master挂了，需要选举slave来当master的时候，这时候会根据以下四个点进行选举

1、slave的节点状态（必须是健康状态，也就是Redis ping得通，如果是很久没有响应的是不行的）

2、slave的优先级。在redis.conf文件中有个slave-priority配置项，值越小，优先级越高。

3、根据数据的同步状态选举，也就是说数据同步越完整，越完善的slave拥有优先选举权。

4、最小run id。比较方案：字典顺序或ASCII码

哨兵执行故障转移的过程：

当发现master客观下线的时候，哨兵会给slave执行slaveof NO ONE命令，解除从节点的身份，让它成为新的master节点身份，然后让其他slave节点执行slaveof new_host new _port命令去跟着新的master节点。

哨兵的最佳实践

一般采用一主二从三哨兵的情况

在 络分区的情况下，当 络延迟较大的时候，会出现一定的问题。

由于 络延迟，R2和R3发现M1 ping 不通，此时R2和R3会进行选举新的master，此时M1 和R2R3的数据就已经分开了，因此可能会出现数据不一致问题或数据丢失。Redis集群非强一致性。

笔者相关文章回顾：

为什么需要缓存 互联 架构中缓存介绍

Redis基础知识 —— Redis系列之初识入门

Redis雪崩、击穿、穿透——Redis系列之雪崩、击穿、穿透

（文章内容不定期补充，若有不恰当的地方，恳请指正。）