TubeMQ简介

TubeMQ 项目始于 2013 年，是腾讯自研的高吞吐消息队列组件。项目团队于 2019 年将 TubeMQ 捐赠给 Apache 基金会，成为腾讯首个被 Apache 基金会接受的项目。

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

详细信息

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

薛赵明表示，TubeHub 团队最终的目标是希望项目从目前的孵化阶段顺利毕业，成为 Apache 基金会顶级项目。同时希望能有更多的开源爱好者参与项目贡献，将各方一些好的思考和理念整合到 TubeHub 中，共同将其打造成为 Apache 社区中又一个非常有影响力的中国项目。

特性纯 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 节点，基于首次使用时作连接尝试来避免大数据量发送时发送受阻