2026-05-21 工作日志
项目进度同步会
本次会议同步了各模块进展，重点讨论了产品走查、前端优化、健康度监控及多项问题的排查与排期。
小结
1. 产品与功能进展
- 营销活动中心的产品走查和优化改善项目按计划推进，部分功能预计在6月4日和6月11日上线。
- 前端提示功能已按计划上线。
- "扫码机盘点"功能的上线时间已调整至7月23日。
2. 健康度与问题排查
- 健康度日常运营：当前"产品功能走查"共104个问题，已完成24个的配置，剩余问题将进行分析。
- 问题排查：会议明确了多项需紧急排查和解决的问题，包括：
- 查证表中经销商为空及5段为空的bug。
- 消费者中奖明细表相关的4个问题。
- 数据监控中的"double数"问题、"货权为空"问题、"调拨后留下未更新"等问题。
3. 其他事项
- 各端将进行上午11点的串流会议，以同步进展。
待办
1. 问题排查与跟进
- 针对查证表中经销商为空及5段为空的问题，需给出排查排期。@张喜
- 需优先解决消费者中奖明细表相关的第2、3、5号问题。@马奇
- 需跟进并提供"扫码机盘点"功能的各端评审排期。@任铭 @王琪
2. 串流会议安排
- 安排上午11点的串流会议，以便各端同步进展。@刘晓娜
签收码接口性能压测报告评审
本次会议评审了签收码接口的性能压测报告，分析了TPS波动及CPU/内存使用率高的问题，并明确了后续的优化方向。
小结
1. 签收码接口性能压测分析
- TPS波动问题：距离查询接口的TPS存在显著的波峰（峰值超3000）与波谷（低至数百），非预期的线性增长。经分析，根本原因为压测时采用的并发策略与缓存机制共同作用所致：压测脚本中的数据集在多线程并发下，部分请求因数据首次访问而命中数据库，后续请求则命中Redis缓存，导致TPS出现大幅波动。
- 资源使用情况：压测过程中，CPU和内存使用率均高于80%，与生产环境配置不一致，这可能是导致TPS表现异常的因素之一。
- 接口响应时间：经确认，该接口为纯校验接口，响应时间表现优秀，99%的请求在500毫秒以内，符合会议确定的验收标准。
2. 压测结论与后续建议
- 压测结论：在当前配置下，接口的TPS（约1200）远高于预估的理论值（约4-5），性能表现良好，能满足业务需求。
- 长远建议：为应对未来业务量增长，可考虑引入Redis缓存层等优化策略来进一步提升接口TPS。
待办
1. 优化压测方案与资源配置
- 升级MySQL资源配置，使其与生产环境对齐。@张喜
- 在MySQL资源配置升级后，移除接口中的Redis缓存逻辑，重新进行压测，以验证并消除TPS波动问题。@张喜
2. 更新压测报告与标准
- 在压测报告中补充CPU和内存使用率超80%的原因说明。@吕杰
- 更新压测报告中的性能标准，将响应时间的验收指标从"90%请求低于200ms"修改为"90%请求低于500ms"。@吕杰
3. 明确后续压测基准
- 基于业务量预估，提供一个用于后续压测的TPS计算公式或基准值，以便于评估系统承载能力。@郑然然
数据修复方案讨论
本次会议主要讨论了数据修复方案，重点针对手机号和经纬度的修复方法、技术细节及后续执行计划。
小结
1. 数据修复方案
- 手机号修复：通过脚本将加密的手机号信息解密后，更新至B端出货明细表中。此过程将使用临时表进行数据比对和验证。
- 经纬度修复：由于数据传输和存储中存在double类型精度丢失的风险，计划通过脚本从MongoDB中查询正确的经纬度信息，并更新至B端出货明细表。
2. 技术实现与优化讨论
- 数据源优化：为提升修复脚本的运行效率，建议将原始的大数据集导出并创建为一张独立的新表作为数据源，避免在庞大的主表上进行全量查询。
- 数据落库：修复后的数据将直接追加到指定的B端出货明细表中，并建议在该表中增加"场景"字段以区分不同批次的修复数据。
待办
1. 数据修复脚本优化与执行
- 将修复所需的数据源从原表导出并创建为一张新表，以优化后续脚本的运行效率。@梁健
- 在修复脚本中，将数据源切换为上述新建的独立数据表。@梁健
2. 数据修复与归档
- 执行手机号和经纬度的修复脚本，完成数据修正。@梁健
- 将修复后的数据追加到指定的B端出货明细表中，并在备注字段中详细记录本次修复的场景和内容。@梁健