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

本文插图

作者 | kimmking
来源 | CSDN博客，责编 | 夕颜
出品 | CSDN（ID:CSDNnews）
随着分布式技术的发展， MQ技术产品也出现井喷。目前除了各类常用的MQ ，比如Apache的ActiveMQ ， Kafka ， Pulsar ， RocketMQ（既是Apache ，也是阿里的，头条也是基于RocketMQ），以及RabbitMQ（美团、汽车之家大量使用）外，各大厂商都自研了自己的产品，腾讯的CMQ和TubeMQ ，京东的JMQ ，去哪儿的QMQ ，滴滴的DDMQ（基于RocketMQ），其中不少都开源了。这里说一下今年开源的TubeMQ 。

本文插图

腾讯开源的TubeMQ
官方介绍如下：
https://github.com/Tencent/TubeMQ/blob/master/docs/tubemq_basic_introduction_cn.md
TubeMQ是腾讯大数据在2013年开始研发的分布式消息中间件系统（MQ），专注服务大数据场景下海量数据的高性能存储和传输。经过近7年上万亿的海量数据沉淀，较之于众多的开源MQ组件， TubeMQ在海量实践（稳定性+性能）和低成本方面有一定的优势，近期我们在开源TubeMQ的相关代码及设计，更多资料正在陆续整理。
TubeMQ集群架构：
经过多年演变， TubeMQ集群分为如下5个部分：

本文插图

Portal：负责对外交互和运维操作的Portal部分，包括API和Web两块， API对接集群之外的管理系统， Web是在API基础上对日常运维功能做的页面封装；
Master：负责集群控制的Control部分，该部分由1个或多个Master节点组成， Master HA通过Master节点间心跳保活、实时热备切换完成（这是大家使用TubeMQ的Lib时需要填写对应集群所有Master节点地址的原因），主Master负责管理整个集群的状态、资源调度、权限检查、元数据查询等；
Broker：负责实际数据存储的Store部分，该部分由相互之间独立的Broker节点组成，每个Broker节点对本节点内的Topic集合进行管理，包括Topic的增、删、改、查， Topic内的消息存储、消费、老化、分区扩容、数据消费的offset记录等，集群对外能力，包括Topic数目、吞吐量、容量等，通过水平扩展Broker节点来完成；
Client：负责数据生产和消费的Client部分，该部分我们以Lib形式对外提供，大家用得最多的是消费端，相比之前，消费端现支持Push、Pull两种数据拉取模式，数据消费行为支持顺序和过滤消费两种。对于Pull消费模式，支持业务通过客户端重置精确offset以支持业务extractly-once消费，同时，消费端新推出跨集群切换免重启的BidConsumer客户端；
Zookeeper：负责offset存储的zk部分，该部分功能已弱化到仅做offset的持久化存储，考虑到接下来的多节点副本功能该模块暂时保留。