腾讯：MQ 技术产品井喷，今天来详聊一下腾讯开源消息中间件 TubeMQ

支持业务extractly-once消费：为了解决业务处理数据时需要精确回档的需求，在客户端版本里提供了通过客户端重置精确offset功能，业务重启系统时，只需通过客户端提供待回拨时间点的消费上下文， TubeMQ即可按照指定的精确位置接续消费。该特性目前已在Flink这类实时计算框架使用，依托Flink基于checkpoint机制进行extractly-once数据处理。

推和拉是消息处理的两个最基础模式。推对服务器处理来说更简单，推出去就不管了， broker变轻，但是可能单位时间推太多，导致消费端积压，压垮了client端系统。拉则意味着，你随时来拿数据， broker都要保持状态而且会产生积压，还需要处理重试策略等。有了offset则意味着可以随时回溯消息，但是这样可能会导致重复，如果没有内置的去重其实不是extractly once ，而是atleast once ，消息会重复。

腾讯：MQ 技术产品井喷，今天来详聊一下腾讯开源消息中间件 TubeMQ | 原力计划

本文插图

其他几个mq
滴滴的DDMQ：
https://github.com/didi/DDMQ/blob/master/README_CN.md
去哪儿网的QMQ：
https://github.com/qunarcorp/qmq

本文插图

有意思的几个点
TubeMQ跟 kafka ， rocketmq ， pulsar等主流的MQ架构上有什么差别？
官方给出的意见是：
Kafka按照顺序写 + 顺序块读的模式实现，单实例下性能数据很强，但随着实例数增多，它的性能就呈现不稳定下降状态；TubeMQ采用顺序写 + 随机读的模式，即使在最大限制下系统仍可以做到长期稳定的1G以上的入流量，同时，结合服务端过滤过滤消费非常顺畅。
个人对这个持保留意见，大量创建topic不适合kafka的设计原则（一般我们建议单集群的topic数量在100以内，过多的小topic造成随机读写，但是可以合并，然后区分和路由消息即可），同时如果改成SSD盘也可以提升吞吐和延迟，几千个topic问题不大。而且kafka的延迟也不像上面的文档里对比说的250ms ，我们实际使用大概在10-40ms之间。
TubeMQ看了一下，整体设计跟pulsar有点像，主要是broker和storage做了分离；消息处理模式上跟ActiveMQ到底有些许接近。
几个有意思的地方：
1、TubeMQ不支持多副本，这样的话单机有可能还是在极端情况下丢失数据，但多副本是目前的各种分布式消息队列的标配（看了一下腾讯云上的商业版本CMQ是支持的。）
2、服务器侧消费负载均衡，早期版本的kafka是这样的，问题挺多
3、消息随机读，这样需要加内存缓存和依赖SSD ，挺诡异，为了并发又加了锁，这一块很复杂， ActiveMQ就是因为内存的处理太复杂，导致量一大，谁都用不好
4、同时支持推和拉，这一点也挺有意思，跟第一条一条有关系，要是支持推的话，服务端肯定需要有状态
5、支持服务器端的消息过滤，现在一般的MQ都是客户端过滤，也同理。
MQ发现到现在，一共经历了三代，分别以ActiveMQ ， Kafka/RocketMQ ， Pulsar为代表，从趋势上来看，越来越分布式、趋向对云原生的支持，越来越无状态， broker越来越轻薄。
总之这个方案看起来是综合了传统和现在的各个MQ的一些特点，但是实现的很重。
还有个tip ， TubeMQ里的组件名称有点乱，叫master的东西，实际上是broker ，叫broker的东西，实际上是storage（在pulsar里是bookie）。
：）
原文链接：
https://blog.csdn.net/KimmKing/article/details/103133789