【Apache TubeMQ】什么场景下适合用Apache TubeMQ？

1. 前言：

Apache TubeMQ是腾讯于2019年对外开源后捐献给Apache的新一代MQ，其源于腾讯公司的实际生产环境，专注服务海量数据的高性能存储和传输，在MQ已是红海的今天（仅Apache就已经有5个MQ），较之于众多的开源MQ组件，Apache TubeMQ到底有些什么特点，我们在什么场景下适用，应用这个产品能给我们带来什么好处？本文想从这点进行介绍。

2. 什么场景下适用 Apache TubeMQ？

总结起来，主要是如下场景：

1. 数据上报量太大，普通MQ支撑不住；
2. 普通MQ能抗住，但消耗的机器资源太多，或者系统不稳定难维护
3. 技术栈纯JAVA，便于自行改造及版本维护，即使版本有问题也可以快速协调资源立即止损；
4. 功能上只要生产消费，不需要事务消息、Exactly Once等高级功能；
5. 系统自动化程度高，容忍极端情况下少量数据丢失。

3. 为什么Apache TubeMQ适合这些场景？

个人觉得主要有3点：

3.1. 源于实际的生产环境需要:

线上8年过40万亿的数据量级服务沉淀，Apache TubeMQ源于腾讯公司的实际生产环境，最初我们也如大多数业务样采用Apache Kafka进行数据服务，但由于Kafka服务端采用Scala实现，阅读、维护较为困难，出问题没办法立即解决，同时Kafka设计存在一些不太合理的地方，使用起来比较的复杂；在现网压力下，我们基于Kafka的思想以及实际需要，萌发了做一款基于服务端管控的以SAAS模式对外服务的高可靠、高性能、低延迟、低成本的分布式消息中间件思路，并围绕这个项目定位进行了产品构建及持续改进。

到目前为止，Apache TubeMQ专注服务大数据场景已近8年的时间，目前已达到了日均40万亿+的吞吐量级，形成了较稳定、易于维护的久经考验产品，服务的业务包括了广点通、PCG、微信等，我们最大的集群规模超过300台Broker，每个Broker配置的topic达到800个，消费组有近3K的规模。

基于腾讯内部各种业务的需求打磨出来的这款MQ，我们很确定一定也适合大家在类似业务场景上的使用。

3.2. 足够强的高吞吐高性能指标：

单机10W以上的TPS，10ms以下的端到端时延，这是一份Apache TubeMQ在开源初期做的一份性能压测对比总结报告tubemq_perf_test_vs_Kafka，总的来说，在TS60机型（万兆网卡，64G内存，24核CPU，12TSATA硬盘）下，配置1000个topic，每个topic配置10个分区，每条消息1K大小，在一份生产二份消费的前提下，单机Broker可以做到10W以上的TPS（TransactionsPerSecond的缩写，每秒成功的请求响应数），端到端时延10ms以下。这仅是我们给出的保守指标，我建议大家自己在相同场景下对比测试，大家可以拿任意外部MQ进行对比测试，会有不一样的发现。

很多MQ都有称系统能达到上千万的TPS，甚至1ms的端到端时延，我们给出的这个指标大家是否觉得太低了？我想表达的是，指标的提供是要有配套的测试前提的，在给出的明确系统配置、生产消费负载下，如果要达到千万级别的TPS，单机10W以上TPS的前提下，集群只需要不到100台的Broker横向扩展即可达到；如果没有如上系统配置、生产消费负载，达到千万级别的TPS，机器量级会更低。

3.3. 足够透明的开放度：

Apache TubeMQ能够达到我们所述的特点，主要源于其根据业务场景构建的TubeMQ 架构，我们内部不仅自己用这套系统支撑服务，同时我们还将其开源出来，按照Apache规则进行项目孵化，让更多的外部公司的业务来使用它，通过它来降成本，提升系统性能和稳定性。系统足够的稳定，有过MQ经验的同学按照官网上的指引进行搭建即可运行起来；系统完全开源且采用纯JAVA构建，即使原创团队不再维护，市场上也有足够的技术人才支撑其改进；按照Apache社区规范来运作社区，只要你有任何的改进建议，验证有效都能合入系统，且原创团队都是国内人员，交流沟通更方便。

4. Apache TubeMQ后续发展路线图是怎样？

一站式的流数据服务平台，我们想将整个的数据上报平台在这个项目里开源出来，将数据上报涉及的采集，汇聚，存储，转发等模块以插件化的形式有机的整合起来（即使是TubeMQ，也可以在这个平台里进行更替），基于此系统，业务只需要进行数据的发布和订阅，即可轻松构建基于流数据的分析和应用。
我们正在构建各个部分的模块，欢迎大家一起来共建。

5. 如何加入项目？

按照apache项目方式进行共建即可，具体可以参考如何加入TubeMQ