#研发中间件介绍#异步消息可靠推送Notify

郑昀基于朱传志的设计文档最后更新于2014/11/11

关键词：异步消息、订阅者集群、可伸缩、Push模式、Pull模式

本文档适用人员：研发

电商系统为什么需要 NotifyServer？

如子柳所说，电商系统『需要两种中间件系统，一种是实时调用的中间件（淘宝的HSF，高性能服务框架）、一种是异步消息通知的中间件（淘宝的Notify）』。那么用传统的 ActiveMQ/RabbitMQ 来实现异步消息发布和订阅不行吗？

2013年之前我们确实用的是 ActiveMQ，当然主要是订阅者 Pull 模式，选 MySQL 做消息持久化存储，SA 还为此反复测试了各种高可用方案，如下图所示，ActiveMQ 5.8，mq主从+mysql互为主从+MMM。

图1 mq 高可用

它有三个问题。

第一，它对上游发布者要求可能不是那么高，但要求下游实现消息订阅时要健壮，比如订阅者把消息读走了后它挂了也得不丢弃消息继续处理，比如非常重要的消息不能只有一个单点订阅者，必须有订阅者集群，但又不能重复处理消息。我在《#研发中间件介绍#JobCenter》中说过，对每一位开发者维护者提出高要求，这不是我们的解题思路。我在《职场培训第五期：职场的真相》中给出了解题思路：『要摒弃单纯依靠员工之间互相提醒、依靠个人认真细致来规避相同错误的固有思路，铁打营盘流水兵，靠人终归是靠不住的，最好靠遵循规则的机器』。是的，异步消息的可靠推送（Push），应该是消息中间件的职责。

第二，ActiveMQ 的高可用方案在可伸缩上不那么灵活，不适合电商业务。譬如说，我一开始用一组 [(mq1+mysql1(master角色)),(mq2+mysql2)] 来支撑所有业务的异步消息，但突然七夕节一个销售验证高峰即将到来，需要尽量平滑地把某些消息队列转移出去，用另一组支撑；或者我看某个消息队列的消息量比较大，想追加一个 mysql 节点单独存储它的消息。总之就是线上尽量平滑地扩容 mq server和 database，这事儿还得咱们自己从头搞才顺手。

最后一个问题是所有开源系统的典型问题，伴随着开源系统以及各种 Driver 的版本升级，我们会一路踏入它埋下的每一个大大小小的坑。当然，不是说我们自己写的中间件就没有 Bug，但 ActiveMQ 确实让人摊手，如下面的 RCA 案例所示。

RCA：ActiveMQ 的生产者流量控制导致订单中心大量线程挂起；
RCA：PHP连MQ超时导致主库连接被打满，引发众多应用数据不一致——原因在于 PHP::Stomp 包的默认重试次数和默认超时时间；
RCA：调小 ActiveMQ之持久化 MySQL 的 wait_timeout 导致发送 MQ 消息频频失败。

最终我们还是选择自己来面对如下场景，采用 Push 模式（NotifyServer 主动向下游 Push 消息）：

图2 一个异步消息需要很多订阅者集群分头处理

淘宝是怎么考虑这些问题的？

可靠性：

消息的投递分为两个阶段

发布者向Broker发送消息
Broker向订阅者投递消息

因此，消息有可能在三个地方丢失

发布者到Broker之间
Broker本身
从Broker到订阅者

稳定性

监视

Broker内存使用
消息收发功能
消息堆积情况
存储的插入速度
各个任务队列长度
其他各项即时统计数据等

控制

自动移除失效存储节点
优雅降级的控制
添加新存储节点
添加新Broker

限制

有可能产生重复消息
对订阅者的要求

幂等性 f(f(x)) = f(x)
重复调用多次产生的业务结果与调用一次产生的业务结果相同

它内部两个消息中间件产品的区别为：

图3 消息中间件对比

以上资料出自于《消息中间件-Notify的概念和原理.pdf》。

窝窝如何实现 NotifyServer 的？

2013年2月，经过几轮的讨论，技术选型初步确定，研发2部传志开始构建 NotifyServer。

他设计了如下概念：

图4 notifyserver 的几个角色概念

技术模型可以描述为：

模块关系

各个模块（队列、生产者、交换中心、DB、消息体缓存、队列缓存、日志缓存、分配中心、消费者）存在一定的对应关系，通过这些对应关系能够更好路由和分流消息，动态扩展系统，改善系统瓶颈。
这些对应关系都存储在控制中心关系数据库中，通过控制台界面来进行配置，各模块在启动和定时到控制中心来更新这些关系，用于消息的分配。
这些关系都遵守一定规则，添加更改不会影响系统的稳定性，如：一个队列必须对应两个以上的交换中心来处理消息，如果DB中还有消息没有消费完毕不允许直接删除，等等。