本篇文章给大家分享的是有关哪些场景下适合用Apache TubeMQ，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。
Apache TubeMQ是腾讯于2019年对外开源后捐献给Apache的新一代MQ，其源于腾讯公司的实际生产环境，专注服务海量数据的高性能存储和传输，在MQ已是红海的今天（仅Apache就已经有5个MQ），较之于众多的开源MQ组件，Apache TubeMQ到底有些什么特点，我们在什么场景下适用，应用这个产品能给我们带来什么好处？下面想从这点进行介绍。
总结起来，主要是如下场景：
数据上报量太大，普通MQ支撑不住；
普通MQ能抗住，但消耗的机器资源太多，或者系统不稳定难维护
技术栈纯JAVA，便于自行改造及版本维护，即使版本有问题也可以快速协调资源立即止损；
功能上只要生产消费，不需要事务消息、Exactly Once等高级功能；
系统自动化程度高，容忍极端情况下少量数据丢失。
个人觉得主要有3点：
线上8年过40万亿的数据量级服务沉淀，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，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
