Work for YILI

Appearance

2026-05-27 工作日志 ​

项目进度同步会 ​

本次会议同步了各项目及模块的进度，讨论了UI改版、性能优化、SFA接入及遗留问题，并明确了后续的调整方向和待办事项。

小结 ​

1. UI/UX及前端相关

  • 前端产品走查因UI改版涉及首页、门店及新增经销商星级页面的改动，将推迟至6月25日版本发布。
  • 提示语优化将进行内部UAT验收后上线，无需额外业务评审。
  • 签收链路优化的UI已对齐，待开发。

2. 性能及功能优化

  • 门店首页及部分页面的性能优化将纳入5月30日版本，以解决耗时长及错误率高的问题。
  • 扫码拍照性能优化虽有提升，但仍慢于智慧门店，需进一步对齐测试口径。
  • SFA神策接入埋点将基于测试环境数据分析，初步制定解决方案。

3. SFA及数据相关

  • 宁夏工厂供应方案将在今日完成评审，后续将按排期进行优化。
  • 智慧门店存在数据差异，需缩小范围后进行业务影响性评估。
  • TTS产品走查的性能测试预计今日完成第一轮，若发现问题则次日再次测试。

4. 遗留问题及风险

  • 经销商编码问题：因存在大小写兼容性问题，导致后续人员关系及门店归属的开发工作受阻，需技术侧提供方案。
  • 数据及报表问题：
    • 盘点明细表中，因财务失效导致异常流出经销商名称不显示，需进一步沟通处理。
    • 3月份数据迁移遗留的脏数据导致产品明细表数据不一致，需进行数据修复。
    • 新发现数据存在重复记录的问题。

待办 ​

1. UI/UX及前端相关

  • 提示语优化工作量从6月11日版本调整至6月25日版本，需李赵丹与李亚洲沟通确认。@李赵丹 @李亚洲

2. 性能及功能优化

  • SFA神策接入埋点，需李赵丹根据测试环境数据分析，初步制定解决方案。@李赵丹
  • 扫码效率提升专项，需陈思和任铭在群里对齐测试口径。@陈思 @任铭

3. SFA及数据相关

  • 宁夏工厂供应方案评审完成后，需启动相应优化调整。@李超
  • 需邢健、陈思及张建利对齐"经销商编码"问题，明确其对下游开发的影响。@邢健 @陈思 @张建利
  • "经销商人员"相关开发需邢健、陈思及张建利对齐，明确具体涉及人员范围。@邢健 @陈思 @张建利
  • "代签收"需求，需刘晓娜完成UI调整后的签字确认，以便进入开发。@刘晓娜

4. 遗留问题及风险

  • 盘点明细表因财务失效导致名称不显示的问题，需李宝仟与李亚洲及杨辉确认处理方案。@李宝仟 @李亚洲 @杨辉
  • 3月份数据迁移导致的产品明细表数据不一致问题，需刘晓娜进行数据修复。@刘晓娜
  • 新发现的数据重复记录问题，需刘晓娜在今日跟进处理。@刘晓娜

活动推送计费失败问题讨论 ​

本次会议主要讨论了活动推送计费失败的报错问题，明确了问题原因、临时解决方案以及前端页面的UI缺失问题。

小结 ​

1. 推送计费失败问题

  • 问题现象：活动创建后，若奖品为红包且出资方为品牌，推送计费时会因营销天网编码和密钥缺失而失败。
  • 根本原因：前端虽有强校验，但偶发性地未将营销天网编码和密钥传递至后端，导致数据缺失。
  • 临时解决方案：立即修复已出现问题的数据，包括修改数据库中的奖品记录并更新缓存。

2. 前端UI缺失问题

  • 问题现象：在活动详情页中，当奖品为非品牌出资时，营销天网编码和密钥字段未展示。
  • 根本原因：此为产品设计遗漏，未在UI设计稿中体现。

待办 ​

1. 数据修复与排查

  • 修复当前计费失败的活动数据，包括修改MySQL中的奖品数据和更新Redis缓存。@余勇军
  • 修复数据后，需持续观察日志，排查是否存在其他类似问题的活动。@余勇军
  • 与郑然然对齐，确认此问题是否受卡券功能的影响。

2. UI缺失问题跟进

  • 由产品侧牵头，将"详情页未展示营销天网编码和密钥"的问题补充到PRD文档中，并组织研发和测试进行对齐。@吴南林

盘点数据重复消费故障复盘与修复方案评审 ​

会议主题：盘点数据重复消费故障复盘与修复方案评审

发言人：梁健、王建朝、贾继伟、孙传熙、吕杰等7人

会议摘要：会议复盘了因RPC报错导致盘点数据重复消费的故障，制定了双重去重拦截的技术修复方案，并对历史脏数据的清洗策略及业务管家下线影响进行了评估。

一、故障根因与修复方案 ​

针对客户反馈的"同一码在同一天出现多次盘点记录"问题，团队进行了根因分析并制定了技术修复方案：

1. 故障根因定位

  • RPC报错引发重试逻辑缺陷：原有代码在处理盘点数据时，遇到RPC报错后会跳转到重试方法，导致已处理成功的码被重复消费，从而产生大量重复数据。
  • 事务缺失与数据一致性风险：由于盘点组装数据过程缺乏事务控制，且RPC报错导致消息重复消费，造成数据库中存在大量重复记录。

2. 双重去重拦截机制

  • 消费端去重拦截：在消息消费前，根据"订单+码"组合查询数据库，若已存在记录则移除该码，仅处理未落库的数据，确保即使报错也不会重复处理已成功的数据。
  • 落库端Upsert操作：在RocketMQ消费逻辑中增加拦截，根据Check ID和码进行过滤，若已存在则执行更新操作，不存在才执行插入操作，实现幂等性。

二、历史数据清洗策略 ​

针对已产生的脏数据，团队讨论了清洗方案及业务规则约束：

1. 清洗逻辑与约束

  • 保留单日首条记录：若需清洗数据，计划按天分组并保留创建时间最早的一条记录，删除其余重复数据。
  • 盘点次数不可修复：由于盘点次数存储在MongoDB中且已累加，无法通过清洗数据库记录来修正，若删除中间记录会导致后续盘点次数不连续。

2. 特殊业务场景排除

  • 业务管家下线确认：经确认，允许一天多次盘点的"业务管家"功能已于今年下线，目前无相关数据产生，因此历史数据清洗不受该特殊规则影响。

三、技术方案风险评估 ​

1. 数据一致性保障

  • 消息重试机制验证：确认RocketMQ在服务宕机或未ACK的情况下会重新投递消息，不会导致数据丢失，仅可能因重复消费导致数据冗余。
  • Stream Load延迟风险：针对Stream Load写入延迟可能导致去重失效的担忧，团队确认在"一天一盘"的业务校验下，该极端情况不会发生。

2. 业务逻辑修正

  • 盘点次数累加逻辑调整：纠正了原有在报表中累加次数的错误逻辑，改为在同步接口中直接累加，确保数据来源的准确性。

四、待办事项 ​

  • 确认是否需要对历史脏数据进行清洗，并明确清洗的具体需求。@梁健 @罗宾
  • 编写并发送本次修复方案的测试报告。@马奇