Work for YILI

Appearance

2026-10-23 工作日志 ​

液奶主数据底座改造 + 报表宽表 + 出签退事件表调度方案评审 ​

主题：本次会议评审液奶业务主数据模块的改造方案，旨在统一基础数据底座、解决多套系统数据不一致的问题，并同步评审了基于 Mongo 大宽表的报表链路架构与出签退事件表的定时任务消费调度策略。

小结 ​

一、液奶主数据底座服务改造方案

会议首先评审了液奶业务主数据模块的改造方案，旨在统一基础数据底座，解决多套系统数据不一致的问题。

1. 架构调整与依赖替换

  • 移除旧微服务：计划移除现有的主数据微服务模块（data rpc），统一使用新的基础数据底座服务。
  • 引入 JAR 包组件：新建一个普通 JAR 包组件，通过 Maven 引用，以 HTTP 协议调用底座接口，替代原有的 Dubbo RPC 调用。
  • 释放数据库资源：待所有模块稳定运行一个月后，将下线原有的主数据模块及数据库实例，释放相关资源。

2. 改造范围与上线策略

  • 梳理 19 个业务模块：目前已梳理出 19 个依赖旧主数据模块的液奶业务模块，将按引用体量从小到大依次推进改造。
  • Code 服务作为首个试点：选择 Code 服务作为首个改造试点，因其仅涉及查询且对核心业务出签退流程影响最小，便于验证底座稳定性。
  • 独立分支与回滚机制：所有升级模块需拉取单独分支，若上线后出现问题，可及时回滚至原分支。

3. 接口改造与异常处理

  • 处理参数与签名差异：部分旧 RPC 接口与新 HTTP 接口的参数和本地方法签名可能不一致，需在模块内进行统一的参数转换。
  • 门店数据拆分查询：对于涉及门店与人员联表查询的旧接口，需拆分为两次独立查询（底座与 SDS 服务）后再在业务层拼装数据。
  • 版本控制严格化：JAR 包发布严禁使用 Snapshot 版本，必须采用带版本号的正式版本，以确保多服务共用时的兼容性与稳定性。

二、报表链路与宽表优化方案

会议针对出签退报表链路的性能瓶颈与数据同步问题，探讨了基于 Mongo 大宽表的新架构方案。

1. 报表数据同步策略

  • TP 与 AP 业务解耦：为避免报表导出时的大批量数据查询拖慢核心业务，计划将报表查询与业务主链路隔离。
  • 历史数据回灌 Mongo：上线前需将 StarRocks 中的历史数据回灌至 Mongo 大宽表，以保证在途订单（如先出货后签收）的数据拼接完整。
  • Mongo 大宽表承载实时数据：新方案计划将出、签、退及激励等数据直接组装写入 Mongo 大宽表，减少实时查询基础数据的压力。

2. 数据展示与查询方案

  • T+1 与实时数据组合展示：针对报表查询，计划组合 Mongo（实时数据）与 StarRocks（T-1 历史数据）两个数据源，在应用层进行分页与汇总。
  • 评估 Mongo 导出性能：针对 Mongo 大范围数据导出可能存在的性能瓶颈，需进一步评估其承载最近几小时（如 2-4 小时）数据导出的能力。

三、出签退事件表消费调度方案

针对新引入的事件表，会议详细评审了定时任务的调度策略与并发处理机制。

1. 调度机制与重试策略

  • 基于 XXL-JOB 的分布式调度：采用 XXL-JOB 进行定时调度，通过分布式锁确保同一时间只有一个执行器处理任务，避免重复消费。
  • 失败订单自动重试：拉取待处理及重试次数小于 3 的失败订单，若连续重试 3 次仍失败，则触发告警并交由人工介入处理。
  • 历史数据迁移保障：上线时需将 StarRocks 中的在途数据回灌至 Mongo 大宽表，确保事件表消费时能正确关联并拼接历史出货数据。

2. 并发处理与线程控制

  • 按单号分组并行处理：从事件表中拉取订单后，按单号在内存中分组，不同单号的出签数据由多线程并行处理，提升处理效率。
  • 退货数据串行处理：为避免并发冲突，退货数据被单独提取并在出签处理完成后串行执行，确保首次处理不会因数据未就绪而失败。
  • 单例调度控制资源消耗：调度任务仅在单节点执行，避免多节点同时运行导致的内存资源浪费与成本增加。

3. 异常场景与人工干预

  • 容器崩溃自动切换：若执行调度的 Pod 崩溃，XXL-JOB 会自动随机调度至其他存活的 Pod 执行，保障任务连续性。
  • 数据库宕机人工修复：若发生数据库宕机等极端情况导致全量失败，需人工修改事件表中的重试次数，触发系统重新调度。
  • 人工处理预案补充：需在技术方案中补充超过 3 次重试失败后的具体人工处理流程与介入方案。

四、评审意见与后续计划

1. 方案完善要求

  • 补充直连数据库改造说明：需明确 Receive 服务中直连数据库部分的改造方案，并安排针对核心业务的压测。
  • 细化流程图与异常分支：技术方案需结合流程图，清晰标注循环条件、异常节点及人工干预预案。

2. 资源评估与压测安排

  • 评估服务部署资源：需评估定时任务对 Receive 服务内存的消耗，避免为单节点运行而过度扩容整个集群资源。
  • 制定压测计划：后续需与压测团队沟通，按历史峰值 10 倍的数据量模拟事件表写入，验证调度消费能力。

待办 ​

  1. 在方案中明确 JAR 包的版本控制计划，严禁使用 Snapshot 版本。 — @宋洋
  2. 补充直连数据库部分的改造方案，并安排针对核心业务的压测。 — @张喜
  3. 将 Report 模块的数据同步方案单独拎出，待宽表方案确定后单独编写详细方案。 — @宋洋
  4. 维护改造涉及的接口及接口说明清单，并生成在线表格链接附于方案中。 — @王林
  5. 准备事件表与大宽表的示例数据（Excel），行转列化以演示多线程消费与数据流转逻辑。 — @张喜
  6. 评估定时任务对 Receive 服务内存的消耗，确定代码最终部署的服务位置。 — @张喜 @王建朝
  7. 评估 Mongo 大宽表承载最近 2-4 小时数据导出的性能，验证双数据源组合展示的可行性。 — @张喜 @邱毅
  8. 完善技术方案中的流程图，补充异常分支、循环条件及人工干预预案。 — @张喜
  9. 与余建新确认 Mongo 大宽表所需的具体字段，完成宽表打平工作。 — @张喜
  10. 安排人员开始核心链路的代码开发。 — @张喜
  1. 与 09-11「异步依赖未做前置等待即为缺陷」并读（同根因的正面处理，可作为方法论引用）：09-11 定调「退款时上游拆单有延迟、指定物料在物料域查不到会导致退款失败/数据丢失，须等拆单完成再执行退款逻辑，或做排队延后重试」。本次出签退事件表调度中，「退货数据被单独提取并在出签处理完成后串行执行，确保首次处理不会因数据未就绪而失败」是同一根因（数据未就绪时的首次执行）的正面解法，与该原则同源。影响是：本次的重试机制（3 次重试 + 告警 + 人工改次数）建立在串行兜底之上，若后续新业务复用该事件表而绕过串行约束，3 次重试会从「预防手段」退化为「事后补救」，届时的失败率会直接落在出签退链路上。
  2. 与 09-11「所有问题统一进一张台账」并读（人工介入路径缺台账闭环）：09-11 要求「不能等中台监控或业务反馈驱动修复——806 那次 RPC 问题拖了一个月才想起修，原因是发现了没人认领、没人排期」，并配套要求所有问题统一进台账（发现来源、影响范围、根因、责任人、排期、关联待办编号）。本次方案中「数据库宕机等极端情况导致全量失败，需人工修改事件表中的重试次数，触发系统重新调度」把人工改库作为常规恢复路径，且「连续重试 3 次失败后交由人工介入」的具体流程本次仍是待补项。影响是：这条路径缺少认领人与排期字段，人工改次数的触发、处置、结案均无留痕，机制上仍存在「发现了没人认领」的风险。落地时须同步建台账而非只在文档里写预案。
  3. 与 10-10「生产变更敬畏」红线并读（SR 历史数据操作方式待明确）：10-10 复盘确立了「SR 表数据修饰一律禁用 SQL 直改，统一由 Java 程序 + Stream Load 分批更新脚本执行」以及「DDL 前全量备份并验证恢复流程」。本次需在上线前将 StarRocks 中的历史与在途数据回灌至 Mongo 大宽表，两处回灌（报表历史回灌、事件表在途回灌）均是批量读 SR 写 Mongo 的搬运，虽非数据修饰，但读侧同样受分区裁剪与执行速率约束。影响是：方案评审材料里的回灌 SQL 须带分区键与时间范围下限并控制速率，否则「上线前一次性全量回灌」极易在 SR 上打出慢查询影响主链路——与 10-10 认定的「测试环境难复现生产数据量」是同一风险面。