腾讯自研高吞吐消息队列组件TubeMQ升级为 TubeHub，挑战RocketMQ

TubeMQ简介

TubeMQ 是腾讯在 2013 年自研的分布式消息中间件系统，专一服务大数据场景下海量数据的高性能存储和传输，较之于众多明星的开源 MQ组件，TubeMQ 在海量实践（稳定性+性能）和低成本方面有着比较好的核心优点。

2019 年 9 月 12 日，Apache 软件基金会成立 20 周年之际，腾讯在 ApacheCon 宣布 TubeMQ 捐赠给 ASF。TubeMQ 成为腾讯开源第一个捐赠 Apache 基金会的项目。

变动说明

近日，Apache TubeMQ 项目负责人宣布该项目将进行全面升级拓展，并改名为 TubeHub 。

升级后的项目将命名为 TubeHub，具备全部组件可插拔、可隔离、可伸缩和可监控的云原生特性，为开发者提供一站式的流式大数据解决方案，包括自动、安全、高性能、分布式的数据发布订阅能力，便于使用者在业务上构建基于流式的数据应用，例如滚动的日志、MySQL 的 binlog 等。

在 Apache 基金会一年的项目孵化过程当中，项目团队新增了 40+ 的 contributores，社区提交了 400+ issuses，合并了 300+ PRs，共发布了 4 个版本。项目团队决定对 TubeMQ 进行全面的升级 —— 即在保留本来 mq 的功能特性以外，同时提供一个包含了大数据场景下的数据采集落地的总体集成方案。 

特性

• 纯 Java 实现语言

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

• 服务器侧消费负载均衡：TubeMQ 采用的是服务侧负载均衡的方案，而不是客户端侧操做，提高系统的管控能力同时简化客户端实现，更便于均衡算法升级

• 系统行级锁操做：对于 Broker 消息读写中存在中间状态的并发操做采用行级锁，避免重复问题

• Offset 管理调整：Offset 由各个 Broker 独自管理，ZK 只做数据持久化存储用（最初考虑彻底去掉ZK依赖，考虑到后续的功能扩展就暂时保留）

• 消息读取机制的改进：TubeMQ 采用的是消息随机读取模式,同时为了下降消息时延又增长了内存缓存读写,对于带 SSD 设备的机器,增长消息滞后转 SSD 消费的处理，解决消费严重滞后时吞吐量降低以及 SSD 磁盘容量小、刷盘次数有限的问题，使其知足业务快速生产消费的需求

• 消费者行为管控：支持经过策略实时动态地控制系统接入的消费者行为，包括系统负载高时对特定业务的限流、暂停消费，动态调整数据拉取的频率等；

• 服务分级管控：针对系统运维、业务特色、机器负载状态的不一样需求，系统支持运维经过策略来动态控制不一样消费者的消费行为，好比是否有权限消费、消费时延分级保证、消费限流控制，以及数据拉取频率控制等

• 系统安全管控：根据业务不一样的数据服务须要，以及系统运维安全的考虑，TubeMQ 系统增长了 TLS 传输层加密管道，生产和消费服务的认证、受权，以及针对分布式访问控制的访问令牌管理，知足业务和系统运维在系统安全方面的需求

• 资源利用率提高改进：相比于 Kafka，TubeMQ 采用链接复用模式，减小链接资源消耗；经过逻辑分区构造，减小系统对文件句柄数的占用，经过服务器端过滤模式，减小网络带宽资源使用率；经过剥离对 Zookeeper 的使用，减小 Zookeeper 的强依赖及瓶颈限制

• 客户端改进：基于业务使用上的便利性以，咱们简化了客户端逻辑，使其作到最小的功能集合，咱们采用基于响应消息的接收质量统计算法来自动剔出坏的 Broker 节点，基于首次使用时做链接尝试来避免大数据量发送时发送受阻