从零单排学Redis【铂金二】

前言

只有光头才能变强

好的，今天咱们要上【铂金二】了，若是尚未上铂金的，赶忙先去蹭蹭经验再回来(否则不带你上分了)：

• 从零单排学Redis【青铜】
• 从零单排学Redis【白银】
• 从零单排学Redis【黄金】
• 从零单排学Redis【铂金一】

在上篇中抛出了一个问题：

抛个问题：若是从服务器挂了，不要紧，咱们通常会有多个从服务器，其余的请求能够交由没有挂的从服务器继续处理。若是主服务器挂了，怎么办？由于咱们的写请求由主服务器处理，只有一台主服务器，那就没法处理写请求了？

Redis提供了哨兵(Sentinal)机制供咱们解决上面的状况。若是主服务器挂了，咱们能够将从服务器升级为主服务器，等到旧的主服务器(挂掉的那个)重连上来，会将它(挂掉的主服务器)变成从服务器。

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

在正常的状况下，主从加哨兵(Sentinal)机制是这样子的：

主服务器挂了，主从复制操做就停止了，而且哨兵系统是能够察觉出主服务挂了。：

Redis提供哨兵机制能够将选举一台从服务器变成主服务器

而后旧的主服务器若是重连了，会变成从服务器：

这篇文章主要讲讲Redis的哨兵(Sentinal)机制的一些细节。但愿看完对你们有所帮助~

1、哨兵(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实例有故障，那么哨兵负责发送消息通知管理员
• 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.
  • 若是主服务器挂掉了，会自动将从服务器提高为主服务器(包括配置都会修改)。
• Configuration provider. 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能够做为配置中心，可以提供当前主服务器的信息。

下面来具体讲讲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判断主服务器是否下线了

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

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

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

1.4选举领头Sentinel和故障转移

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

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

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

• 在已下线主服务器属下的从服务器中，挑选一个转换为主服务器
• 让已下线主服务器属下的全部从服务器改成复制新的主服务器
• 已下线的主服务器从新链接时，让他成为新的主服务器的从服务器
• (这三步实际上就是文章开头的图片)

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

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

最后

这篇文章主要讲解了Sentinel的做用和工做的基本过程(我以为已经基本OK了)，其中也涉及到了不少的细节，这里我就没有一一整理出来了。想要深刻学习的同窗最好本身看看书或者文档~~

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

丢失数据有两种状况：

• 异步复制致使的数据丢失
  • 有部分数据还没复制到从服务器，主服务器就宕机了，此时这些部分数据就丢失了
• 脑裂致使的数据丢失
  • 有时候主服务器脱离了正常网络，跟其余从服务器不能链接。此时哨兵可能就会认为主服务器下线了(而后开启选举，将某个从服务器切换成了主服务器)，可是实际上主服务器还运行着。这个时候，集群里就会有两个服务器(也就是所谓的脑裂)。
  • 虽然某个从服务器被切换成了主服务器，可是可能客户端还没来得及切换到新的主服务器，客户端还继续写向旧主服务器写数据。旧的服务器从新链接时，会做为从服务器复制新的主服务器(这意味着旧数据丢失)。

能够经过如下两个配置尽可能减小数据丢失的可能：

min-slaves-to-write 1
min-slaves-max-lag 10

从零单排学Redis【铂金三】，敬请期待~

参考资料：

• 《Redis设计与实现》
• 《Redis实战》

若是你以为我写得还不错，了解一下：

• 坚持原创的技术公众号：Java3y。回复 1 加入Java群
• 文章的目录导航(精美脑图+海量视频资源)：https://github.com/ZhongFuCheng3y/3y