Redis

(四)Redis高可用性的实现

《Redis设计与实现》学习笔记

Posted by Jesse on August 2, 2017

参考：Redis的设计与实现 [TOC] Redis的从服务器挂了，一般有多个从服务器，所有影响不大。但是一旦主服务器挂了，怎么办？

Redis提供了哨兵(Sentinal)机制供我们解决上面的情况。如果主服务器挂了，哨兵机制能够察觉出，然后将某个从服务器升级为主服务器，等到旧的主服务器(挂掉的那个)重连上来，会将它(挂掉的主服务器)变成从服务器。

  • 这个过程叫做主备切换(故障转移)

    一、哨兵(Sentinal)机制

    High Availability: Redis Sentinel is the official high availability solution for Redis.

哨兵(Sentinal)机制主要用于实现Redis的高可用性，主要的功能如下：

  • Monitoring. Sentinel constantly checks if your master and slave instances are working as expected.

    监控:Sentinel不停地监控Redis主从服务器是否正常工作

  • Notification. Sentinel can notify the system administrator, another computer programs, via an API, that something is wrong with one of the monitored Redis instances.

    通知：如果Redis的某个实例出现异常，哨兵机制可以通过API通知管理员或其某些相关应用

  • Automatic failover. If a master is not working as expected, Sentinel can start a failover process where a slave is promoted to master, the other additional slaves are reconfigured to use the new master, and the applications using the Redis server informed about the new address to use when connecting.

故障转移:如果主服务器挂掉了，会自动将从服务器提升为主服务器(包括配置都会修改),其他的从服务器和相关应用也会收到主服务器修改的通知

  • 配置中心. Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redis master responsible for a given service. If a failover occurs, Sentinels will report the new address.

Sentinel可以作为配置中心，能够提供当前主服务器的信息。

tips:Sentinel可以让我们的Redis实现高可用，Sentinel自身必然是高可用的

1.1启动和初始化Sentinel

首先:Sentinel本质上只是一个运行在特殊模式下的Redis服务器。因为Sentinel做的事情和Redis服务器是不一样的，所以它们的初始化是有所区别的(比如，Sentinel在初始化的时候并不会载入AOF/RDB文件，因为Sentinel根本就不用数据库)。 然后:在启动的时候会将普通Redis服务器的代码替换成Sentinel专用代码。(所以Sentinel虽然作为Redis服务器，但是它不能执行SET、DBSIZE等等命令，因为命令表的代码被替换了) 接着:初始化Sentinel的状态，并根据给定的配置文件初始化Sentinel监视的主服务器列表。

哨兵初始化

最后，Sentinel会创建两个连向主服务器的网络连接：

  • 命令连接(发送和接收命令)
  • 订阅连接(订阅主服务器的_sentinel_:hello频道)

1.2获取和更新信息

Sentinel通过主服务器发送INFO命令来获得主服务器属下所有从服务器的地址信息，并为这些从服务器创建相应的实例结构。 当发现有新的从服务器出现时，除了创建对应的从服务器实例结构，Sentinel还会创建命令连接和订阅连接。 在Sentinel运行的过程中，通过命令连接会以每两秒一次的频率向监视的主从服务器的_sentinel_:hello频道发送命令(主要发送Sentinel本身的信息，监听主从服务器的信息)，并通过订阅连接接收_sentinel_:hello频道的信息。

这样，我们就可以更新每个Sentinel实例结构的信息。

1.3、判断主服务器是否下线

判断主服务器是否下线有两种情况：

  • 主观下线
    1. Sentinel会以每秒一次的频率向与它创建命令连接的实例(包括主从服务器和其他的Sentinel)发送PING命令，通过PING命令返回的信息判断实例是否在线
    2. 如果一个主服务器在down-after-milliseconds毫秒内连续向Sentinel发送无效回复，那么当前Sentinel就会主观认为该主服务器已经下线了。
  • 客观下线
    1. 当Sentinel将一个主服务器判断为主观下线以后，为了确认该主服务器是否真的下线，它会向同样监视该主服务器的Sentinel询问，看它们是否也认为该主服务器是否下线。
    2. 如果足够多的Sentinel认为该主服务器是下线的，那么就判定该主服务为客观下线，并对主服务器执行故障转移操作。

在多少毫秒内无效回复才认定主服务器是主观下线的，以及有多少个Sentinel认为主服务器是下线才认定为客观下线。这都是可以配置的

1.4选举领头Sentinel和故障转移

当一个主服务器认为为客观下线以后，监视这个下线的主服务器的各种Sentinel会进行协商，选举出一个领头的Sentinel，领头的Sentinel会对下线的主服务器执行故障转移操作。

选举领头Sentinel的规则也比较多，总的来说就是先到先得(哪个快，就选哪个)

选举出领头的Sentinel之后，领头的Sentinel会对已下线的主服务器执行故障转移操作，包括三个步骤：

  • 在已下线主服务器属下的从服务器中，挑选一个转换为主服务器
  • 让已下线主服务器属下的所有从服务器改为复制新的主服务器
  • 已下线的主服务器重新连接时，让他成为新的主服务器的从服务器

挑选某一个从服务器作为主服务器也是有策略的，大概如下：

（1）跟master断开连接的时长 （2）slave优先级 （3）复制offset （4）run id

1.5 数据丢失情况

目前为止的主从+哨兵架构可以说Redis是高可用的，但要清楚的是：Redis还是会丢失数据的

  • 异步复制导致的数据丢失

    有部分数据还没复制到从服务器，主服务器就宕机了，此时这些部分数据就丢失了

  • 脑裂导致的数据丢失
    1. 有时候主服务器脱离了正常网络，跟其他从服务器不能连接。此时哨兵可能就会认为主服务器下线了(然后开启选举，将某个从服务器切换成了主服务器)，但是实际上主服务器还运行着。这个时候，集群里就会有两个服务器(也就是所谓的脑裂)。
    2. 虽然某个从服务器被切换成了主服务器，但是可能客户端还没来得及切换到新的主服务器，客户端还继续写向旧主服务器写数据。旧的服务器重新连接时，会作为从服务器复制新的主服务器(这意味着旧数据丢失)。
FEATURED TAGS
Design Pattern Redis MQ spring Java并发 InnoDB bigdata java redis
FRIENDS