sentinel
1、概要
Sentinel是 Redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动 将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。
2、启动并初始化Sentinel
启动有两种方式
- redis-sentinel /path/to/your/sentinel.conf
- redis-server /path/to/your/sentinel.conf --sentinel
sentinel启动时需要有配置文件
当一个Sentinel启动时，需要执行以下步骤
- 初始化服务器
- 将普通Redsi服务器使用的代码替换成Sentinel专用代码
- 初始化Sentinel状态
- 根据给定的配置文件，初始化Sentinel的监视主服务器列表
- 创建连向主服务器的网络连接
2.1 初始化服务器
initServerConfig来初始化一个普通的Redis服务器。
2.2 使用Sentinel专用代码
初始化服务器端口，sentinel支持的命令替换普通命令
2.3 初始化Sentinel状态
sentinel状态定义为
初始化在server.c/initSentinel
2.4 初始化Sentinel状态的masters属性
masters字典记录了所有被Sentinel监视的主服务器的相关信息,通过sentinelHandleConfiguration来处理配置文件中的与sentinel相关的配置
sentinel monitor
- 字典的键是被监视主服务器的名字
- 字典的值是被监视器主服务器对应的sentinel.c/sentinelRedisInstance结构
结构定义如下
2.5 创建连向主服务器的网络连接
对于每个被Sentinel监视的主服务器，会创建两个连向主服务器的异步网络连接
- 一个是命令连接，专门用于向主服务器发送命令，并接收命令回复
- 另一个是订阅连接，专门用于订阅主服务器的__sentinel__:hello频道
连接结构定义如下
为什么有两个链接？
在Redis目前的发布与订阅功能中，被发送的信息都不会保存在Redis服务器里面，如果在信息发送时，想要接收信息的客户端不在线或者断线，那么这个客户端就会丢失这条信息。因此，为了不丢失__sentinel__:hello频道的任何信息，sentinel必须专门用一个订阅连接来接收该频道的信息。
另一方面，除了订阅频道外，Sentinel还必须向主服务器发送命令，以此来与主服务器进行通信，所以Sentinel还必须向主服务器创建命令连接。
3、获取主服务器信息
Sentinel默认会以每10s一次的频率，通过命令连接向被监视的主服务器发送info命令，并通过分析info命令的回复来获取主服务器的当前信息
通过分析主服务器返回的info命令回复，sentinel可以获取以下两方面的信息：
- 一方面是关于主服务器本身的信息，包括run_id域记录的服务器运行id，以及role域记录的服务器角色
- 另一方面是关于主服务器属下所有从服务器的信息，每个从服务器都由一个slave字符串开头的行记录，每行的ip=域记录了从服务器的ip地址，而port=域则记录了从服务器的端口号。根据这些ip地址和端口号，sentinel无须用户提供从服务器的地址信息，就可以自动发现从服务器。
根据run_id域和role域记录的信息，sentinel将对主服务器的实例结构进行更新。至于主服务器返回的从服务器信息，则会被用于更新主服务器实例结构的slaves字典，这个字典记录了主服务器属下从服务器的名单。
sentinel在分析info命令中包含的从服务器信息时，会检查从服务器对应的实例结构是否已经存在于slaves字典：
- 如果从服务器对应的实例结构已经存在，那么sentinel对从服务器的实例结构进行更新。
- 如果从服务器对应的实例结构不存在，那么说明这个从服务器是新发现的从服务器，sentinel会在slaves字典中为这个从服务器新创建一个实例结构。
4、获取从服务器信息
当sentinel发现主服务器有新的从服务出现时，sentinel除了会为这个新的从服务器创建相应的实例结构之外，sentinel还会创建连接到从服务器的命令连接和订阅连接。在创建命令后，sentinel在默认情况下，会以10s一次的频率通过命令连接向从服务器发送info命令，并获得相应信息。
根据info命令的回复，sentinel会提取以下信息
- 从服务器的运行ID run_id
- 从服务器的角色role
- 主服务器的IP地址master_host,以及主服务器的端口号master_port
- 主从服务器的连接状态master_link_status
- 从服务器的优先级slave_priority
- 从服务器的复制偏移量slave_repl_offset
根据这些信息，sentinel会对从服务器的实例结构进行更新。
5、向主服务器和从服务器发送信息
在默认情况下，sentinel会以2s一次的频率，通过命令连接向所有被监视的主服务器和从服务器发送以下格式的命令
PUBLISH __sentinel__:hello "
以s_开头的参数记录的是sentinel本身的信息；以m_开头的参数记录的则是主服务器的信息。
| 参数 | 意义 |
| s_ip | sentinel的ip地址 |
| s_port | sentinele的端口号 |
| s_runid | sentinel的运行ID |
| s_epoch | sentinel当前的配置纪元 |
| m_name | 主服务器的名字 |
| m_ip | 主服务器的ip地址 |
| m_port | 主服务器的端口号 |
| m_epoch | 主服务器当前的配置纪元 |
6、接收来自主服务器和从服务器的频道信息
当sentinel与一个主服务器或者从服务器建立起订阅连接之后， sentinel就会通过订阅连接，向服务器发送以下命令
SUBSCRIBE __sentinel__:hello
服务器会将客户端(sentinel)添加到server->pubsub_channels中
sentinel对__sentinel__:hello频道的订阅会一直持续到sentinel与服务器的连接断开为止。
对于每个与sentinel连接的服务器，sentinel既通过命令连接向服务器的__sentinel__:hello频道发送信息，又通过订阅连接从服务器的__sentinel__:hello频道接收信息。
将sentinel发布过来的消息转发给其它sentinel
对于监视同一个服务器的多个sentinel来说，一个sentinel发送的信息会被其他sentinel接收到，这些信息会被用于更新其他sentinel对发送信息sentinel的认知，也会被用于更新其他sentinel对被监视服务器的认知。
当一个sentinel从__sentinel__:hello频道收到一条信息时，sentinel会对这条信息进行分析，提取出信息中的sentinel IP地址，sentinel端口号，sentinel运行id等八个参数。
- 如果信息中记录的sentinel运行id和接收信息的sentinele的运行id相同，那么 说明这条信息是sentinel自己发送的,sentinel将丢弃这条信息，不做进一步处理
- 相反地，如果 信息中记录的sentinel运行id和接收信息的sentinel的运行id不相同，那么说明这条信息是监视同一个服务器的其他sentinel发来的，接收信息的sentinel将根据信息中的各个参数，对相应主服务器的实例结构进行更新。
6.1 更新sentinels字典
sentinel为主服务器创建的实例结构中的sentinels字典保存了除sentinel本身之外，所有同样监视这个主服务器的其他sentinel的资料
- sentinels字典的键是其中一个sentinel的名字，使用的是runid
- sentinels字典的值则是键所对应的sentinel的实例结构。
当一个sentinel接收到其他sentinel发来的信息时，目标sentinel会从信息中分析并提取出以下两方面参数
- 与sentinel相关的参数：源sentinel的ip地址，端口号，运行id和配置纪元
- 与主服务器相关的参数：源sentinel正在监视的主服务器的名字、ip地址、端口号和配置纪元。
根据信息中提取出的主服务器参数，目标sentinele会在自己的sentinel状态的masters字典中查找相应的主服务器实例结构，然后根据提取出的sentinel参数，检查主服务器实例结构的sentinel字典中，源sentinel的实例结构是否存在：
- 如果源sentinel的实例结构不存在，那么说明源sentinel是刚刚开始监视主服务器的新sentinel，目标sentinel会为源sentinel创建一个新的实例结构，并将这个结构添加到sentinels字典里面
- 如果源sentinel的实例结构已经存在，那么对源sentinel的实例结构进行更新
6.2 创建连向其他sentinel的命令连接
当sentinel通过频道信息发现一个新的sentinel时，它不会会为新sentinel在sentinels字典中创建相应的实例结构，还会创建一个连向新sentinel的命令连接，而新sentinel也同样会创建连向这个sentinel的命令连接，最终监视同一主服务器的多个sentinel将形成相互连接的网络。
使用命令连接相连的各个sentinel可以通过向其他sentinel发送命令请求来进行信息交换。
sentinel之间不会创建订阅连接
sentinel在连接主服务器或者从服务器时，会同时创建命令连接和订阅连接，但是在连接其他sentinel时，却只会创建命令连接，而不创建订阅连接。这是因为sentinel需要通过接收主服务器或者从服务器发来的频道信息来发现未知的新sentinel，所以才需要建立 订阅连接，而相互已知的sentinel只要使用命令连接来进行通信就足够了。
7、检测主观下线状态
默认情况下，sentinel会以1s一次的频率向所有与它创建了命令连接的实例（包括主服务器、从服务器、其他sentinel在内）发送ping命令，并通过实例返回的ping命令回复来判断实例是否在线。
实例对ping命令的回复可以分为以下两种情况
- 有效回复：+PONG,-LOADING,-MASTERDOWN
- 无效回复：除去有效回复之外的
sentinel配置文件中的down-after-milliseconds选项指定了sentinel判断实例进入主观下线所需的时间长度：如果一个实例在down-after-milliseconds毫秒内，连续向sentinel返回无效回复，那么sentinel会修改这个实例对应的实例结构，在结构的flags属性中打开SRI_S_DOWN标识，以此来表示这个实例已经进入主观下线状态。
8、检查客观下线状态
当sentinel将一个主服务器判断为主观下线后，为了确认这个主服务器是否真的下线了，它会向同样监视这一主服务器的其他sentinel进行询问，看它们是否也认为主服务器已经进入了下线状态（可以是主观下线或者客观下线）。当sentinel从其他sentinel那里到足够数据的已下线判断之后，sentinel就会将主服务器判断为客观下线，并对主服务器执行故障转移操作。
8.1 发送SENTINEL is-master-down-by-addr命令
sentinel使用
SENTINEL is-master-down-by-addr
| ip | 被sentinel判断为主观下线的主服务器的ip地址 |
| port | 被sentinel判断为主观下线的主服务器的端口号 |
| current_epoch | sentinel当前的配置纪元，用于选举领头sentinel |
| runid | 可以是*符号或者sentinel的运行id：*符号代表命令仅仅用于检测主服务器的客观下线状态，而sentinel的运行id则用于选举领头sentinel |
8.2 接收SENTINEL is-master-down-by-addr命令
当一个sentinel（目标sentinel）接收到另一个sentinel（源sentinel）发来的SENTINEL is-master-down-by命令时，目标sentinel会分析并取出命令请求中包含的各个参数，并根据其中的主服务器ip和端口号，检查主服务器是否已下线，然后源sentinel返回一条包含三个参数的Multi Bulk回复作为SENTINEL is-master-down-by命令的回复
| down_state | 返回目标sentinel对主服务器的检查结果，1代表主服务器已下线，0代表主服务器未下线 |
| leader_runid | 可以是 *符号或者目标sentinel的局部领头sentinel的运行id：*符号代表命令仅仅用于检测主服务器的下线状态。而局部领头sentinel的运行id则用于选举领头sentinel。 |
| leader_epoch | 目标sentinel的局部领头sentinel的配置纪元，用于选举领头sentinel。仅在leader_runid的值不为*时有效，如果leader_runid的值为*,那么leader_epoch总为0 |
8.3 接收SENTINEL is-master-down-by-addr命令的回复
根据其他sentinel发回的SENTINEL is-master-down-by-addr命令回复，sentinel将统计其他sentinel同意主服务器已下线的数量，当这一数量达到配置指定的判断客观下线所需的数量时，sentinel会将主服务器实例结构flags属性的SRI_O_DOWN标识打开 ，表示主服务器已经进入客观下线状态。
下面是处理接收到的回复
下面是检查数量
9、选举领头sentinel
当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个sentinel会进行协商，选举出一个领头sentinel，并由领头sentinel对下线主服务器进行故障转移操作，以下是redis选举领头sentinel的规则和方法：
- 所有在线的sentinel都有被选为领头sentinel的资格，换句话说，监视同一个主服务器的多个在线sentinel中的任意一个都有可能成为领头sentinel
- 每次进行领头sentinel选举之后，不论选举是否成功，所有sentinel的配置纪元的值都会自增一次。配置纪元实际上就是一个计数器，并没有什么特别的
- 在一个配置纪元里面，所有sentinel都有一次将某个sentinel设置为局部领头sentinel的机会，并且局部领头一旦设置，在这个配置纪元里面就不能再更改
- 每个发现主服务器进入客观下线的sentinel都会要求其他sentinel将自己设置为局部领头sentinel。
- 当一个sentinel（源sentinel)向另一个sentinel（目标sentinel）发送SENTINEL is-master-down-by-addr命令，并且命令中的runid参数不是*符号而是源sentinel的运行id时，这表示源sentinel要求目标sentinel将前者设置为后者的局部领头sentinel.
- sentinel设置局部领头sentinel的规则是先到行得：最先向目标sentinel发送设置要求的源sentinel将成为目标sentinel的局部领头sentinel，而之后接收到的所有设置要求都会被目标sentinel拒绝
- 目标sentinel在接收到SENTINEL is-master-down-by-addr命令之后，将向源sentinel返回一条命令回复，回复中的leader_runid参数和leader_epoch参数分别记录了目标sentinel的局部领头sentinel的运行id和配置纪元。
- 源sentinel在接收到目标sentinel返回的命令回复之后，会检查回复中leader_epoch参数的值和自己的配置纪元是否相同，如果相同的话，那么 源sentinel继续取出回复中的leader_runid参数，如果leader_runid参数的值和源sentinel的运行id一致，那么表示目标sentinel将sentinel设置成了局部领头sentinel.
- 如果有某个sentinel被半数以上的sentinel设置成了局部领头sentinel，那么这个sentinel成为领头sentinel。
- 因为领头sentinel的产生需要半数以上sentinel的支持，并且每个sentinel在每个配置纪元里面只能设置一次局部领头sentinel，所以在一个配置纪元里面，只会出现一个领头sentinel
- 如果在给定时限内，没有一个sentinel被选举为领头sentinel，那么各个sentinel将在一段时间之后再次进行选举，直到选出领头sentinel为止。
10、故障转移
在选举产生出领头sentinel之后，领头sentinel将对已下线的主服务器执行故障转移操作，该操作包含以下三个步骤
- 在已下线主服务器属下的所有从服务器里面，挑选出一个从服务器，并将其转换为主服务器
- 让已下线主服务器属下的所有从服务器改为复制新的主服务器
- 将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线时，它就会成为新的主服务器的从服务器
故障转移状态机状态转移图为
10.1 选出新的主服务器
故障转移操作第一步要做的就是在已下线主服务器属下的所有从服务器中，挑选出一个状态良好、数据完整的从服务器，然后向这个从服务器发送slaveof no one命令，将这个从服务器转换为主服务器。
如何选择新的主服务器？
- 列表中所有处于下线或者断线状态的从服务器，不计算在内
- 5s内没有回复过领头sentinel的ping命令的从服务器，不计算在内
- 从服务器的slave_priority的优先级为0的不计算在内
- 主服务器主观下线时5s内(否则30s内)没有回复领头sentinel的info命令的从服务器，不计算在内。
- 与已下线主服务器连接断开超过down_after_period*10ms的从服务器，不计算在内
- 对列表中剩余的从服务器根据从服务器的优先级排序，如果有多个具有相同最高优先级的从服务器，那么领头sentinel将按照从服务器的复制偏移量选出其中偏移量最大的从服务器，如果复制偏移量相同，将按照运行id对这些从服务器进行排序，选出其中运行id最小的从服务器。
10.2 修改从服务器的复制目标
当新的主服务器出现之后，领头sentinel下一步要做的就是，让已下线主服务器属下的所有从服务器支复制新的主服务器，通过向从服务器发送slaveof命令来实现。
10.3 将旧的主服务器变为从服务器
故障转移操作最后要做的是，将已下线的主服务器设置为新的主服务器的从服务器。
