2026-08-13 工作日志
高并发性能瓶颈与缓存穿透方案讨论会
本次会议主要围绕高并发场景下的性能瓶颈问题展开讨论，重点探讨了缓存穿透的解决方案，并明确了后续的技术评估方向。
小结
1. 高并发性能瓶颈与缓存穿透问题
- 当前系统在处理"一码多"扫码报表生成时，因并发请求过高，导致数据库查询压力巨大。
- 讨论发现，现有的缓存方案存在缺陷：在首次查询时，若数据库响应时间较长，后续的并发请求在缓存未写入前仍会穿透至数据库，造成性能问题。
2. 解决方案探讨
- 方案一：增加读锁：为首次查询的数据操作增加一个短暂的读锁（如 500–1000 毫秒），确保在第一个请求完成并写入缓存前，其他请求都等待，从而避免并发查询。
- 方案二：异步处理：将高并发的循环查询改为异步消息队列处理。第一个请求同步执行并写入缓存，后续请求则直接命中缓存，以此来削峰。
- 其他建议：会议中也提出了将数据表整体放入缓存、使用数据库读写分离等其他思路，但均被认为存在数据一致性风险或无法从根本上解决问题。
3. 技术方案评估与链路梳理
- 会议强调，在实施任何技术方案前，必须先完整地梳理出问题相关的完整技术链路，明确所有触发点和真实存在的高并发场景。
- 各方同意将技术方案的可行性、开发难度和预期效果进行综合评估，再进行决策。
待办
1. 技术方案评估与链路梳理
- 宋洋需尽快梳理出完整的业务链路，并评估"增加读锁"和"异步消息队列"两种方案的可行性、开发难度和预期效果。
- 宋洋需找到梁建之前梳理过的相关文档，作为本次链路梳理的参考。
- 宋洋评估完毕后，需与王建朝和李明非同步结论。
MCP Server 技术架构与安全设计及 AI 培训计划同步会
本次会议介绍了 MCP Server 的技术架构与安全设计，并同步了后续 AI 培训的调研计划。
小结
1. MCP Server 技术架构与设计
- 为兼容生产运营管理系统及后续的仓储类业务系统，采用独立工程的方式构建 MCP Server。
- 该架构可兼容存量系统，通过 OpenAPI 进行调度，减少对存量系统的改造工作量。
- 技术栈基于较新标准，如 Java 17 及以上版本。
2. MCP Server 安全设计
- 构建了包含签名校验、客户端指纹（NetID）绑定和重放防护在内的双重安全架构。
- 设计了基于 User-Agent 的工具权限过滤机制，可根据客户端类型动态控制其可调用的工具范围。
3. MCP Server 工具设计原则
- 工具定义需清晰说明功能、参数及返回值，确保 AI 能准确理解。
- 参数描述应能帮助 AI 判断取值范围。
- 工具应尽量返回字符串类型，便于 AI 处理。
- 倾向于采用单一职责原则，将复杂的业务流程拆分为多个工具。
4. AI 培训计划同步
- 团队已开展多场 AI 相关培训，后续将发起一份调研问卷。
- 调研旨在了解现有培训内容的掌握情况，并收集各岗位在工作中对 AI 赋能的具体需求。
待办
1. AI 培训资料同步
- 刘圣需将本次会议的录屏发送给技术顾问，以便其了解相关内容。
经销商电子围栏缓存击穿问题讨论会
本次会议主要围绕经销商电子围栏功能引发的缓存击穿问题展开讨论，明确了当前的解决方案、潜在风险以及后续的测试和备选方案。
小结
1. 缓存击穿问题与解决方案
- 问题背景：在大批量出货场景下，由于并发请求同时调用电子围栏接口，且无有效缓存，导致大量请求直接打到数据库，引发 CPU 飙升和响应缓慢。
- 解决方案：在 RPC 调用的最外层增加一层分布式锁。该方案通过先查询缓存、获取锁、执行数据库查询并写入缓存的流程，确保同一查询在 30 秒内只对数据库发起一次请求，从而解决缓存击穿问题。
2. 方案风险与备选方案探讨
- 风险：当前方案仅针对电子围栏功能进行了改造，范围有限。若未来其他依赖此通用方法的场景（如产品信息、仓库信息查询）也存在类似并发问题，可能需要进行大规模改造。
- 备选方案：会上讨论了其他备选方案，包括将缓存从 JVM 内存改为 Redis、采用读写分离或直接将数据全部加载到 Redis 中，但考虑到性能和改动成本，这些方案暂未采纳。
3. 问题根因分析
- 经排查，问题根源在于业务逻辑。由于存在一个通用方法，用于处理出货、签收、退货、盘点等多种场景下的串货判断，而这些场景下的批量操作会开启多线程并发调用，导致了高频次的数据库访问。
待办
1. 缓存方案测试与验证
- 需要对缓存方案进行更全面的测试，重点验证以下场景：缓存过期机制（30 秒缓存过期后后续请求的行为）；高并发场景（使用大单或小单进行并发测试，确保缓存效果稳定）；锁机制（验证多 Pod 环境下分布式锁的有效性）。 — @吕杰
2. 数据库性能保障
- 若缓存方案无法在明天发版前解决性能问题，则需准备启用数据库读写分离的预案。 — @李明非
3. 发布后监控
- 在功能正式发布后，需在明天下午 7–8 点左右密切观察数据库的性能指标，确保问题得到解决。 — @宋洋