简单粗暴的ZMQ通知中转

大家好，这里是tiankonguse的公众号(tiankonguse-code)。
tiankonguse曾是一名ACMer，现在是鹅厂视频部门的后台开发。
这里主要记录算法，数学，计算机技术等好玩的东西。

这篇文章从公众号tiankonguse-code自动同步过来。
如果转载请加上署名：公众号tiankonguse-code，并附上公众号二维码，谢谢。

零、背景

之前在介绍《浅谈中转系统》时提到，当年视频遇到各种资料变更需要通知很多业务方的问题。
原始的解决方案是每个资料对应的开发各自调用需要感知数据变更的业务方接口。
这样方案是的数据生产者和数据消费者耦合加深，生产者和消费者边多后维护成本变得非常号。
2013年5月的时候，于是hades提出要实现一个支持数据变更通知的消息队列。

一、系统架构

由于是解耦，自然是加一个消息队列中间层。
生产者将数据发给ZMQ消息队列，ZMQ消息队列将所有消息发给链接的所有消费者，消费者过滤自己需要的数据。

二、系统分析

对于消息队列系统或者中转系统，我们一般关心两个问题：怎么区分不同的资料数据，传输的是什么数据，怎么知道消费者需要消费哪些数据。

1. 怎么区分数据

在之前的文章《浅谈中转系统》中曾提到过，这个系统为每一种资料分配了一个唯一的编号。

这个系统设计的相当暴力，这个编号起初是在代码写死的，后来由于加编号不方便，大家就口头约定编号了。
后来没人知道哪个编号是什么意思了。 /(ㄒoㄒ)/~~

2. 传输什么数据

这个同样在《浅谈中转系统》中提到。
因为我们要做的是一个资料变更的通知系统，所以只需要带上变更数据的主键即可。

后来，搜索组也要储存视频的全量数据了，但是数据变更时只接收到数据的主键，于是他们拿着这个主键去我的UNION系统拉取数据。
再后开很多组都这样做时，UNION系统的压力就相当大了，于是就有了另一篇文章：《每秒千万每天万亿级别服务之诞生》。

实际上做的比较好的方法时带上变更的字段，然后业务只需要去拉取变更的字段即可。
当然要实现这个实际上也有很多问题的，不够我们后来还是做了这么一套系统，有空了可以也分享一下。

3. 消费哪些数据

由于这个系统的中心纯粹是一个数据转发服务，没有任何配置。
所以某个消费者要消费哪些数据服务中心是完成不知道的，服务中心只好把所有数据全部转发给所有的消费者。

每个消费者知道自己消费哪些数据的，所以在消费者初始化的时候需要设置自己消费哪些数据。
消费API接收到数据后会把无关的数据过滤掉。

4. 其他

实际做一个系统不仅仅要考虑功能上的需求，还需要考虑容灾问题。
比如服务中心挂了怎么办？全部转发数据流量满了怎么办？某个生产者异常生产大量数据怎么办？
是的！这个系统当时是快速开发的，都没有去考虑这些。

由于这个系统只支持传递数据的主键，所以流量不会成为问题。
不过2015年还是发生了其他两件事，影响颇为严重。
第一件事是这个单机服务挂了，跑了两年终于挂了一次，半夜发生的，导致半天的消息都没有发出去，很多地方数据不更新了。
第二件事是一个新同事触发的。有一个程序更新数据前会检查数据是否变更，没变更就不更新数据。这位同事把这个逻辑去掉了，直接更新数据，导致生成者生产大量消息。

发生了这几件时候，老大说我们换到微博中转吧。
于是ZMQ消息队列就这么慢慢的退出了历史舞台。

三、总结

这个系统总体来看相当简单，今天我花了半个小时就把生产者，中心服务，消费者的代码全看完了。写的也相当简洁。
不像我们现在的系统，做之前就考虑各种情况，各种配置，各种容灾，各种特殊逻辑，代码特别复杂，看一眼都不想看了。

最后送上高清版的《纪念碑谷2》吧。

对了现在开通了公众号和小密圈。
博客记录所有内容。
技术含量最高的文章放在公众号发布。
比较好玩的算法放在小密圈发布。
小密圈这周接受免费加入，欢迎大家加入看各种算法的思路。

长按图片关注公众号，接受最新文章消息。