导语 | 近日，云+社区技术沙龙“腾讯开源技术”圆满落幕。本次沙龙邀请了多位腾讯技术专家围绕腾讯开源与各位开发者进行探讨，深度揭秘了腾讯开源项目TencentOS tiny、TubeMQ、Kona JDK、TARS以及MedicalNet。本文是对张国成老师演讲的整理。

本文要点：

一、Message Queue 简介

对于Message Queue(以下简称MQ)，Wiki百科上的定义指：不同进程之间或者相同进程不同线程之间的一种通讯方式，它是一种通讯方式。

那我们为什么要采用MQ呢？这是由MQ的特点来决定的。第一是因为它可以整合多个不同系统共同协作；第二是它可以解耦，进行数据传递和处理；第三是它可以做峰值的缓冲处理，我们平常接触到的像Kafka、RocketMQ、Pulsar等基本上也都有这样的特点。

那作为大数据场景下的MQ又有什么特点呢？从我个人的理解来说，就是高吞吐低延时，系统尽可能地稳定，成本尽可能地低，协议也不需要特别地复杂，特别是水平扩展能力要尽可能的高。

因为像海量数据基本上都是到百亿、千亿、万亿，比方说我们自己的生产环境可能一个月、一年的时间就会翻一番，如果没有横向的扩展能力，系统就很容易出现各种问题。

二、TubeMQ实现原理及使用介绍

那么，腾讯自研的TubeMQ又有什么样的特点呢？TubeMQ属于万亿级分布式消息中间件，专注于海量数据下的数据传输和存储，在性能、可靠性，和成本方面具有独特的优势。

针对大数据场景的应用，我们给出了一个测试方案（详细方案在腾讯TubeMQ开源docs目录里可以查询得到）。首先我们要做一个实际应用场景定义，在这个定义之下，再进行系统数据的收集整理。结果是：我们的吞吐量达到了14万的TPS，消息时延可以做到5ms以内。

可能有些人会感到好奇，因为有很多研究报告都分析过，同样的分布式发布订阅消息系统，例如Kafka这种，都能达到上百万的TPS。相比来说，我们的数据会不会显得太差？

其实这里是有一个前提的，那就是：我们是在1000个Topic中，并为每个Topic配置10个Partition的场景下达到的性能指标。对于Kafka，它或许可以达到百万级的TPS，或许时延可以降到很低，但在我们的大数据的场景下，就远远到不了这个量级。

我们的系统在线上已经稳定运行了7年的时间，系统的架构采用的是瘦客户端、偏服务器管控模型。这样的技术特点就决定了它相应的应用场景。比如实时的广告推荐、海量的数据上报、指标&监控、流处理、以及IOT场景下的数据上报等。

部分数据有损是可以允许的，因为大不了重复再报一下也可以解决，但是考虑到数据的量级实在太大，所以只能牺牲部分的可靠性来换取高性能的数据接入。

TubeMQ系统架构是怎样的？如下图所示，它通过一个SDK与外部交互，当然直接通过我们定义的TCP协议实现对接也是可以的。

值得注意的是：TubeMQ是纯Java编写的，它拥有Master HA的协调节点，采用弱zk来管理Offset。在消息存储模式上也同样进行了改进，调整了数据可靠性的方案，采用的是磁盘RAID10多副本+快速消费，而非多Broker节点多副本的方案，而且启用了元数据自管理模式等。

如下图所示，自有数据记录以来，我们一共经历了四个阶段，从引入到改进再到开始自研，再到现在的自我创新。从2013年6月最开始的200亿，到2019年11月的35万亿，预计2020年能达到40万亿。

总的来说，这也是我们当初要选择自研的重要的原因。因为当数据量还不大的时候，比如在10亿或者是10亿量级以下，用什么样MQ其实都是可以的。但是一旦达到百亿、百亿到千亿、千亿到万亿甚至是万亿以上数据量的时候，越来越多的制约因素就会相继出现，包括系统的稳定性、性能以及机器成本和运维成本等问题。

我们现网TubeMQ拥有1500台的机器，而1500台机器就只需要用到一个左右的人力来运维就可以了（非全职的两个人）。对于我们的Broker存储服务器，能够做到上线持续运行4个月不重启，这些都是我们在原基础之上所做的改进和创新带来的。

下图的这个表格是TubeMQ与其他MQ横向比较的数据情况，我们项目是开源的，大家如果感兴趣的话可以直接去验证一下。总的来说，TubeMQ比较适合需要高性能、低成本又容许极端情况下有数据损失的场景，是经得起实践考验的。