2026-05-28 工作日志
项目进度同步会
本次会议同步了各项目进度，讨论了数据治理、遗留问题及扫码签收优化，并明确了后续的跟进事项。
小结
1. 各项目进度同步
- 活动中心：页面走查和提示语优化将随611版本一同上线。
- 扫码签收优化：因业务流程变更，性能优化效果需待528版本上线后再观察。已确认的COS图片压缩和AI风控参数优化将会上线。
- TCS产品：已完成压测，方案已发出等待确认。
- 数据治理：健康度配置将分批上线，目前已完成3个，剩余6个仍在进行中。
2. 数据治理与遗留问题
- 数据治理：已完成对齐智慧门店的性能探查方式，将为前端性能探测上报日志。同时，正在梳理155个调度任务并分类，以便后续监控。
- 遗留问题：
- 必填项问题：活动中心页面的扫码时间必填项将进行优化，允许只传一个时间即可。
- 数据准确性：已定位到因消息重发导致的重复签收数据问题，正在修复；同时，马松状态签收的准确性也需要进一步排查。
待办
1. 扫码签收优化
- 需与智慧门店团队沟通COS图片压缩和AI风控参数优化对业务的影响。@王琪 @张建利
- 528版本上线后，需规划前端性能探测的日志上报方案。@张建利
2. 数据治理
- 推进健康度配置的登记上线工作，需与各端做好沟通。@宝谦 @罗斌
- 推进调度任务的梳理和问题定位，可直接与开创技术团队沟通资源。@张建利 @余建新
3. 遗留问题跟进
- 协调各端安排专人，完成活动中心"必填项"的测试工作。@王琪 @陈思 @李赵丹
- 现场对齐并解决活动中心页面扫码时间必填项的问题。@李赵丹 @余建新
- 协助处理因消息重发导致的重复签收数据问题。@余建新 @李宝仟
- 排查并确认马松状态签收的准确性问题。@李宝仟
技术面试 — 候选人焦岩琳
评估结论
- 整体评价：沟通良好
- 技术能力：技术优化、技术方案部分可以清晰表达且方案可行
- 不足之处：个别问题没有理解到位，但问题不大
技术面试 — 候选人刘浩然
评估结论
- 面试结果：不通过
激励活动逻辑漏洞问题讨论
本次会议主要围绕售卖激励和签收激励活动中发现的逻辑漏洞展开讨论，明确了问题原因、影响范围及后续的修复与排查方案。
小结
1. 激励活动逻辑漏洞
经排查，售卖激励和签收激励功能存在逻辑漏洞，导致部分用户在未满足活动范围条件的情况下仍可中奖。
- 根本原因：代码实现中，当"执行门店范围"未填写具体门店而选择"与活动范围一致"时，系统会将其视为"all"，并直接跳过对门店的校验逻辑，仅校验了授权经销商。
2. 影响范围与解决方案
- 除了已定位的售卖激励和签收激励，会议提出需进一步梳理BC端扫码查活动、抽奖等环节，排查是否存在类似漏洞。
- 临时解决方案：手动将现有活动的门店范围配置在规则中，以强制校验，控制问题蔓延。
待办
1. 问题修复与影响梳理
- 由李明非牵头，先由余勇军负责补充核心的校验逻辑代码。@李明非 @余勇军
- 王建朝需协同张喜，进一步排查是否存在其他受影响的功能点。@王建朝 @张喜
2. 问题影响范围确认
- 刘晓娜需紧急联系业务同学，沟通线上问题的具体情况，并推动临时方案的落地。@刘晓娜
3. 整体逻辑梳理与对齐
- 李明非需全面梳理售卖激励、签收激励及BC端扫码查活动等环节的逻辑。@李明非
- 李明非需与宋阳对齐梳理结果，确保无遗漏。@李明非 @宋阳
4. 内部进度同步
- 李明非需在下午向刘晓娜同步本次会议的进展。@李明非 @刘晓娜
距离查询接口性能压测问题讨论
本次会议主要围绕距离查询接口的性能压测问题展开，重点分析了其TPS波动的原因，并探讨了后续的优化方案。
小结
1. 性能压测问题分析
在对距离查询接口进行性能压测时，发现其TPS存在"断崖式"下跌的波动现象。
- 初步判断：该波动是由MySQL服务端的最大连接数限制（当前为4500）导致。当并发请求达到该阈值后，MySQL不再接收新连接，从而造成TPS骤降。
2. 压测模式与架构讨论
为定位问题，本次压测采用了两种模式：一种是关闭Redis缓存，使所有请求直接穿透至MySQL；另一种是保留缓存机制。
- 架构合理性：会议讨论了当前架构的合理性，指出在Redis缓存失效时发生"穿透"至MySQL是设计预期，而非性能瓶颈。当前MySQL的性能足以应对预期的TPS。
3. 数据库查询优化建议
- 当前问题：通过5段ID关联多张规则表进行查询的方式较为复杂，存在性能优化空间。
- 优化方案：提出可将5段ID与预计算的距离规则整合为一张宽表，每日定时刷新，以简化查询逻辑并提升效率。
待办
1. 数据库连接数调整
- 需联系中阳，将MySQL服务端的最大连接数进行上调，以解决当前压测中暴露的性能瓶颈。@张喜
2. 重新进行压测
- 在开启Redis缓存并调整网关配置后，需再次进行性能压测，以验证在缓存机制下的系统表现。@张喜
3. 数据库查询优化
- 调研将5段ID与距离规则整合为宽表的方案，并评估其可行性及实施计划。@张喜
B端出货功能发版计划讨论
本次会议主要围绕B端出货功能的发版计划展开，明确了停机方案、各端依赖关系，并重点讨论了上线验证方案。
小结
1. 发版计划与停机方案
本次发版的核心是B端出货、查证、盘点相关服务。
- 为保障抽奖服务（关联活力、安慕希小程序）的连续性，决定采用"部分服务停机"的策略，而非全量停机。
- 具体停机顺序：营销助手、小智、智慧门店先行停机 → 抽奖服务不停机 → B端出货、查证、盘点等服务在确认上游无数据后进行发布。
2. 发布流程与依赖
- 发布前需确认上游服务（如营销助手）已停机，并等待几分钟以确保无在途数据。
- 将使用现有模板来制定详细的发布计划，明确各步骤的时间节点和负责人。
- 若发布失败，将执行代码及DDL脚本的回滚。
3. 上线验证方案
由于缺少可验证的门店账号，传统的全流程验证方案难以实现。
- 讨论了两种替代方案：
- 使用已售出的码进行"自主签收"接口的校验
- 寻找已关闭的"盐城顶点"经销商作为业务模拟环境，打通SFA出货至签收的完整链路
待办
1. 发布计划细化
- 张喜需根据会议讨论结果，完善详细的发布计划，并使用现有模板进行填写。@张喜
2. 上线验证方案落地
- 张建利需协调业务方，获取用于验证的业务账号。@张建利
- 邱毅需联系杨慧，探讨利用"盐城顶点"经销商打通SFA出货至签收的完整验证链路。@邱毅
3. 组织发布前会议
- 马奇需在当晚组织一次线上会议，邀请各端研发及发布相关人员参会，同步发布计划和准备情况。@马奇
盘点数据重复问题修复方案讨论
本次会议主要讨论了盘点数据重复问题的修复方案，明确了清洗范围、技术实现路径及潜在风险。
小结
1. 数据重复问题与修复范围
- 问题背景：数据库中存在因重试机制导致的重复盘点记录，影响数据准确性。
- 修复目标：清洗2025年1月1日至今的数据，以修正重复记录。
- 业务影响：业务侧（如结案补贴）依赖于准确的盘点次数，重复记录可能导致补贴发放错误。
2. 技术修复方案
- 核心思路：创建临时表，将需修复的数据迁移至其中；根据check_id批量删除源表中的重复数据；将临时表中的数据回写至源表。
- 数据处理：对于同一商品码的多次重复记录，将根据其首次出现的盘点次数进行重新计数。
- 风险规避：讨论将数据清洗与MongoDB的回写操作拆分为两个独立步骤，以避免清洗期间因新数据写入而导致结果不准确。
3. 方案实施与潜在问题
- 实施时机：讨论了在业务高峰期进行在线清洗的风险，倾向于寻找停机窗口进行操作，以确保数据一致性。
- 业务确认：需进一步与业务方确认，明确"盘点次数"字段的具体用途及是否必须在MongoDB中同步修正。
待办
1. 业务影响确认
- 刘晓娜需与业务方再次沟通，确认重复数据对结案补贴的具体影响，以及盘点次数字段是否必须在MongoDB中修正。@刘晓娜
2. 技术方案优化
- 梁健需将数据清洗与MongoDB回写操作拆分为两个独立的定时任务，以规避在线操作的风险。@梁健
- 梁健需与王建朝确认，关于通过CSV文件批量删除数据的技术方案的可行性。@梁健 @王建朝
3. 数据清洗执行
- 梁健需在确认方案可行后，执行数据清洗任务，并寻找合适的停机窗口进行MongoDB数据回写。@梁健