本篇文章给大家伙儿一起来分享的是有关哪些场景下适合用Apache TubeMQ，小编觉得挺实用的，因此分享给大家学习，希望我们大家阅读完这篇文章后可以有所收获，话不多说，跟着小编共同来看看吧。
Apache TubeMQ是腾讯于2019年对外开源后捐献给Apache的新一代MQ，其源于腾讯公司的实际生产环境，专注服务海量数据的高性能存储和传输，在MQ已是红海的今天（仅Apache就已经有5个MQ），较之于众多的开源MQ组件，Apache TubeMQ到底有些什么特点，我们在什么场景下适用，应用这样的产品能给我们大家带来啥好处？下面想从这点进行介绍。
技术栈纯JAVA，便于自行改造及版本维护，即使版本有问题也能够迅速协调资源立即止损；
功能上只要生产消费，不需要事务消息、Exactly Once等高级功能；
线万亿的数据量级服务沉淀，Apache TubeMQ源于腾讯公司的实际生产环境，最初我们也如大多数业务样采用Apache Kafka进行数据服务，但由于Kafka服务端采用Scala实现，阅读、维护较为困难，出问题没办法立即解决，同时Kafka设计存在一些不太合理的地方，用起来比较的复杂；在现网压力下，我们基于Kafka的思想以及实际需要，萌发了做一款基于服务端管控的以SAAS模式对外服务的高可靠、高性能、低延迟、低成本的分布式消息中间件思路，并围绕这一个项目定位进行了产品构建及持续改进。
到目前为止，Apache TubeMQ专注服务大数据场景已近8年的时间，目前已达到了日均40万亿+的吞吐量级，形成了较稳定、易于维护的久经考验产品，服务的业务包括了广点通、PCG、微信等，我们最大的集群规模超过300台Broker，每个Broker配置的topic达到800个，消费组有近3K的规模。
基于腾讯内部各种业务的需求打磨出来的这款MQ，我们很确定一定也适合大家在类似业务场景上的使用。
单机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，机器量级会更低。
Apache TubeMQ能达到我们所述的特点，主要源于其依据业务场景构建的TubeMQ 架构，我们内部不仅自己用这套系统支撑服务，同时我们还将其开源出来，按照Apache规则进行项目孵化，让更多的外部公司的业务来使用它，通过它来降成本，提升系统性能和稳定能力。系统足够的稳定，有过MQ经验的同学按照官网上的指引进行搭建即可运行起来；系统完全开源且采用纯JAVA构建，即使原创团队不再维护，市场上也有足够的技术人才支撑其改进；按照Apache社区规范来运作社区，只要你有任何的改进建议，验证有效都能合入系统，且原创团队都是国内人员，交流沟通更方便。
一站式的流数据服务平台，我们想将整个的数据上报平台在这一个项目里开源出来，将数据上报涉及的采集，汇聚，存储，转发等模块以插件化的形式有机的整合起来（即使是TubeMQ，也可以在这样的平台里进行更替），基于此系统，业务只有必要进行数据的发布和订阅，即可轻松构建基于流数据的分析和应用。 我们正在构建每个部分的模块，欢迎各位一起来共建。
以上就是哪些场景下适合用Apache TubeMQ，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。
