《redis的pub/sub机制》

【redis pub/sub机制导读】上一节介绍了redis的哨兵机制，其中提到了哨兵集群，但是有很多细节没有深入，假设哨兵集群中有哨兵挂了，哨兵还能继续进行选主、通知、主从切换吗？在协商主库下线的时候，哨兵之间如何进行协商的？因为不同的哨兵位于不同的服务器上。

基于这些场景，redis推出了PUB/SUB（发布/订阅）的机制，何为发布/订阅机制？可以这么理解，redis服务A可以作为一个"广播站"，redis服务B可以往redis服务A上发布消息，如果redis服务C想知道redis服务B的消息，那redis服务C可以往redis服务A上订阅消息。这就是发布/订阅的机制。

哨兵只要和主库建立起了连接，就可以在主库上发布消息了，比如：发布自己的IP和监听端口，同时它也可以从主库上订阅其它哨兵的IP和端口信息，哨兵集群中多个哨兵都往主库上发布、订阅消息，那么整个哨兵集群就能获取到彼此的IP和端口了，进而整个哨兵集群之间的交流和通信就不存在障碍了。

我们自己编写的业务程序也可以往redis上发布消息，因为消息的种类有很多，那么redis采用了频道的形式对消息做了区分，只有归属于同个频道的应用，才能通过发布消息进行消息的互换。

在主从集群中，主库上有一个名为“sentinel:hello”的频道，不同哨兵就是通过它来相互发现彼此，实现互相通信的。哨兵之间如何互相发现的，可以参考下图：