关于前端:VOP-消息仓库演进之路如何设计一个亿级企业消息平台

作者：京东批发 李孟冬

VOP 作为京东企业业务对外的 API 对接洽购供应链解决方案平台，始终致力于从企业洽购数字化畛域登程，施展京东数智化供应链能力，通过产业链上下游耦合与链接，无效助力企业客户的老本优化与资产效力晋升。本文将介绍 VOP 如何通过亿级音讯仓库零碎来保障上千家企业 KA 客户与京东的数据交互。

本文共有 5,088 字

如果感觉页面很长

那是因为代码截图和留言很多，哈哈

引言

音讯（仓库）作为电商业务场景必不可少的外围性能，自 VOP 上线以来，就开始了建设和演进迭代之路。截止目前，VOP 音讯仓库已接入 200+ 内部消息端，对外提供 80+ 音讯，服务 3000+ 企业客户，笼罩商品、地址、发票、订单、售后、物流等 VOP 所有业务场景。

音讯零碎中，个别有两种生产模式：服务端推送和客户端拉取。本文除了对于音讯仓库的技术架构演进做对应叙述，重点介绍以后 客户端拉取的音讯仓库 建设实践经验。

客户调用场景

以商品音讯为例，京东企业业务目前大概有 5600W+ 商品，这些商品波及根本信息、价格、库存等的变更，客户侧会通过音讯 API 被动获取商品变更音讯，并通过查问实时商品信息接口来获取对应信息，同步本地商品库，业务处理完毕后，删除这一批商品类音讯，定时循环。其余类音讯同理，不多加形容。

音讯仓库 V1.0

和咱们所理解的零碎一样，随着业务倒退和企业客户规模的增多，音讯仓库整体架构和底层存储系统都逐步呈现瓶颈。特地在于数据库方面，毕竟在高并发读写的场景下很大一部分工作是围绕数据库开展的，所以后期两次的降级迭代次要须要解决的问题也是如何晋升数据库容量。

尽管最后咱们也通过读写拆散等伎俩来无效升高数据库的负载，晋升零碎容量和稳定性，然而其毛病也是极其显著：主从提早、从库数据量无限、TPS 高 等问题无奈妥善解决。

并且，随着 618、1111 等各种流动的发展，且 VOP 侧客户的一直减少，音讯激增成为咱们不得不尽快面对的问题，限流、缓存等伎俩随能保证系统的高可用及并发能力。然而音讯大量积压、消费水平无限、音讯同步不及时等问题越发重大，随之带来的就是对业务有损，所以咱们在评估后，对系统进行降级，通过剖析最掣肘咱们的 外围起因还是在于数据库。（此时音讯表行数亿行，容量超过 10G）

音讯仓库 V2.0

因而在读写拆散无奈不能满足咱们的业务须要时（已经验过数据归档），分库分表的模式也就须要登上舞台了。具体如何分库分表，注意事项等我就不多加赘述了，感兴趣举荐翻阅菜鸟积分零碎的分库分表实际 https://mp.weixin.qq.com/s/uF…

分库新旧流程比照

分库新旧流程比对切换根据（供参考）

1. 依据 ducc 和 clientId 决定是否写入到新库，ducc（bizMsgTransDbJson）中配置了切换开关、白名单、黑名单和分流范畴
2. 应用新库写入时，依据 clientId.hashCode % dbSource.size，得出应用哪个 dbSource
3. 客户读取时，先从旧库查出，若无数据，则再读取一遍新库，dbSource 选取形式同上
4. 客户删除时，判断删除 ID 是否大于一万亿（1000000000000），大于取新库，小于取旧库

因为是多 master 的架构，分库分表除了蕴含读写拆散模式的所有长处外，还能够解决读写拆散架构中无奈解决的 TPS 过高的问题，同时分库分表实践上是能够有限横向扩大的，也解决了读写拆散架构下从库数量无限的问题。

当然在理论的工程实际中个别须要提前预估好容量，因为数据库是有状态的，如果发现容量有余再扩容是十分麻烦的，应该尽量避免。

在分库分表的模式下能够通过不启用查问从库的形式来防止主从提早的问题，也就是说读写都在主库，因为在分库后，每个 master 上的流量只占总流量的 1/N，大部分状况下能扛住业务的流量，从库只作为 master 的备份，在主库宕机时执行主从切换顶替 master 提供服务应用。

优化后的后期状况是美妙的，无论从客户角度还是从外部消费水平都失去了大幅晋升，其跳点和峰值音讯下高 TPS 影响 CPU 等问题都失去了解决，整个音讯仓库性能和稳定性趋于稳定。

为什么说后期状况好，置信大家都有所意料了，尽管分库大幅晋升了零碎整体的吞吐能力和稳定性，然而因为后期的容量评估问题（业务增长加剧）及自身现有架构的局限性（单体利用），在仓库稳固运行一年左右，又呈现了一些不言而喻的痛点问题：

痛点问题

1. 海量数据：19 年客户量及商品品类（商品量级）的大幅减少，及最后分库时晋升了音讯数据的存储时长由 2 - 3 天晋升至 7 天（起因：考量政府、银行等客户重保期间不生产音讯的空档期，然而前期验证空档期长达月维度），音讯仓库的流量呈现了频繁翻倍的增长，数据不平衡的状况也逐步显现出来；
2. 字段扩大：随着业务一直的演进，音讯内容也逐步简单（如售后音讯 会附带各环节信息，整个 JSON 音讯体较大），入库或存在字段长度限度，调整字段较难；
3. 高可用 & 扩展性：原有单体架构的状况，会有热点数据的冲击及热点商品类音讯数据对订单类、对账类音讯数据的写入和同步带来重大的时延问题及服务性能跳点问题。
4. 运维老本高：因为面向宽广开发者，因而零碎必须兼顾各种各样的网络环境问题，开发者能力问题等。企业对接客户经常来征询音讯量及音讯生产状况，外部无对应的审计数据可供参考。

指标

不破不立，为防止音讯问题长期以来的频繁影响及其他零碎雷同的音讯需要，咱们急需打造一套可复用可扩大的企业音讯核心，在满足业务的同时，还需综合思考可用性、低成本、高吞吐和强扩展性，并且在迁徙过程中保障音讯不失落和客户无感知。

计划剖析

通过多方调研和排查之后，初步选取了 2 种存储计划：Mysql+es 和 MongoDB。

咱们在存储老本、开发运维老本、性能比照三个方面进行评估 Mysql+es 和 MongoDB 的计划。（仅供参考，具体仍需依据本身业务评估）

• 存储老本：MongoDB 存储劣势显著——数据压缩和无冗余存储，相比 Mysql+es 会缩小 50% 以上的总数据容量。
• 开发运维老本：MongoDB 不须要数据同步，缩小开发和运维难度；字段调整方面 Mysql+es 的架构下对于业务附带抖动危险，DDL 相干问题危险高，易出错；MongoDB 开发保护老本，存储架构简略，无数据一致性压力；扩容方面，MongoDB 反对随时动静无脑扩容，根本不存在下限问题，然而 Mysql 的扩容须要保障 hash 统一，迁徙数据灰度等状况，周期长且高概率存在对业务影响。
• 性能比照：通过压测，同样的 4C8G 的机器配置下，MySQL 和 MongoDB 在大数据量下写性能基本一致。MySQL 的读性单分片约 6000QPS 左右，ES 的性能只有 800QPS 左右。而 MongoDB 单分片地读性能在 3 万 QPS 左右，远高于 MySQL 和 ES 的性能。

音讯仓库 V3.0

没有完满的架构，只有刚好的架构，没有满足所有的架构，只有满足指标的架构

综上剖析，MongoDB 不仅齐全满足业务需要，同时在其余方面也优于其余计划，因而 最终选用 MongoDB 分片集群作为了最底层的数据存储形式 ，并对 零碎架构从新梳理 ，分为 四个阶段：音讯接管阶段，音讯直达阶段，音讯写入阶段，音讯可视化阶段，主要职责如下：

• 音讯接管阶段（vop-worker）：该零碎仅关注不同音讯源的接入，以后已接入中台近百个音讯源，且依赖 BTE 工作平台、订单 & 商品池 & 主数据 & 音讯核心等服务，通过过滤，荡涤，封装等伎俩封装需入库的业务音讯数据直达收回。
• 音讯直达阶段（JMQ 集群）：将音讯直达进去，分级管控，以后分为四级，以此解决外围音讯生产不及时，局部时段 CPU 内存飙升的问题。分级别设置生产线程数，低级别音讯不影响高级别音讯生产。低级别音讯具备降级能力。
• 音讯写入阶段（vop-msg-store）：音讯写入阶段，批量双写，MongoDB+ES（反对多维度的运维审计查问及数据导出）。MongoDB 解决 tps10000+、数据量日均 5 亿 +、多查问条件和数据分布不平均的问题，解决数据库无奈撑持租户数据平均和音讯内容可扩大的问题；创立 mongo 表，设置租户 id 和事件 id 索引、设置租户 id 的分片规定、设置惟一索引和超时工夫 45 天。ES 解决音讯运维过程中，审计、核查等问题。
• 音讯可视化阶段（vop-support-platform）：解决对客户生产 / 生产能力无认知、全局音讯不可控和音讯可视化的问题。并且数据可视化的不断完善又会反哺架构的可用性晋升，为后续咱们设立的优化专题打下松软的数据根底。

补充：MongoDB 分片集群无单点故障的起因——当 MongoDB 被部署为一个分片集群时，应用程序通过驱动，拜访路由节点，也就是 Mongos 节点 Mongos 节点会依据读写操作中的片键值，把读写操作散发的特定的分片执行，而后把分片的执行后果合并，返回给应用程序。那集群中的数据是如何散布的呢? 这些元数据记录在 Config Server 中，这也是一个高可用的复制集。每个分片治理集群中整体数据的一部分，也是一个高可用复制集。此外，路由节点，也就是 Mongos 节点在生产环境通常部署多个。这样，整个分片集群没有任何单点故障。

音讯仓库 V3.0 给咱们带来的成绩也是非常显著，高标准达到了预期的指标：

• 撑持日均音讯写入量 5 亿，现反对 6wTPS 和 1wQPS
• TP99 从 100ms 晋升至 40ms，在高吞吐量状况下性能体现安稳
• 新架构边界清晰，新需要不波及外围零碎的革新
• 数据有效期 7 天晋升至 45 天
• It 老本 0 增长
• 音讯可视化方面大幅晋升运维效率，已全面凋谢技术客服应用

音讯仓库 V3.0+（回首往事）

之前咱们始终铆足劲的往前追赶，当初零碎稳固，为实现将来客户和商品的增量对音讯仓库无影响 &稳固运行 3 年 +的指标，咱们决定在 限度资源有限性 的状况下，转换角度思考问题和优化指标。随即咱们针对音讯数据发展了几个专题的治理，外围围绕 流量治理、零碎稳定性建设、降低成本 三个方面登程。

锁定目标定后, 剩下的只是迈步朝它缓缓走上来。

流量治理（峰值状况下裁剪亿级音讯量）

1）优化业务场景，从源头缩小调用量，梳理零碎流程，优化有效数据源的接入，历史空跑逻辑等。
2）a、有效客户管控（LoadingCache），因为其余端外界客户接入 VOP，存在局部不生产音讯的有效客户，需进行被动屏蔽，以此解决有效客户音讯直达存储的问题。b、缓存，缩小耗时操作等等。
3）音讯过滤器（jimdb），通过 防重管制 + 工夫窗口 对客户未生产且反复 sku 进行去重，以此解决客户音讯生产提早，客户音讯量大，反复音讯多，客户零碎重启后音讯量微小的问题，并大幅缩小我侧 MongoDB 存储数据量。

这里补充一个小插曲，在流量治理过程中，咱们也在数据中发现了一些问题，并作为领导咱们产品优化的数据撑持，通过技术手段进行优化和解决。** 如：通过数据分析，咱们在整个生产过程中，局部客户（如：联通）生产较慢或者有效生产导致信息同步不及时的问题，因而从技术角度登程与客户技术侧沟通，通过建设主动补推性能，来晋升客户与京东的同步率，即通过自助补推性能，来辅助客户同步异常情况下二次同步，以价格变更为例，通过客户下单价格不统一，来自助补推价格变更音讯，以此挽回因为客户同步异样导致异样的订单，晋升客户成单率，进一步晋升整体 GMV 产出。

这里也给我带来思考，无论引入还是自研，无论架构还是工具，落到实处，实在解决业务中的问题，在降本增效中带来价值，不管大小，均为翻新。

零碎稳定性（解决 cpu 毛刺及分片热点问题）

1）进步资源利用率 ：优化局部代码构造，如：通过 list.contains() 转化为 set.contains()将其工夫复杂度由 O（n）降至 O（1）、比拟耗时或者不用放在主流程中执行的工作异步解决、单个写转化为批量写、缩小传统重量级锁应用操作系统互斥量带来的性能损耗等等，以此解决大流量下，机器 cpu 飙升影响整体性能的状况。

2）a、被动降级队列 ：后面有提到 MongoDB 设置租户 id 的分片规定，所以在单客户频繁进行大量商品池操作时，会收回该客户的大量商品出入池音讯，因为以后整个零碎吞吐性能极佳，所以在写入 MongoDB 时，会造成单分片的热点写问题，所以设定被动降级队列。 具体实现为 在音讯仓库多租户场景下，不影响整体客户的状况下，配置化（某客户 + 配置详音讯类型）的进行异样客户的过载流量隔离，来保障底层存储介质的服务质量，即异样流量超过阈值则进入降级队列。  b、JMQ 生产线程调优 等

降低成本（非流动期间，白天音讯量级绝对早晨较少）

serverless 主动扩缩：采纳秒级音讯接管量阈值和机器 CPU 阈值来触发主动扩缩策略，通过调优后非大促期间音讯仓库整体资源老本降落52%。

小结

目前的音讯仓库从正式退役到通过一直的迭代和更新已踏入 V3.0+ 版本，胜利经验了四次大促，零碎各项性能指标稳固。以最近的大促为例，22 年双十一开门红，音讯相干接口性能稳固，MongoDB 整体写入 QPS 2w，查问 QPS 4.3w。  并且通过评估能齐全应答接下来独立场切换带来的音讯增长状况。

在音讯仓库整体架构演进降级的过程中，尽管根底中间件给咱们提供了各种高可用的能力，但可用性最终还是要回归咱们业务架构自身。业务零碎须要依据各平台业务个性尽可能抉择最优的可用性计划，并在零碎架构中遵循一些准则，如最大限度缩小要害依赖；打消扩容瓶颈；预防和缓解流量峰值；过载时做好优雅降级等等。而且 更重要的一点是，咱们须要时刻思考架构如何撑持业务的长期增长。

后续有工夫也能够给大家同步一下咱们另一个 数据推送平台。（一键三连催更）

瞻望

1. 放弃工匠精力，精益求精：在保证系统稳定性和扩展性的同时，以业务为重点，继续践行数据驱动的实际办法，进一步晋升客户和 VOP 单方零碎的各类音讯同步率，通过技术手段一直优化产品，晋升客户搜寻体验及下单成功率。
2. 音讯数据治理：无论音讯推送还是音讯拉取方面都有一个极其显著的特色，在客户零碎消费水平足够好的状况下，大部分数据是会在几秒内进行写删各一次，两次操作实现这条数据就失去了意义。（以前天为例，有 3000W+ 音讯数据生产生产简直同速率）在这种场景，应用任何存储介质自身就不合理，就像是在存储介质中插入一条简直不会去读的数据。这样生命周期极短的数据放在存储介质中，不仅资源节约，也造成存储介质成为零碎将来的瓶颈。思考服务器自身的老本问题，能够针对降级过滤器或者参考计算机三级存储体系结构的思路，将来将大量的此类音讯事务在 Memory 内实现，其余音讯依照原有形式进行操作，该形式下千万级音讯事务在 Memory 内实现，节俭大量服务器资源。
3. 推送形式标准化：轮询状态下，数据的实时性究竟依赖于客户利用的轮询间隔时间，该形式下，API 调用效率低且节约机器资源，如何联合业务侧推动数据推送标准化，给客户提供实时牢靠的双向数据交换通道，大大晋升 API 调用效率也是咱们后续着重思考的方向。

• • *

本次就写到这，零零散散，很多细节点（如：如何线程调优晋升吞如，大流量音讯下的数据埋点及剖析等等）无奈齐全描述，如有问题，欢送交换。心愿文章中的音讯仓库的演进教训，给大家带来一些播种，或者说，大家无妨思考一下你们会采纳何种技术计划和伎俩来解决演进中遇到的问题。欢送留言交换，也心愿能和更多气味相投的搭档沟通交流。

最初老样子，欢送大家一键三连点赞珍藏 + 关注。