简介
TubeMQ 是腾讯在 2013 年自研的分布式消息中间件系统，专注服务大数据场景下海量数据的高性能存储和传输，较之于众多明星的开源 MQ组件，TubeMQ 在海量实践（稳定性+性能）和低成本方面有着比较好的核心优势。
2019 年 9 月 12 日，Apache 软件基金会成立 20 周年之际，腾讯在 ApacheCon 宣布 TubeMQ 捐赠给 ASF。TubeMQ 成为腾讯开源第一个捐赠 Apache 基金会的项目。
目前，tubemq已经改名为inlong(应龙)。
优势
- 高吞吐：大数据满负载场景下，消息吞吐量可以达到14W TPS，且系统运行平稳。
- 低时延：；满负载场景下，从生产到消费，可以做到5ms以内。
- 稳定性高：系统线上运营近7年，目前过35万亿的日均消息接入条数近1500台机器，运维人员不到1个人力资源，系统除了版本发布系统可以连续不间断运营。
- 成本低：相比同类使用原生Kafka机器的业务，按照已知的横向数据比较，仅机器成本就可以节约至少4倍资源。
特性
- 纯 Java 实现语言
- 引入 Master 协调节点：相比 Kafka 依赖于 Zookeeper 完成元数据的管理和实现 HA 保障不同，TubeMQ 系统采用的是自管理的元数据仲裁机制方式进行，Master 节点通过采用内嵌数据库 BDB 完成集群内元数据的存储、更新以及 HA 热切功能，负责 TubeMQ 集群的运行管控和配置管理操作，对外提供接口等；通过 Master 节点，TubeMQ 集群里的 Broker 配置设置、变更及查询实现了完整的自动化闭环管理，减轻了系统维护的复杂度
- 服务器侧消费负载均衡：TubeMQ 采用的是服务侧负载均衡的方案，而不是客户端侧操作，提升系统的管控能力同时简化客户端实现，更便于均衡算法升级
- 系统行级锁操作：对于 Broker 消息读写中存在中间状态的并发操作采用行级锁，避免重复问题
- Offset 管理调整：Offset 由各个 Broker 独自管理，ZK 只作数据持久化存储用（最初考虑完全去掉ZK依赖，考虑到后续的功能扩展就暂时保留）
- 消息读取机制的改进：TubeMQ 采用的是消息随机读取模式,同时为了降低消息时延又增加了内存缓存读写,对于带 SSD 设备的机器,增加消息滞后转 SSD 消费的处理，解决消费严重滞后时吞吐量下降以及 SSD 磁盘容量小、刷盘次数有限的问题，使其满足业务快速生产消费的需求
- 消费者行为管控：支持通过策略实时动态地控制系统接入的消费者行为，包括系统负载高时对特定业务的限流、暂停消费，动态调整数据拉取的频率等；
- 服务分级管控：针对系统运维、业务特点、机器负载状态的不同需求，系统支持运维通过策略来动态控制不同消费者的消费行为，比如是否有权限消费、消费时延分级保证、消费限流控制，以及数据拉取频率控制等
- 系统安全管控：根据业务不同的数据服务需要，以及系统运维安全的考虑，TubeMQ 系统增加了 TLS 传输层加密管道，生产和消费服务的认证、授权，以及针对分布式访问控制的访问令牌管理，满足业务和系统运维在系统安全方面的需求
- 资源利用率提升改进：相比于 Kafka，TubeMQ 采用连接复用模式，减少连接资源消耗；通过逻辑分区构造，减少系统对文件句柄数的占用，通过服务器端过滤模式，减少网络带宽资源使用率；通过剥离对 Zookeeper 的使用，减少 Zookeeper 的强依赖及瓶颈限制
- 客户端改进：基于业务使用上的便利性以，我们简化了客户端逻辑，使其做到最小的功能集合，我们采用基于响应消息的接收质量统计算法来自动剔出坏的 Broker 节点，基于首次使用时作连接尝试来避免大数据量发送时发送受阻
架构
架构
- Portal： 负责对外交互和运维操作的Portal部分，包括API和Web两块，API对接集群之外的管理系统，Web是在API基础上对日常运维功能做的页面封装；
- Master： 负责集群控制的Control部分，该部分由1个或多个Master节点组成，Master HA通过Master节点间心跳保活、实时热备切换完成（这是大家使用inlong的Lib时需要填写对应集群所有Master节点地址的原因），主Master负责管理整个集群的状态、资源调度、权限检查、元数据查询等；
- Broker： 负责实际数据存储的Store部分，该部分由相互之间独立的Broker节点组成，每个Broker节点对本节点内的Topic集合进行管理，包括Topic的增、删、改、查，Topic内的消息存储、消费、老化、分区扩容、数据消费的offset记录等，集群对外能力，包括Topic数目、吞吐量、容量等，通过水平扩展Broker节点来完成；
- Client： 负责数据生产和消费的Client部分，该部分我们以Lib形式对外提供，大家用得最多的是消费端，相比之前，消费端现支持Push、Pull两种数据拉取模式，数据消费行为支持顺序和过滤消费两种。对于Pull消费模式，支持业务通过客户端重置精确offset以支持业务exactly-once消费，同时，消费端新推出跨集群切换免重启的BidConsumer客户端；
- Zookeeper： 负责offset存储的zk部分，该部分功能已弱化到仅做offset的持久化存储，考虑到接下来的多节点副本功能该模块暂时保留。
集群的安装部署
下载
git clone https://github.com/apache/incubator-inlong.git
编译
mvn clean package -Dmaven.test.skip
部署服务端
| 机器 | 角色 | 备注 |
|---|---|---|
| 10.224.148.145 | master | 元数据存储在/data/stage/metadata |
| broker | 消息存储在/data/stage/msgdata | |
| zk | offset存储在根目录/inlong | |
| 100.115.158.208 | master | 元数据存储在 /data/stage/metadata |
| broker | 消息储存在/data/stage/msgdata |
tar -zxvf inlong-server-3.8.0-bin.tar.gz
cd inlong-server-3.8.0
#配置conf/master.ini文件
#Master IP和端口
[master]
hostName=YOUR_SERVER_IP // 替换为当前主机IP
port=8000
webPort=8080
#访问授权Token
confModAuthToken=abc // 该token用于页面配置、API调用等
#ZooKeeper集群地址
[zookeeper]
zkNodeRoot=/tubemq
zkServerAddr=localhost:2181 // 指向zookeeper集群，多个地址逗号分开
#配置Replication策略
[replication]
repNodeName=tubemqMasterGroupNode1 // 每个master节点需使用不同名称
repHelperHost=FIRST_MASTER_NODE_IP:9001 // helperHost用于创建master集群，一般配置第一个master节点ip
#配置resources/velocity.properties文件
file.resource.loader.path=/INSTALL_PATH/tubemq-server-[TUBEMQ-VERSION]-bin/resources/templates
#配置conf/broker.ini文件
#Broker IP和端口
[broker]
brokerId=0
hostName=YOUR_SERVER_IP // 替换为当前主机IP，broker目前只支持IP
port=8123
webPort=8081
#Master地址
masterAddressList=MASTER_NODE_IP:8000 //多个master以逗号分隔
#数据目录
primaryPath=/stage/msgdata
#ZooKeeper集群地址
[zookeeper]
zkNodeRoot=/tubemq
zkServerAddr=localhost:2181 // 指向zookeeper集群，多个地址逗号分开
启动
#启动master
bin/master.sh start
#访问master的管控台
http://masterIp:8080/config/topic_list.htm
#在管控台新增broker
#在管控台上线broker
#启动broker
bin/broker.sh start
#在管控台新增topic
#在管控台重载受topic影响的broker
#之后可以生产和消费数据了
