redis中的哨兵和集群

哨兵其实就相当于一个法官，一堆哨兵就相当于一个法庭。他们可以决定哪个服务器是主服务器，哪些服务器是从服务器。当主服务器坏了哪个又该成为新的主服务器以及这一过程中间的步骤。

创建

Sentinel--哨兵，是一个特殊情况的服务器，他的创建和服务器的创建极为相似，只是使用的命令和普通服务器不同（没有set，get等）。它会在创建时读取配置好的文件，从而为每隔服务器创建相对应的对象，这些对象中包含了该服务器的地址，状态等等信息。sentinel相当于一个摄像头，它可以监管主服务器以及主服务器下面的从服务器，当然摄像头可以是多个，也就是说可以有多个sentinel监管多个服务器。

这些sentinel之间也保持着联系和沟通，他们会统一的向主服务器的一个端口来发送INFO请求，从而获取信息。

sentinel之间的联系与状态更新

sentinel会每间隔10s向主服务器发送INFO请求，希望获取该服务器的状态。

只要某一个sentinel发送了请求给服务器，那么服务器会向所有监听的sentinel会送结果。这个结果包含了主服务器的状态，从服务器的状态，以及其他监听这个服务器的所有sentinel信息。所有的sentinel可以通过此信息，在上面提到的主服务器对象中进行更新或者新增。这里有些不知如何描述，但是这个信息是保存在sentinel的主服务器对象中。

比如sentinel1 ，sentinel2，sentinel3是共同监听着server1，那么sentinel1会有一个关于server1的对象，这个对象中有一些sentinel2和sentinel3的某些信息（如地址，端口号等等），sentinel2和sentinel3也同样如此。但假设sentinel1和sentinel2同样监督着server2，那么sentinel1的server2对象中也会有着sentinel2的信息，但不会有sentinel3的信息。

主观下线和客观下线：

sentinel中会设置一个类似于超时器的概念。而一旦主服务器超过了这个设定时间却还没有回应的话，那么这个sentinel便会认为这个server已经垮了，他会在自己的观点中将它判定为下线。由于每个sentinel设置的超时器不同，所以sentinel并不会同时将主服务器主管下线。

客观下线有点复杂。由于我们之前讲到过在所有sentinel中都有一个相关的主服务器对象，其中有同样监听此服务器的其他sentinel地址，所以当某个sentinel认为此server主观下线后，他会向其他同样监听这这台服务器的sentinel发送一个信息，其中讲明了自己这边认为主服务器已经下线，想看看其他的怎么样了。收到这个信息的sentinel会进行回复，它会统计收到的主观下线数量。

当超过半数的sentinel均认为这个服务器下线了，那么服务器会被客观下线。

当判定为客观下线时，这些sentinel会选举出一个领头的sentinel。

选举策略：

首先讲一个小概念，配置纪元。配置纪元实际上是一个计数器，在一个配置纪元中只会选举出来一次领头sentinel，并且不会更改

任何sentinel都有机会成为领头的那个，至于如何选举，主要取决于它的网速（滑稽）。sentinel之间会进行一个通信，假如现在只有a和b两个sentinel，那么当a先发通信给b了，那么b的局部sentinel就是a。换句话说就是先到先得，谁先发送通信给另一个了，那么谁就是局部领头的sentinel。假如有个sentinel被半数以上的sentinel选举为局部领头，那么它就成为了全局领头，并且这个身份在一个配置纪元内不会更改。假如一个配置纪元内没有选举出来领头，那么就等待到下一个配置纪元再选举（每个配置纪元内选举都是重新开始的）

客观下线：

当领头选举出来后，一切就好办了。现在server1出了问题，他有server2，server3两个从服务器，sentinel1是领头。那么sentinel会这么做：看看server2，server3哪个是在线的，最近进行过通信的，且数据是最新的。它会根据这三个条件计算优先级，当有多个优先级相同的人出现时，会跟据id大小来判断，id小的优先成为主服务器。最后，当server1重新上线后，他也会成为选举出来的主服务器的从服务器。

其他：

sentinel之间只会有命令连接，不会有订阅连接。而sentinel与主服务器有命令和订阅连接

sentinel默认10s发送一次INFO请求，但是当主服务器下线后，变为2s一次

可以多读读raft算法的论文