一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第1天，点击查看活动详情。
哨兵模式
- 监控：不断检查master是否正常运行。master存活检测，master与slave运行情况检测
- 通知：当被监控的服务器出现问题时，向其他（哨兵之箭、客户端）发送通知
- 自动故障转移：断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址
哨兵一般为单数，可以在投票的时候避免同票。有一个哨兵发现主节点掉线，其他哨兵都去查看发现掉了，就开始投票选出新的主节点，并把原来的master设为slave，且将状态设置为下线。
工作原理
阶段一：监控阶段
监控阶段主要用于同步各个节点的状态信息：
-
获取各个sentinel的状态，判断是否在线
-
获取master的状态
-
master属性
- runid
- role:master
-
各个slave的详细信息
-
-
获取所有slave的状态（根据master中的slave的ip和port）
-
slave属性
- ....
-
每个sentinel接入之后，会先去master拿信息，拿到后连接master并且根据信息去拿slave的信息。
当后续有新的sentinel加入之后，新的sentinel除了常规获取信息，也会根据master保存的sentinels与其他的sentinel建立一套 发布订阅 的通信机制。
阶段二：通知阶段
每个sentinel都可能探活到信息，哨兵群内部也会互相通知共享这些信息。
阶段三：故障转移阶段
-
在某个sentinel发现master挂了之后，会在哨兵群内部告诉其他哨兵，此时master状态称为 主观下线
-
其他sentinel就会去查看master，当超过一半的哨兵都确认挂了，就代表master确实挂了，此时 master状态是客观下线
-
sentinel们要选出一个主sentinel去沟通，所以要开启竞选机制，每人有一票。
-
每个sentinel都会竞选，并且优先投票给最先收到的票。
-
一轮投票完成如果平票就再选，直到选到一个。
-
主sentinel开始找一个slave当master，主要有几个原则：
-
在线的
-
响应比较快的
-
与原master最近交流过的
-
优先原则
- 优先级
- offset
- runid较小的
-
-
选了新的master之后，主sentinel做了几件事：
- 向新的master发送slaveof no one，通知他当选
- 向其他slave发送新master的IP和端口
集群模式
集群的作用
- 分散单台服务器的访问压力，实现负载均衡
- 分散单台服务器的存储压力，实现可扩展性
- 降低单台服务器宕机带来的业务灾难
存储结构的设计
- 通过算法设计，将key计算出对应的hash
- 所有的存储空间分成16384份，每一份叫一个槽，里面会有很多数据
- hash%16384得到该key放到那个槽中
- 每个服务器节点都会保存一张 槽映射表
- key的数据按照槽位置存储，在查询的时候，随便找一个节点访问
- 如果命中则直接返回，未命中则返回映射表对应的 服务器节点，叫客户端去访问相应的节点
主从下线与主从切换
当主节点下线后，从节点就会变为主节点。
不管谁下线，其余的节点都做同步信息就行。
增加一个主从结构或者减少一个主从结构都会重新分配槽，并且修改槽映射表
