我是一个苦逼的运维，有一次老板过来找我。
老板：现在有四个 redis 节点摆在你面前，一主三从，你负责盯着点，主节点挂了你赶紧想办法拿从节点顶上来，交给你了！
这还不简单！
首先我先分别连上这四台 redis 节点。
redis-cli -h 10.232.0.0 -p 6379
redis-cli -h 10.232.0.1 -p 6379
redis-cli -h 10.232.0.2 -p 6379
redis-cli -h 10.232.0.3 -p 6379
然后每隔 1s 分别发送 redis 专属的命令 PING
我就这样一直不断地发送着 PING 命令，日复一日。
终于有一天，发送给主节点的 PING 命令收到了无效回复！
我立刻打起了精神，开始操作了起来。
但我没有慌乱了手脚，很快我就梳理好了即将要做的三件事。
选择一个从节点，将其变为主节点。
选哪个节点好呢？先别管那么多了，随便选一个，就 10.232.0.3:6379 这个吧！
我对着这个节点，发送了一个命令。
10.232.0.3:6379> slaveof no one
OK
我想，这个节点应该就已经变成了主节点了，但我不太敢确定，于是又发送了一个命令进行确认。
10.232.0.3:6379> info
...
role:slave
诶，还没有变成主节点呢，那再给他点时间。一秒钟之后，我再次进行查看。
10.232.0.3:6379> info
...
role:master
嗯，这回已经成功变成主节点啦，进行下一步！
修改其他从节点的附属主节点
很简单，向另外两台从节点发送命令。
10.232.0.1:6379> slaveof 10.232.0.3 6379
OK
10.232.0.2:6379> slaveof 10.232.0.3 6379
OK
将挂掉的主节点变为从节点
这一步充分体现了我多年的运维经验，很多人都想不到。
原来的主节点我可不能不管，万一他又复活了，就得乖乖成为新主节点的从节点。
10.232.0.0:6379> slaveof 10.232.0.3 6379
但是我不能直接发送这个命令给它，因为它还挂着呢，所以我将命令保存起来，只要它一复活我就发给它这个命令。
整个三步看起来是这个样子。
经过多次这样的操作，我终于熟悉了整个流程。
为了解放我自己的双手，我把这个固定的流程，写成了一个程序。
这个程序能实时监控这些 redis 节点的状态，并能自动报告并处理突发情况，我给他命名为哨兵程序。
而这个哨兵程序我单独用一台服务器部署，这个服务器就称为哨兵节点。
哨兵一开始就连接这 4 个 redis 节点，并持续我刚刚的操作过程。
优化
我还发现了一个小的优化点，我无需知道这 4 个节点的全部信息，只需要知道主节点即可。
从节点的信息，我通过向主节点发送 info 命令即可获取，而且可以不断获取来更新。
10.232.0.0:6379> info
...
role:master
...
slave0:ip=10.232.0.1,port=6379,state=online ...
slave0:ip=10.232.0.2,port=6379,state=online ...
slave0:ip=10.232.0.3,port=6379,state=online ...
...
这样，我在启动哨兵时，只要知道主节点即可，而且这样获取的从节点信息更准确，也更实时，就不用一直问老板啦。
虽然已经可以解放双手，但兴致来了的我仍然没有收手。
刚刚主节点挂了之后，我随机从三个从节点中选择了一个作为主节点，不妨让这个随机也智能一些吧，不然总觉得太 low。
首先，我把所有的从节点的主要信息列出来（这里假设多一些节点方便分析）
|
节点 |
状态 |
距离上次回复的时间 |
复制偏移量 |
uid |
|
1 |
DISCONNECTED |
8 |
50 |
12345 |
|
2 |
DOWN |
8 |
50 |
12346 |
|
3 |
√ |
7 |
50 |
12347 |
|
4 |
√ |
1 |
50 |
12348 |
|
5 |
DOWN |
8 |
50 |
12349 |
|
6 |
√ |
1 |
50 |
12350 |
先去掉所有断线或下线的节点。
|
节点 |
状态 |
距离上次 回复的时间 |
复制偏移量 |
uid |
|
1 |
DISCONNECTED |
8 |
50 |
12345 |
|
2 |
DOWN |
8 |
50 |
12346 |
|
3 |
√ |
7 |
50 |
12347 |
|
4 |
√ |
1 |
50 |
12348 |
|
5 |
DOWN |
8 |
50 |
12349 |
|
6 |
√ |
1 |
50 |
12350 |
再去掉最后一个 ping 请求过去后，未回应的时间大于 5s 的。
|
节点 |
状态 |
距离上次 回复的时间 |
复制偏移量 |
uid |
|
1 |
DISCONNECTED |
8 |
50 |
12345 |
|
2 |
DOWN |
8 |
50 |
12346 |
|
3 |
√ |
7 |
50 |
12347 |
|
4 |
√ |
1 |
50 |
12348 |
|
5 |
DOWN |
8 |
50 |
12349 |
|
6 |
√ |
1 |
50 |
12350 |
剩下两个，是至少状态健康的节点，继续择优录取。
我们比较其复制偏移量的值，这个代表其从主节点成功复制了多少数据，选择一个复制偏移量最多的，也就是与主节点最接近同步的。
|
节点 |
状态 |
距离上次 回复的时间 |
复制偏移量 |
uid |
|
4 |
√ |
1 |
50 |
12348 |
|
6 |
√ |
1 |
50 |
12350 |
不过我们发现其偏移量一样。
到现在，这两个节点无论从健康状态，还是同步状态，都是完全一样的，没办法分出谁好谁坏了，那怎么办呢？
没关系，还有一个终极武器，就是唯一标识 uid，这两个 uid 在启动节点时就保证了必然不相同，我们选择一个相对较小的。
|
节点 |
状态 |
距离上次 回复的时间 |
复制偏移量 |
uid |
|
4 |
√ |
1 |
50 |
12348 |
OK，最终可以唯一确定一个从节点，就把它变为主节点了！
我把这个复杂的过程，写成了一个方法，sentinelSelectSlave()，放在了哨兵程序中，用来选择一个从节点。
嗯，现在这个程序看起来，已经很完善了！
我放心地把这个哨兵程序启动起来，之后的很长一段时间，我就靠着我的哨兵程序，成功自动应对了很多次突发情况，有一次甚至在半夜两点多迅速将问题发现并解决。
老板一直夸我坚守岗位，半夜了还这么负责，我很快得到了晋升。
直到有一次，我正在开开心心摸鱼，老板气哄哄地走来。
老板：redis 都挂了一个小时了！你怎么还不处理！额？你这是看什么？leetcode？是准备跳槽了么！
我一脸懵逼，赶紧看了一下我的哨兵进程，我擦，哨兵服务器挂掉了！
我被降了职，但仍然要负责看着这些 redis 节点，这回我可不敢怠慢了。
我继续用哨兵程序监控着这些节点的生死，但我自己又多了一项任务，就是监控哨兵节点的状态，仿佛一夜回到解放前。
怎么样再次解放我的双手，让程序帮我去监控和处理这个哨兵节点的健康状态呢？
我灵机一动，部署多个哨兵节点，成为哨兵集群！只要有一个节点活着就行，这样同时都挂掉的概率就非常小了。
当然，有三个哨兵时，每个哨兵就不能太自我了，得听从组织统一安排。
主客观问题
比如说，当哨兵 1 认为主节点已经挂掉时，不能认为主节点就真的挂掉了，这种判断叫做主观下线。
哨兵 1 主观认为主节点下线时，需要询问其他节点，主节点是否已经下线。
如果其中哨兵 2 回复，主节点下线了，哨兵 3 回复，主节点没下线。
那么这个时候，哨兵集群中，一共有 2 个哨兵都主观认为主节点下线。
当主观下线的数量达到一定值时，比如说 >=2 时，我们就可以认为，主节点客观下线。
一旦主节点客观下线了，那就又可以走之前的故障处理流程，即选择一个从节点变成主节点。
领头问题
接下来，将从节点变成主节点，也就是后续的这个故障处理流程，由哪个哨兵来完成呢？
总不能同时来操作吧。
那就必然需要选举出一个领头来完成这个事。
怎么选举出一个领头呢？我总不能再用一个哨兵去做吧，那样就无限套娃了，最好的方式就是让他们仨自发地决定。
这部分有点复杂，在这里展开不太合适，可以单独水一篇文章来讲解，感兴趣的同学可以看一下 Raft 算法，哨兵集群正是通过这个算法来选举领头的。
OK，我终于再次解放了我的双手！
我把这个破玩意，称为哨兵系统，或者哨兵集群！
我再给哨兵起个英文名字，叫 Sentinel 吧！
后记
本次选取的 redis 代码为 redis-3.0.0。
之所以能够通过"我"这个视角来写哨兵，正是因为哨兵这个程序，完全可以由人不断输入 redis 命令来轻松完成，并不需要什么其他协议的支持。
比如判断节点健康状态的 ping，拿到节点信息的 info，设置主从节点的 slaveof，甚至询问其他哨兵节点是否在线的命令 sentinel is-master-down-by addr 等等，都是 redis 支持的客户端命令，对用户端非常友好。
redis 的源代码也是非常干净，而且设计得很精妙，建议有兴趣的读者可以深入源码进行阅读，不算难。
比如上面讲的，如何从一堆从节点中，选取一个作为主节点。
这个知识点网上搜，你会搜到很多云里雾里的解释，而如果你看源码，你会发现这个过程非常清晰。
sentinelRedisInstance *sentinelSelectSlave() { ... // 去掉一些节点 while((de = dictNext(di)) != NULL) { ... if (slave->flags & (DOWN||DISCONNECTED)) continue; if (mstime() - slave->last_avail_time > 5000) continue; if (slave->slave_priority == 0) continue; if (...) continue; ... } // 剩下的节点排个序 qsort(..., compareSlavesForPromotion); // 取第一个 return instance[0]; } // 怎么排序呢？就这么排 int compareSlavesForPromotion(const void *a, const void *b) { // 先按优先级排 if ((*sa)->slave_priority != (*sb)->slave_priority) return (*sa)->slave_priority - (*sb)->slave_priority; // 优先级一样按偏移量排 if ((*sa)->slave_repl_offset > (*sb)->slave_repl_offset) { return -1; } else if ((*sa)->slave_repl_offset < (*sb)->slave_repl_offset) { return 1; } ... // 偏移量一样按唯一标识排 return strcasecmp(sa_runid, sb_runid); }
我想相信如果你停下来仔细看几秒，哪怕你对 c 语言并不熟悉，也能看懂个大概了，再结合网上或者书上关于这块的描述，你就有了很直观的印象。
关于 redis 源码的深入学习，我建议先阅读黄健宏的《Redis 设计与实现》，这本书代码量很少，但逻辑描述完全按照写代码的思维来讲，你读一下就知道了。
读完这本书，直接上手 redis 源码的阅读，你可以选择 redis-1.0.0 代码，非常少，主要阅读其整个网络 IO 以及命令处理的流程。
接着，从 redis-3.0.0 开始，有针对性研究其主从、集群、哨兵等特性。
这样，redis 在你这，就不再是模模糊糊了。
