简介
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
#之后可以生产和消费数据了
网友评论