Muduo 网络编程示例之九：简单的消息广播服务

Muduo 网络编程示例之九：简单的消息广播服务

陈硕 (giantchen_AT_gmail)

Blog.csdn.net/Solstice  t.sina.com.cn/giantchen

这是《Muduo 网络编程示例》系列的第九篇文章，讲用 muduo 实现一个简单的 pub/sub 服务。

Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx

本文介绍用 muduo 实现一个简单的 topic-based 消息广播服务，这其实是“聊天室”的一个简单扩展，不过聊天的不是人，而是分布式系统中的程序。

本文的代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/hub

 

在分布式系统中，除了常用的 end-to-end 通信，还有一对多的广播通信。一提到“广播”，或许会让人联想到 IP 多播或 IP 组播，这不是本文的主题。本文将要谈的是基于 TCP 协议的应用层广播。示意图如下：

上图中圆角矩形代表程序，"Hub"是一个服务程序，不是网络集线器，它起到类似集线器的作用，故而得名。Publisher 和 Subscriper 通过 TCP 协议与 Hub 程序通信。Publisher 把消息发到某个 topic 上，Subscribers 订阅该 topic，然后就能收到消息。即 publisher 借助 hub 把消息广播给了多个 subscribers。这种 pub/sub 结构的好处在于可以增加多个 Subscriber 而不用修改 Publisher，一定程度上实现了“解耦”（也可以看成分布式的 observer pattern）。 由于走的是 TCP 协议，广播是基本可靠的，这里的“可靠”指的是“比 UDP 可靠”，不是“完全可靠”。（思考：如何避免 Hub 成为 single point of failure？）

为了避免串扰（cross-talk），每个 topic 在同一时间只应该有一个 publisher，hub 不提供 compare-and-swap 操作。

（“可靠广播、原子广播”在分布式系统中有重大意义，是以 replicated state machine 方式实现可靠的分布式服务的基础，“可靠广播”涉及 consensus 算法，超出了本文的范围。）

 

应用层广播在分布式系统中用处很大，这里略举几例：

1. 体育比分转播。有 8 片比赛场地正在进行羽毛球比赛，每个场地的计分程序把当前比分发送到各自的 topic 上（第 1 号场地发送到 court1，第 2 号发送到 court2，以此类推）。需要用到比分的程序（赛场的大屏幕显示，网上比分转播等等）自己订阅感兴趣的 topic ，就能及时收到最新比分数据。由于本文实现的不是 100% 可靠广播，那么消息应该是 snapshot，而不是 incremental。（换句话说，消息的内容是“现在是几比几”，而不是“刚才谁得分”。）

2. 负载监控。每台机器上运行一个监控程序，周期性地把本机当前负载（CPU、网络、磁盘、温度）publish 到以 hostname 命名的 topic 上，这样需要用到这些数据的程序只要在 hub 订阅相应的 topic 就能获得数据，无需与多台机器直接打交道。（为了可靠起见，监控程序发送的消息里边应该包含时间戳，这样能防止 stale 数据，甚至一定程度上起到心跳的作用。）沿着这个思路，分布式系统中的服务程序也可以把自己的当前负载发布到 hub 上，供 load balancer 和 monitor 取用。

协议

为了简单起见，muduo 的 hub 示例采用以 '/r/n' 分界的文本协议，这样用 telnet 就能测试 hub。协议只有三个命令：

• sub /r/n
  • 该命令表示订阅 ，以后该 topic 有任何跟新都会发给这个 tcp 连接。在 sub 的时候，hub 会把该 上最近的消息发给此 subscriber。
• unsub /r/n
  • 该命令表示退订
• pub /r/n/r/n
  • 往 发送消息，内容为 。所有订阅了此 的 subscribers 会收到同样的消息“pub /r/n/r/n”

代码

muduo 示例中的 hub 分为几个部分：

• hub 服务程序，负责一对多的消息分发。它会记住每个 client 订阅了哪些 topic，只把消息发给特定的订阅者。代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/hub/hub.cc
• pubsub 库，为了方便编写使用 hub 服务的应用程序，我写了一个简单的 client library，用来和 hub 打交道。这个 library 可以订阅 topic、退订 topic、往指定 topic 发布消息。代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/hub/pubsub.h 和 http://code.google.com/p/muduo/source/browse/trunk/examples/hub/pubsub.cc
• sub 示例程序，这个命令行程序订阅一个或多个 topic，然后等待 hub 的数据。代码 http://code.google.com/p/muduo/source/browse/trunk/examples/hub/sub.cc
• pub 示例程序，这个命令行程序往某个 topic 发布一条消息，消息内容由命令行参数指定。代码 http://code.google.com/p/muduo/source/browse/trunk/examples/hub/pub.cc

一个程序可以既是 publisher 又是 subscriber，而且 pubsub 库只用一个 tcp 连接（这样 failover 比较简便）。

使用范例：

1. 开启 4 个命令行窗口
2. 在第一个窗口运行 $ hub 9999
3. 在第二个窗口运行 $ sub 127.0.0.1:9999 mytopic
4. 在第三个窗口运行 $ sub 127.0.0.1:9999 mytopic court
5. 在第四个窗口运行 $ pub 127.0.0.1:9999 mytopic "Hello world."  ，这时第二三号窗口都会打印 “mytopic: Hello world.”，表明收到了 mytopic 这个主题上的消息。
6. 在第四个窗口运行 $ pub 127.0.0.1:9999 court "13:11"  ，这时第三号窗口会打印 “court: 13:11”，表明收到了 court 这个主题上的消息。第二号窗口没有订阅此消息，故无输出。

借助这个简单的 pub/sub 机制，还可以做很多有意思的事情。比如把分布式系统中的程序的一部分 end-to-end 通信改为通过 pub/sub 来做（例如，原来是 A 向 B 发一个 SOAP request，B 通过同一个 tcp 连接发回 response (分析二者的通信只能通过查看 log 或用 tcpdump 截获）；现在是 A 往 topic_a_to_b 上发布 request，B 在 topic_b_to_a 上发 response），这样多挂一个 monitoring subscriber 就能轻易地查看通信双方的沟通情况，很容易做状态监控与 trouble shooting。