TubeMQ 万亿级分布式消息中间件

        TubeMQ是腾讯在2013年自研的分布式消息中间件系统，专注服务大数据场景下海量数据的高性能存储和传输，经过近7年上万亿的海量数据沉淀，目前日均接入量超过25万亿条。较之于众多明星的开源MQ组件，TubeMQ在海量实践（稳定性+性能）和低成本方面有着比较好的核心优势

TubeMQ User Guide:

https://github.com/Tencent/TubeMQ/blob/master/docs/tubemq_user_guide.md#top

Github 开源地址：

https://github.com/Tencent/TubeMQ

TubeMQ 国内镜像地址：https://git.code.tencent.com/Tencent_Open_Source/TubeMQ

TubeMQ系统特点

一. Java语言开发

   Tube MQ采用纯Java语言开发；

二. Master协调节点

    Tube MQ系统采用的是自管理的元数据仲裁机制方式进行，Master节点通过采用内嵌数据库BDB完成集群内元数据的存储、更新以及HA热切功能，负责Tube MQ集群的运行管控和配置管理操作，对外提供接口等；通过Master节点，Tube MQ集群里的Broker配置设置、变更及查询实现了完整的自动化闭环管理，减轻了系统维护的复杂度,

     与Kafka相比,Kafka依赖于Zookeeper完成元数据的管理和实现HA保障不一样，

三. 服务器侧消费负载均衡

    Tube MQ采用的是服务侧负载均衡的方案，

四. 系统行级锁操作

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

五、 消息读取机制的改进

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

六、 Offset管理调整

    Offset由各个Broker独自管理，ZK只作数据持久化存储用（最初考虑完全去掉ZK依赖，考虑到后续的功能扩展就暂时保留）；

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

八、客户端改进

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

九、系统安全管控

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

十、资源利用率提升改进

       和Kafka相比，Tube MQ采用连接复用模式，减少连接资源消耗；通过逻辑分区构造，减少系统对文件句柄数的占用，通过服务器端过滤模式，减少网络带宽资源使用率；通过剥离对Zookeeper的使用，减少Zookeeper的强依赖及瓶颈限制；

消息中间件比较

比较项	TubeMQ	Hippo	Kafka	Pulsar
数据时延	10毫秒	20毫秒级	250毫秒	10毫秒
请求TPS	单机14W+/s	不适用	单机10W+/s	10W+/s (大压力下不稳定)
过滤消费	支持服务端过滤	客户端过滤，不支持服务端过滤	客户端过滤，不支持服务端过滤	客户端过滤，不支持服务端过滤
数据副本同步策略	无，通过RAID10磁盘备份+低时延消费解决	类Paxos算法保障	多机异步备份	多机异步备份
数据可靠性	无数据同步策略，故单机故障未消费的数据存在丢失风险	高	一般，master未同步的数据存在丢失风险	一般，master未同步的数据存在丢失风险
系统稳定性	高，日均25万亿交易量， 稳定运行5年	无TubeMQ类似的运营场景	无TubeMQ类似的运营场景	无TubeMQ类似的运营场景
易用性	一般，只提供Java和C++的Lib	一般，只提供Java和C++的Lib	高，有很多配套插件使用	高，有很多配套插件使用