聊聊 Redis 的发布订阅设计与实现

借一个午休的时光整理一下关于redis发布订阅源码的设计与实现，通过本文的阅读，你将会对发布订阅模型的设计思想以及对哨兵间选举通信的流程有着更底层的视角。

一、详解redis中发布订阅的设计

redis服务端启动时，会初始化一个记录channel以及channel订阅者的键值对结构，它用channel的名称作为key，用一个链表记录这个订阅这个channel的客户端：

对此我们给出redis初始化函数initServer的代码片段，可以看到其内部调用dictCreate方法为pubsub_channels 这个记录channel和channel订阅者的指针初始化了一个频道名称为key，链表为value的字典：

当客户端1通过SUBSCRIBE mychannel订阅mychannel这个频道，本质上就是redis服务端解析SUBSCRIBE指令并调用subscribeCommand函数，该方法会检查这个channel是否存在，如果不存在则则以channel名称为key，初始化一个链表作为value，将订阅这个channel的客户端追加到链表中。反之，如果channel存在则直接将客户端信息存入链表即可：

图片==

对此我们给出对应的源码实现，该函数subscribeCommand位于pubsub.c可以看到其入口逻辑就是遍历参数得到当前客户端想订阅的频道，然后调用pubsubSubscribeChannel将该客户端追加到这个频道的链表上：

我们步入pubsubSubscribeChannel方法即可看到上图所说明的逻辑，如果对应的频道不存在，则初始化然后将客户端追加到链表中，反之直接追加到链表中：

同理，当我们通过redis客户端键入publish mychannel "hello"向mychannel 发送一个hello消息时，redis服务端会解析这条publish指令并调用publishCommand完成消息发布，通知到各个订阅者：

图片==

我们给出publishCommand的源码，位于pubsub.c这个源代码文件中，可以看到这段代码会将channel和对应的消息传入pubsubPublishMessage方法中，并返回接收者数：

步入pubsubPublishMessage即可看到发布消息的核心逻辑，可以看到这个方法用receivers来记录接收的通知者，它会先进行精准匹配，到pubsub_channels找到和channel名字一致的channel并向该channel的订阅者发布消息，然后在进行模糊匹配，遍历所有的channel找到模糊匹配上的channel并向订阅者发布消息：

关于pub/sub模式，redis中的哨兵就很好的利用这种模式进行沟通和选举等各个工作，当我们的redis以哨兵的方式启动时，redis会定期执行哨兵的定时任务，该任务会在检查连接时检查发布订阅master的连接是否为空，若为空则调用异步连接绑定的方式订阅master的"__sentinel__:hello"频道，而该频道主要负责下面这些工作：

在故障转移过程中，Sentinel 实例会通过 __sentinel__:hello 频道交换信息，协调谁来执行故障转移操作，并确保只有一个 Sentinel 实例负责执行。

通过master的hello频道，哨兵会定期publish自己的信息到hello频道，其他哨兵就可以基于这个频道发现其他的哨兵由此完成通信：

对此我们给出哨兵定期发送hello的函数入口sentinelSendPeriodicCommands，这个方法会被定期执行，其内部逻辑一旦检查到pub/sub时间间隔过长时就会发送调用sentinelSendHello向hello频道发送当前哨兵的信息让其他哨兵感知：

步入sentinelSendHello即可看到我们上文所说的逻辑，可以看到当前哨兵会组装个人信息通过异步连接cc指针维护的连接信息PUBLISH 个人信息到hello频道:

二、小结

自此我们将发现redis发布订阅的设计与实现，本质上就是通过一个个链表管理订阅者，通过pub指令定位到channel后将消息遍历发送到对应客户端socket上，这里笔者也简单的补充一句，从源码中我们可以看到redis的发布订阅模型没有持久化机制，所以对于可靠性要求高的场景笔者还是不太建议使用pub/sub。