Work for YILI

Appearance

2026-06-12 工作日志 ​

项目早会 ​

本次会议同步了各项目进展，讨论了数据问题、SFA、APM 等模块的优化方案，并重点沟通了协同发版的节奏与文档调整。

小结 ​

1. 数据与主数据相关问题

  • 数据为空问题：因高德地图解析包存在 300 万次调用上限，导致部分数据为空。目前已重试处理，后续将关注监控。
  • 主数据 1 小时延迟：原计划采用的兜底方案将由前端传递字段解决，主数据侧不再开发。
  • 门店数据清洗：为统一处理约 500 万家门店的数据，将由各端系统共同参与清洗工作。
  • SFA 登录性能：登录注册相关接口的平均响应时间已从之前的 4-5 秒降至 1 秒多，性能有所提升。

2. SFA 与 APM 项目进展

  • SFA 项目：登录注册模块预计在本周六上线，整体版本计划维持 7 月底上线。
  • APM 项目：本周将对齐全量接口的优化项和生产计划，下周将输出架构优化项和省电计划。

3. 协同发版与文档调整

  • 发版节奏：为保障主数据系统的稳定性，将推行协同发版机制，要求各业务系统提前规划并同步依赖项。
  • 文档调整：为方便各端负责人查看，将调整月度发版汇总文档，使其更清晰地呈现各版本的发布日期、依赖关系和协同信息。

4. 剩余问题跟进

  • SFA 重复数据：因 SSR 写入延迟可能导致少量重复盘点数据，将作为专项问题进行排查。
  • 环境照片功能：将确认图片存储的权限问题，并推进手动录入环境照片功能的开发。

待办 ​

1. 数据与主数据相关

  • 刘晓娜 补充因高德地图解析问题导致的数据为空项。
  • 邢健、刘晓娜 评估电子围栏门店 SKU 数据对活动中心的价值，并纳入后续开发范围。
  • 李亚洲 组织各端（小智、智慧门店、云商等）进行门店数据统一清洗的沟通。
  • 李宝仟、建利哥 组织对 SFA 重复数据问题的专项排查。

2. SFA 与 APM 项目

  • 刘晓娜 更新因测试风险可能导致延期的"营销活动中心活动模块升级"的发版计划。
  • 李亚洲 调整月度发版汇总文档，使其更清晰地呈现各版本的发布日期、依赖关系和协同信息。

3. 协同发版

  • 邢健 牵头协调各端系统的发版排期，确保主数据系统的稳定性。

积分商城支持多事业部讨论会 ​

本次会议主要围绕积分商城支持多事业部展开，讨论了其技术架构、资源投入及后续开发计划。

小结 ​

1. 积分商城项目背景与目标

  • 积分商城（原名"积分乐园"）是营销活动中心下的一个通用工具，旨在支持各事业部的积分发放与兑换。
  • 当前版本仅支持"椰奶"事业部，但"酸奶"、"成人营养品"等事业部已提出需求，需支持多事业部的数据隔离。
  • 本次改造的目标是在重构后的独立系统基础上，增加多事业部的数据权限隔离功能。

2. 技术架构与资源情况

  • 积分商城将从原"小拓"项目中剥离，作为一个独立的、全新的项目进行开发，拥有独立的代码仓库、数据库和部署流水线。
  • 目前存在资源不足的问题，特别是测试资源。开发人员（任同超）已到位，但测试资源尚未明确，可能会影响项目进度。

3. 开发与测试流程

  • 开发工作可以先行启动，但必须确保测试资源能够同步到位，以保障项目质量和按时上线。
  • 测试工作需由熟悉技术方案的专业人员进行，而非仅做功能层面的黑盒测试。

待办 ​

1. 整体架构与流程梳理

  • 余建新 需要梳理并输出积分商城的整体技术架构图，明确其在营销域中的位置及与其他系统的业务关系。
  • 余建新 争取在下周组织一次项目组会议，对齐整体架构并讨论资源分配。

2. 测试资源协调

  • 余建新 需要尽快协调并安排测试资源，确保开发工作可以顺利进行。

3. 测试任务交接

  • 余建新 需要与刘莉沟通，将她手头的测试任务交接给新的项目，以便她能投入到积分商城的测试工作中。

网关异常修复与核销幂等性研讨（技术方案评审） ​

发言人：粱健、王建朝、潘玉平、贾继伟、余建新等 7 人

本次会议针对网关连接超时与核销接口幂等性问题进行了技术方案评审，明确了网关配置优化与代码热处理的修复路径，并对核销幂等性改造的必要性进行了深入探讨，同时评审通过了中奖明细表数据补偿机制。

小结 ​

1. 网关连接超时与异常修复方案

  • 核心问题根因分析：
    • 连接池复用过期连接：网关发出请求后，后端无响应或字节流关闭，导致连接池复用了已关闭的过期连接。
    • 后端进程异常或超时：后端进程在传输过程中崩溃或被强制杀死，导致网关连接被重置。
    • 配置失效：Spring Boot Gateway 使用 Netty 连接池，原有的 Tomcat 配置（如连接超时时间）不生效，导致连接空闲时间过长未被回收。
  • 修复方案与验证策略：
    • 配置参数调整：在网关侧增加连接池配置，包括最大连接数、最大空闲时间及单条连接最长存活时间，并移除无效的 Tomcat 配置。
    • 代码级补充方案：在拦截器 Filter 中加入代码热处理的逻辑，将 Body 内容缓存至数组，避免并发场景下重复读取导致的"非法引用计数异常"。
    • 验证流程：决定先在测试环境验证配置调整效果，若问题未彻底解决再补充代码修改方案，严禁直接在生产环境进行尝试性调参。

2. 核销接口幂等性改造评估

  • 业务影响与改造动机：核销表缺乏唯一键约束，且代码中仅通过捕获唯一键异常处理冲突，导致接口重复调用时会插入多条记录。虽然目前该表数据暂未对业务产生实质性影响，但从技术规范角度出发，需解决幂等性问题以保障数据一致性。
  • 控制逻辑与链路梳理：经讨论确认，核销一次的控制逻辑主要在抽奖接口中实现，通过检查码状态（如已售状态）来阻止重复抽奖，而核销接口本身未做控制。需进一步梳理两个核销接口（新老接口）的具体调用方及业务场景，确认幂等性改造应覆盖的链路节点，避免盲目修改。

3. 中奖明细表数据补偿机制

  • 问题场景与方案设计：在出货信息未落库前进行抽奖，导致中奖明细表无法关联到正确的出货信息。补偿机制为创建重试表存储失败记录，通过定时任务（每 5 分钟）拉取待执行数据，重新执行业务逻辑以回补出货信息。
  • 执行策略与风险控制：设定最大重试次数（5 次），防止死循环；若重试超过最大次数仍未成功，则停止重试，避免资源浪费。考虑到数据量较小，暂不进行自动清理；若后期数据量增大，可增加定时任务清理已处理成功或超次数的数据。

待办 ​

1. 网关连接超时修复

  • 潘玉平 在测试环境验证网关配置调整效果，确认无问题后再考虑上线。

2. 核销接口幂等性改造

  • 潘玉平 梳理核销接口的调用方及业务场景，明确幂等性改造的具体影响范围。

3. 数据补偿方案

  • 粱健 补充数据补偿方案的背景说明，详细描述"先出货后抽奖"导致数据丢失的具体场景。
  • 粱健 开发并测试中奖明细表数据补偿功能，完成后上线。