MQ技术产品井喷，今天来详聊一下腾讯开源消息中间件TubeMQ|原力计划

作者 | kimmking

来源 | CSDN博客&＃xff0c;责编 | 夕颜

出品 | CSDN&＃xff08;ID:CSDNnews&＃xff09;

随着分布式技术的发展&＃xff0c;MQ技术产品也出现井喷。目前除了各类常用的MQ&＃xff0c;比如Apache的ActiveMQ&＃xff0c;Kafka&＃xff0c;Pulsar&＃xff0c;RocketMQ&＃xff08;既是Apache&＃xff0c;也是阿里的&＃xff0c;头条也是基于RocketMQ&＃xff09;&＃xff0c;以及RabbitMQ&＃xff08;美团、汽车之家大量使用&＃xff09;外&＃xff0c;各大厂商都自研了自己的产品&＃xff0c;腾讯的CMQ和TubeMQ&＃xff0c;京东的JMQ&＃xff0c;去哪儿的QMQ&＃xff0c;滴滴的DDMQ&＃xff08;基于RocketMQ&＃xff09;&＃xff0c;其中不少都开源了。这里说一下今年开源的TubeMQ。

腾讯开源的TubeMQ

官方介绍如下&＃xff1a;

https://github.com/Tencent/TubeMQ/blob/master/docs/tubemq_basic_introduction_cn.md

TubeMQ是腾讯大数据在2013年开始研发的分布式消息中间件系统&＃xff08;MQ&＃xff09;&＃xff0c;专注服务大数据场景下海量数据的高性能存储和传输。经过近7年上万亿的海量数据沉淀&＃xff0c;较之于众多的开源MQ组件&＃xff0c;TubeMQ在海量实践&＃xff08;稳定性&＃43;性能&＃xff09;和低成本方面有一定的优势&＃xff0c;近期我们在开源TubeMQ的相关代码及设计&＃xff0c;更多资料正在陆续整理。

TubeMQ集群架构&＃xff1a;

经过多年演变&＃xff0c;TubeMQ集群分为如下5个部分&＃xff1a;

• Portal&＃xff1a;负责对外交互和运维操作的Portal部分&＃xff0c;包括API和Web两块&＃xff0c;API对接集群之外的管理系统&＃xff0c;Web是在API基础上对日常运维功能做的页面封装&＃xff1b;

• Master&＃xff1a;负责集群控制的Control部分&＃xff0c;该部分由1个或多个Master节点组成&＃xff0c;Master HA通过Master节点间心跳保活、实时热备切换完成&＃xff08;这是大家使用TubeMQ的Lib时需要填写对应集群所有Master节点地址的原因&＃xff09;&＃xff0c;主Master负责管理整个集群的状态、资源调度、权限检查、元数据查询等&＃xff1b;

• Broker&＃xff1a; 负责实际数据存储的Store部分&＃xff0c;该部分由相互之间独立的Broker节点组成&＃xff0c;每个Broker节点对本节点内的Topic集合进行管理&＃xff0c;包括Topic的增、删、改、查&＃xff0c;Topic内的消息存储、消费、老化、分区扩容、数据消费的offset记录等&＃xff0c;集群对外能力&＃xff0c;包括Topic数目、吞吐量、容量等&＃xff0c;通过水平扩展Broker节点来完成&＃xff1b;

• Client&＃xff1a; 负责数据生产和消费的Client部分&＃xff0c;该部分我们以Lib形式对外提供&＃xff0c;大家用得最多的是消费端&＃xff0c;相比之前&＃xff0c;消费端现支持Push、Pull两种数据拉取模式&＃xff0c;数据消费行为支持顺序和过滤消费两种。对于Pull消费模式&＃xff0c;支持业务通过客户端重置精确offset以支持业务extractly-once消费&＃xff0c;同时&＃xff0c;消费端新推出跨集群切换免重启的BidConsumer客户端&＃xff1b;

• Zookeeper&＃xff1a; 负责offset存储的zk部分&＃xff0c;该部分功能已弱化到仅做offset的持久化存储&＃xff0c;考虑到接下来的多节点副本功能该模块暂时保留。

比较常规的分布式MQ结构&＃xff0c;broker功能比较重。

相比Kafka,TubeMQ的系统特点&＃xff1a;

1. 纯Java实现语言&＃xff1a;TubeMQ采用纯Java语言开发&＃xff0c;便于开发人员快速熟悉项目及问题处理&＃xff1b;

2. 引入Master协调节点&＃xff1a;相比Kafka依赖于Zookeeper完成元数据的管理和实现HA保障不同&＃xff0c;TubeMQ系统采用的是自管理的元数据仲裁机制方式进行&＃xff0c;Master节点通过采用内嵌数据库BDB完成集群内元数据的存储、更新以及HA热切功能&＃xff0c;负责TubeMQ集群的运行管控和配置管理操作&＃xff0c;对外提供接口等&＃xff1b;通过Master节点&＃xff0c;TubeMQ集群里的Broker配置设置、变更及查询实现了完整的自动化闭环管理&＃xff0c;减轻了系统维护的复杂度&＃xff1b;

3. 服务器侧消费负载均衡&＃xff1a;TubeMQ采用的是服务侧负载均衡的方案&＃xff0c;而不是客户端侧操作&＃xff0c;提升系统的管控能力同时简化客户端实现&＃xff0c;更便于均衡算法升级&＃xff1b;

4. 系统行级锁操作&＃xff1a;对于Broker消息读写中存在中间状态的并发操作采用行级锁&＃xff0c;避免重复问题&＃xff1b;

5. Offset管理调整&＃xff1a;Offset由各个Broker独自管理&＃xff0c;ZK只作数据持久化存储用&＃xff08;最初考虑完全去掉ZK依赖&＃xff0c;考虑到后续的功能扩展就暂时保留&＃xff09;&＃xff1b;

6. 消息读取机制的改进&＃xff1a;相比于Kafka的顺序块读,TubeMQ采用的是消息随机读取模式,同时为了降低消息时延又增加了内存缓存读写,对于带SSD设备的机器,增加消息滞后转SSD消费的处理&＃xff0c;解决消费严重滞后时吞吐量下降以及SSD磁盘容量小、刷盘次数有限的问题&＃xff0c;使其满足业务快速生产消费的需求&＃xff08;后面章节详细介绍&＃xff09;&＃xff1b;

7. 消费者行为管控&＃xff1a;支持通过策略实时动态地控制系统接入的消费者行为&＃xff0c;包括系统负载高时对特定业务的限流、暂停消费&＃xff0c;动态调整数据拉取的频率等&＃xff1b;

8. 服务分级管控&＃xff1a;针对系统运维、业务特点、机器负载状态的不同需求&＃xff0c;系统支持运维通过策略来动态控制不同消费者的消费行为&＃xff0c;比如是否有权限消费、消费时延分级保证、消费限流控制&＃xff0c;以及数据拉取频率控制等&＃xff1b;

9. 系统安全管控&＃xff1a;根据业务不同的数据服务需要&＃xff0c;以及系统运维安全的考虑&＃xff0c;TubeMQ系统增加了TLS传输层加密管道&＃xff0c;生产和消费服务的认证、授权&＃xff0c;以及针对分布式访问控制的访问令牌管理&＃xff0c;满足业务和系统运维在系统安全方面的需求&＃xff1b;

10. 资源利用率提升改进&＃xff1a;相比于Kafka&＃xff0c;TubeMQ采用连接复用模式&＃xff0c;减少连接资源消耗&＃xff1b;通过逻辑分区构造&＃xff0c;减少系统对文件句柄数的占用&＃xff0c;通过服务器端过滤模式&＃xff0c;减少网络带宽资源使用率&＃xff1b;通过剥离对Zookeeper的使用&＃xff0c;减少Zookeeper的强依赖及瓶颈限制&＃xff1b;

11. 客户端改进&＃xff1a;基于业务使用上的便利性以&＃xff0c;我们简化了客户端逻辑&＃xff0c;使其做到最小的功能集合&＃xff0c;我们采用基于响应消息的接收质量统计算法来自动剔出坏的Broker节点&＃xff0c;基于首次使用时作连接尝试来避免大数据量发送时发送受阻&＃xff08;具体内容见后面章节介绍&＃xff09;。

这一块基本上说清楚了特点&＃xff0c;以及与其他MQ的一些特色的地方&＃xff0c;其实可以猜到&＃xff0c;一直在和kafka做对比&＃xff0c;很多地方参与并改进了kafka&＃xff0c;在管理能力上做了不少思考和新的实现。

TubeMQ客户端的演进&＃xff1a;

业务与TubeMQ接触得最多的是消费侧&＃xff0c;怎样更适应业务特点、更方便业务使用我们在这块做了比较多的改进&＃xff1a;

数据拉取模式支持Push、Pull&＃xff1a;

• Push客户端&＃xff1a;TubeMQ最初消费端版本只提供Push模式的消费&＃xff0c;这种模式能比较快速地消费数据&＃xff0c;减轻服务端压力&＃xff0c;但同时也带来一个问题&＃xff0c;业务使用的时候因为无法控制拉取频率&＃xff0c;从而容易形成数据积压数据处理不过来&＃xff1b;

• • 带消费中止/继续的Push客户端&＃xff1a;在收到业务反馈能否控制Push拉取动作的需求后&＃xff0c;我们增加了resumeConsume()/pauseConsume()函数对&＃xff0c;让业务可以模拟水位线控制机制&＃xff0c;状态比较繁忙时调用pauseConsume()函数来中止Lib后台的数据拉取&＃xff0c;在状态恢复后&＃xff0c;再调用resumeConsume()通知Lib后台继续拉取数据&＃xff1b;

  • Pull客户端&＃xff1a;我们后来版本里增加了Pull客户端&＃xff0c;该客户端有别于 – Push客户端&＃xff0c;是由业务而非Lib主动的拉取消息并对数据处理的结果进行成功与否的确认&＃xff0c;将数据处理的主动权留给业务。这样处理后&＃xff0c;虽然服务端压力有所提升&＃xff0c;但业务消费时积压情况可大大缓解。

• 数据消费行为支持顺序和过滤消费&＃xff1a;在TubeMQ设计初我们考虑是不同业务使用不同的Topic&＃xff0c;实际运营中我们发现不少业务实际上是通过代理模式上报的数据&＃xff0c;数据通过Topic下的文件ID或者表ID属性来区分&＃xff0c;业务为了消费自己的一份数据是需要全量消费该Topic下的所有数据。我们通过tid字段支持指定属性的过滤消费模式&＃xff0c;将数据过滤放到服务端来做&＃xff0c;减少出流量以及客户端的数据处理压力。

• 支持业务extractly-once消费&＃xff1a;为了解决业务处理数据时需要精确回档的需求&＃xff0c;在客户端版本里提供了通过客户端重置精确offset功能&＃xff0c;业务重启系统时&＃xff0c;只需通过客户端提供待回拨时间点的消费上下文&＃xff0c;TubeMQ即可按照指定的精确位置接续消费。该特性目前已在Flink这类实时计算框架使用&＃xff0c;依托Flink基于checkpoint机制进行extractly-once数据处理。

推和拉是消息处理的两个最基础模式。推对服务器处理来说更简单&＃xff0c;推出去就不管了&＃xff0c;broker变轻&＃xff0c;但是可能单位时间推太多&＃xff0c;导致消费端积压&＃xff0c;压垮了client端系统。拉则意味着&＃xff0c;你随时来拿数据&＃xff0c;broker都要保持状态而且会产生积压&＃xff0c;还需要处理重试策略等。有了offset则意味着可以随时回溯消息&＃xff0c;但是这样可能会导致重复&＃xff0c;如果没有内置的去重其实不是extractly once&＃xff0c;而是atleast once&＃xff0c;消息会重复。

其他几个mq

滴滴的DDMQ&＃xff1a;

https://github.com/didi/DDMQ/blob/master/README_CN.md

去哪儿网的QMQ&＃xff1a;

https://github.com/qunarcorp/qmq

有意思的几个点

TubeMQ跟 kafka&＃xff0c;rocketmq&＃xff0c;pulsar等主流的MQ架构上有什么差别&＃xff1f;

官方给出的意见是&＃xff1a;

Kafka按照顺序写 &＃43; 顺序块读的模式实现&＃xff0c;单实例下性能数据很强&＃xff0c;但随着实例数增多&＃xff0c;它的性能就呈现不稳定下降状态&＃xff1b;TubeMQ采用顺序写 &＃43; 随机读的模式&＃xff0c;即使在最大限制下系统仍可以做到长期稳定的1G以上的入流量&＃xff0c;同时&＃xff0c;结合服务端过滤过滤消费非常顺畅。

个人对这个持保留意见&＃xff0c;大量创建topic不适合kafka的设计原则&＃xff08;一般我们建议单集群的topic数量在100以内&＃xff0c;过多的小topic造成随机读写&＃xff0c;但是可以合并&＃xff0c;然后区分和路由消息即可&＃xff09;&＃xff0c;同时如果改成SSD盘也可以提升吞吐和延迟&＃xff0c;几千个topic问题不大。而且kafka的延迟也不像上面的文档里对比说的250ms&＃xff0c;我们实际使用大概在10-40ms之间。

TubeMQ看了一下&＃xff0c;整体设计跟pulsar有点像&＃xff0c;主要是broker和storage做了分离&＃xff1b;消息处理模式上跟ActiveMQ到底有些许接近。

几个有意思的地方&＃xff1a;

1、TubeMQ不支持多副本&＃xff0c;这样的话单机有可能还是在极端情况下丢失数据&＃xff0c;但多副本是目前的各种分布式消息队列的标配&＃xff08;看了一下腾讯云上的商业版本CMQ是支持的。&＃xff09;

2、服务器侧消费负载均衡&＃xff0c;早期版本的kafka是这样的&＃xff0c;问题挺多

3、消息随机读&＃xff0c;这样需要加内存缓存和依赖SSD&＃xff0c;挺诡异&＃xff0c;为了并发又加了锁&＃xff0c;这一块很复杂&＃xff0c;ActiveMQ就是因为内存的处理太复杂&＃xff0c;导致量一大&＃xff0c;谁都用不好

4、同时支持推和拉&＃xff0c;这一点也挺有意思&＃xff0c;跟第一条一条有关系&＃xff0c;要是支持推的话&＃xff0c;服务端肯定需要有状态

5、支持服务器端的消息过滤&＃xff0c;现在一般的MQ都是客户端过滤&＃xff0c;也同理。

MQ发现到现在&＃xff0c;一共经历了三代&＃xff0c;分别以ActiveMQ&＃xff0c;Kafka/RocketMQ&＃xff0c;Pulsar为代表&＃xff0c;从趋势上来看&＃xff0c;越来越分布式、趋向对云原生的支持&＃xff0c;越来越无状态&＃xff0c;broker越来越轻薄。

总之这个方案看起来是综合了传统和现在的各个MQ的一些特点&＃xff0c;但是实现的很重。

还有个tip&＃xff0c;TubeMQ里的组件名称有点乱&＃xff0c;叫master的东西&＃xff0c;实际上是broker&＃xff0c;叫broker的东西&＃xff0c;实际上是storage&＃xff08;在pulsar里是bookie&＃xff09;。

原文链接&＃xff1a;

https://blog.csdn.net/KimmKing/article/details/103133789

同时&＃xff0c;欢迎所有开发者扫描下方二维码填写《开发者与AI大调研》&＃xff0c;只需2分钟&＃xff0c;便可收获价值299元的「AI开发者万人大会」在线直播门票!

推荐阅读&＃xff1a;你知道吗&＃xff1f;其实 Oracle 直方图自动统计算法存在这些缺陷&＃xff01;&＃xff08;附验证步骤&＃xff09;
你公司的虚拟机还闲着&＃xff1f;基于 Jenkins 和 Kubernetes 的持续集成测试实践了解一下&＃xff01;一站式杀手级 AI 开发平台来袭&＃xff01;告别切换零散建模工具那些神一样的程序员
比特币当赎金&＃xff0c;WannaRen 勒索病毒二度来袭&＃xff01;通过 Python 代码实现时间序列数据的统计学预测模型
真香&＃xff0c;朕在看了&＃xff01;