所以主要说一下哨兵形式。

哨兵是用来管理多个 Redis 效劳器的，我从《Redis开发与运维》一书中，拍个照片给你看看：

它主要执行三种类型的义务：

监控(Monitoring)： Sentinel 会不断地反省你的主效劳器和从效劳器能否运作正常。

提示(Notification)： 当被监控的某个 Redis 效劳器出现成绩时， Sentinel 可以经过 API 向管理员或许其他运用顺序发送通知。

自动缺点迁移(Automatic failover)： 当一个主效劳器不能正常任务时， Sentinel 会末尾一次自动缺点迁移操作， 它会将失效主效劳器的其中一个从效劳器晋级为新的主效劳器， 并让失效主效劳器的其他从效劳器改为复制新的主效劳器; 当客户端试图衔接失效的主效劳器时， 集群也会向客户端前往新主效劳器的地址， 使得集群可以运用新主效劳器替代失效效劳器。

哨兵其实也是一个散布式系统，我们可以运转多个哨兵。

然后这些哨兵之间需求相互通气，交流信息，经过投票来决议能否执行自动缺点迁移，以及选择哪个从效劳器作为新的主效劳器。

哨兵之间采用的协议是 gossip，是一种去中心化的协议，达成的是最终分歧性，十分有意思，

另外，假设主节点挂了，哨兵究竟经过什么规则选择新的主节点，也就是选举进程大致是怎样样的，也偶现于面试环节。

我以前就被问到过，幸而事先背的熟练。

复杂说一下规则，无它，背诵就完事了：

在挂了的主节点下挂的从节点中，被标记为客观下线、已断线、或许最后一次回复 PING 命令的时间大于五秒钟的从节点都没有资历参与选举。

在挂了的主节点下挂的从节点中，那些与挂了的主节点衔接断开的时长超过 down-after 配置指定的时长十倍的从节点都没有资历参与选举。

经过下面这两轮淘汰之后，剩上去的从效劳器中，选出复制偏移量(replication offset)最大的那个从效劳器作为新的主效劳器。假设复制偏移量不可用，或许从效劳器的复制偏移量相反，那么带有最小运转 ID 的那个从效劳器成为新的主效劳器。

其实执行下面这些操作的，是一个哨兵。而我们的哨兵普通是三个以上，那么那个哨兵来执行这些操作呢?

其实这个哨兵也是需求从多个哨兵中被选举一个出来的，被选出来的这个哨兵就是领头哨兵(leader Sentinel)。

选举领头哨兵的时分，采取的是 Raft 算法。

至于哨兵形式的搭建，普通来说是运维干的事儿。

但是网上的搭建教程很多，能本人跟着教程亲身搭一波那就更好了。

置信我，搭建的进程中你一定会碰到各种各样的成绩，而这些成绩就是你的播种。

回到末尾

这一小节，我们回到最末尾的这个面试题：

其实看到这个成绩的时分，我就想到了老是被爆来爆去的微博。

刚好，这周又吃了一波吴某凡的瓜，事先还正在看女排的直播，看到报道的时分，表情大约是这样的：

周六的早晨基本上就是带着这个表情瓜田外面上蹿下跳的，真是太好吃了。

但是凡凡这一波，不知道是凡凡的流量不行了，还是微博的架构经受住了考验。

微博居然还比较顺滑，没有出现大范围的、十分清楚的效劳挂掉的现象。

我印象中最近一次微博挂的死死的，就是鹿晗关晓彤那事了。

倒不是由于我关注他们，而是我关注到了那天正在结婚的顺序员。

要说这位丁振凯同窗也真是太惨了。

结婚的时分碰上鹿晗发布爱情。海外度假时撞上双宋官宣。老婆待产的时分撞上华晨宇供认和张碧晨未婚生有一女。

这次我去看了，表现比较淡定。应该是在一手抱娃，一手扩容，特地吃瓜。

当年鹿晗这事，微博助手说挂掉是由于单条微博转发、评论次数太多了。

这是不片面的，单纯的转发评论多，并不能压垮大微博。而且鹿晗的那天微博应该也不是他所以的微博中转发评论最多的一条。

是由于转发、评论并发太高太高太高了，是我一辈子都接触不到的瞬间流量。

吃瓜群众也蜂拥而至，短时间内同时在线迅速爆涨，把效劳器干掉了：

关于这个成绩，我在知乎上看到一个评论，我觉得挺好的，搬运截图一下：

https://www.zhihu.com/question/66346687

(责任编辑：admin)