Apache InLong(Incubating) 在消息中间件上的改进 张国成

1 .Apache InLong(Incubating)在 消息中间件上的改进 Gosonzhang 2022/05/09 1 

2 .关于我 • Apache InLong (incubating) PPMC • 腾讯大数据 研发工程师 2 

3 .内容介绍 • 关于InLong • 大数据场景下的MQ需求 • 自研InLong-TubeMQ介绍 • InLong-TubeMQ进展 3 

4 .关于InLong Apache InLong（应龙）一站式海量数据集成框架，提供自动、安全、可靠和高性能的数据传输 能力，同时支持批和流，方便业务构建基于流式的数据分析、建模和应用。 Manager OpenAPI 元数据 集群 认证 调度器 名字服务 审计对账 指标监控 采集 汇聚 缓存层 分拣 入库 SDK DataProxy TubeMQ Sort Hive File 实时计算 Iceberg DataProxy Pulsar HTTP 离线计算 HBase DataProxy DB Kafka SDK ClickHouse 4 

5 .大数据场景下的MQ需求 异步调用 系统解耦 削峰填谷 广播通知 缓存 消息通讯 数据上报量太大，普通MQ支撑不住 成 本 普通MQ能抗住，但消耗的机器资源太多，或者系统不稳定难维护 性 能 技术栈纯JAVA，便于自行改造及版本维护，即使版本有问题也可以 快速协调资源立即止损 稳定性 功能上只要生产消费，不需要事务消息、Exactly Once等高级功能 可靠性 系统自动化程度高，容忍极端情况下少量数据丢失 可维护性 。。。 …… 5 

6 .InLong-TubeMQ介绍 InLong-TubeMQ架构： 百万亿及以上 Master Master ⅹ 业务更高要求 管控 ⅹ 超大规模下的蝴蝶效应 ✓ 跨BG\公司协作 ZooKeeper ✓ 深耕，打造技术品牌 Producer Consumer Broker Broker …… Broker 客户端 客户端 项目更名为 存储 Apache InLong 十到卅万亿 ⅹ 业务时延要求 万亿到十万亿 ⅹ 集群规模瓶颈 ⅹ 万兆集群下磁盘IO瓶颈 ✓ 内存存储 千亿到万亿规模 ⅹ 聚集度增长后的管理挑战 ✓ 信令协议改造 百亿到千亿规模 ⅹ 访问频度上涨ZK出现不稳定 ✓ 服务器消息过滤 ⅹ 数据重复，丢包 ⅹ 集群规模扩大系统运维工作加重 ✓ 消费者行为管控 TubeMQ 开源 ⅹ 熟悉Scala语言的开发人员少 ✓ 改造消息存储模式 ✓ 解决功能实现Bug ✓ 借鉴思想自研TubeMQ ✓ 增加集群元数据自维护管理 ✓ 增加管理节点，减少ZK依赖 ✓ 增加节点自动化运维管理 ✓ 日志优化 6 

7 .InLong-TubeMQ价值优势 低成本： 1. 机 器 数： 1 : 4~5 1万亿条/天： 50台 vs 200台 2. 磁盘机器： 尽可能的发挥硬件能力 10万亿条/天： 500台 vs 2000台 100万亿条/天： 5000台 vs 20000台 高性能： 1. 高吞吐 10万+ TPS 暂未发现有达到该指标的MQ： 2. 10- ms 磁盘单机，1000个Topic，每个Topic 10个 分区，每个Topic一份生产2份消费，单条 高稳定： 消息1K字节 1. 运维人力：0.5 人力 性能测试方案：https://inlong.apache.org/zh-CN/docs/modules/tubemq/tubemq_perf_test_vs_Kafka 7 

8 .TubeMQ横向对比 TubeMQ适用于 需要高性能的数据吞吐，允许偶发情况下（硬盘故障等）少量数据丢失的业务场景 比较项 TubeMQ Kafka Pulsar 数据时延 非常低，10ms 比较低，250ms 非常低，10ms TPS 高，14W+/s 一般，10W+/s 高，14W+/s (不稳定) 过滤消费 支持服务端过滤和客户端过滤 客户端过滤 客户端过滤 数据副本 无多机副本 多机多副本，异步备份 多机多副本，同步备份 数据可靠性 一般（单机RAID10磁盘存储） 一般（主备切换存在未同步数据丢失风险）高 高，已线上运营近10年，每天过85万亿的数据量，已 一般，性能随Topic数增多出现不稳定情 一般，高压下存在性能下降、服务受阻 系统稳定性 做到单集群1000台Broker的线上运营规模，运维人 况，无法构建单质的大集群 等异常情况，以及元数据问题 力0.5人 一般，基于zk配置管理，API或页面操 配置可管理性 高，热备存储，中心化管理，API或页面操作 一般，基于zk配置管理，API或页面操作 作 多语言SDK 支持3种语言的SDK，Java、C++、Python 官网只提供了Java语言SDK 支持7种语言的SDK CAP模型 AP AP or CP CP or AP 8 

9 .InLong-TubeMQ优化 — 存储(1) Topic 1 Topic m partition 1 文件 index data partition 1 文件 index data partition 2 文件 index data partition 2 文件 index data …… …… partition n 文件 index data partition n 文件 index data Kafka Topic 1 Topic m partition 1 文件 index partition 1 文件 index partition 2 文件 index partition 2 文件 index …… …… partition n 文件 index partition n 文件 index data 文件 data RocketMQ Topic 1 Topic m partition 1 文件 index partition 1 文件 index partition 2 文件 index partition 2 文件 index …… …… partition n 文件 index partition n 文件 index data 文件 data data 文件 data JMQ 9 

10 .InLong-TubeMQ优化 — 存储(2) 问题： ⚫ 硬件差异  线上存在不同配置的机器：大内存，磁盘机，SSD机器等  磁盘随机写能力比较差，总写文件数超过1000个性能急剧下降  存储介质无征兆地坏掉 ⚫ 不同的数据特点  量级差异：有些业务一秒内有几十万的数据上报，有些1分钟1条消息  处理时长：有些业务数据处理非常快，有些则很慢达到秒级  消费份数：部分业务只有1份、2份，部分有10多份  时耗：尽可能短的管道留存时长  服务端过滤：业务只需要总量中1/10，甚至1/100占比的特定数据 方案： ⚫ 基于存储块（内存+文件）的存储结构 ⚫ 服务器端根据指定key过滤 ⚫ 基于存储块及节点的状态监测 效果： ⚫ 满载情况下，单节点最大1000个Topic，分区数不限 ⚫ TS60机型下，1K包大小，1入2出负载下，TPS 14W+ ⚫ 端到端时延 10ms以内 ⚫ 支持按不同机型配置调整存储路径 性能测试方案： https://inlong.apache.org/zh-CN/docs/modules/tubemq/tubemq_perf_test_vs_Kafka ⚫ 支持按照Topic实时动态扩缩容，包括存储实例及分区数 10 

11 .InLong-TubeMQ优化 — 元数据 问题： 元数据定义 Topic broker meta-data status ⚫ Master出流量增长迅猛 test1 broker1 {“partnum”:1} pub:on sub:on 300台Broker过 笛卡尔乘积 -- 客户端数 * 订阅的Topic数 * 单Topic元数据大小 pub:on test2 broker2 {“partnum”:1} sub:on 1G的出流量 …… …… …… …… * 部署的Broker数 Master 方案： ⚫ 元数据冷热分离 Client Client  基于版本ID及数字化压缩冷数据，基于变化的更新 Client Client Client  热的状态数据周期同步 ⚫ 进程内的所有客户端共享冷数据 效果： 静态数据 压缩，版本ID ⚫ 同比优化前，入流量下降到200M左右 元数据 ⚫ 当前最大集群规模可扩展到1000台Broker，约 实时状态 900M出流量 TubeMQ方案 11 

12 .InLong-TubeMQ优化 — 自动屏蔽 问题： ⚫ 硬件故障突发性及不确定性  磁盘读或写异常  网卡降速  CPU、内存异常  非显性的异常 方案： ⚫ 服务端状态检测  基于存储块的IO异常检测及自动屏蔽触发 ⚫ 客户端检测  基于连接异常的检测及屏蔽  基于上报质量的统计检测（Producer） 效果： ⚫ 集群自动屏蔽故障节点：  生产端自动评估并切换上报节点  Broker主动拒绝异常Topic的数据服务  Master按照配置策略自动屏蔽Broker节点的服务状态 ⚫ 运维只需根据屏蔽告警信息做日常巡检 12 

13 .InLong-TubeMQ改进思路 — 跨集群(1) 问题： ⚫ 数据冷热不均 ⚫ 单节点或单集群资源有限 Consumer 1-1 Topic 1 Consumer 方案： b1-t1 b1-t2 b1-t3 b1-tn 1-2 Group-1 ⚫ 基于Bid，Tid构建上报及消费维度 Topic 2 b2-t1 b2-t2 b2-t3 b2-tn ⚫ 基于Topic聚合及跨Topic、跨集群上报及消费 b3-t1 b3-t3 …… Consumer 2-1 Topic x Consumer 状态： …… b3-t2 b3-tn b1t1 b1t2 b1t3 b1tn 2-2 Topic m Group-2 ⚫ 改进中 b2t1 b2t2 b2t3 b2tn Bid,Tid 与 Topic b4-t1 …… b4-t2 映射关系 b3t1 b3t2 b3t3 b3tn Cluster1 Consumer bmt1 bmt2 bmt3 bmtn 3-1 Topic n bid + tid Consumer b4-t3 b4-tn …… 3-2 Cluster2 Group-3 数据上报流 数据路由 数据存储 数据消费 13 

14 .InLong-TubeMQ改进思路 — 跨集群(2) 进展： ⚫ 正在构建Tube-Manager ⚫ 进行客户端改造，支持按照bid，tid 进行消费 Manager Manager (active) (inactive) ⚫ 进行存储改造，支持bid级别的过滤 Manager A W A W A W P E P E P E I B I B I B Producer P P P o o o r r r Consumer t t t a a a l l l M M M a a a s s s M M M t t t ast ast ast e e e er( er( er( r r r m) m) m) ( ( ( s s s ) ) ) C C C o o o n n n t t t r r r o o o z z z l l l k k k Br Br Br Br Br Br Br Br Br ok ok ok ok ok ok ok ok ok er er … er er er … er er er … er … … … S S S t t t o o o r r r e e e Tube-1 Tube-2 Tube-n Consumer Producer Client Tube Group Client 心跳流 数据流 14 

15 .THANKS Email：gosonzhang@apache.org https://inlong.apache.org Apache InLong 公众号 Apache InLong 交流群 15