您好,登录后才能下订单哦!
本篇文章给大家分享的是有关哪些场景下适合用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进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。