2026-05-22 工作日志

技术面试 — 候选人啊力

本次会议为技术面试，面试官王建朝与候选人啊力进行了交流，主要围绕候选人过往项目经历、技术选型、难点及AI助手开发等方面进行了深入探讨。

小结

1. 候选人背景介绍

• 候选人啊力拥有12年以上开发经验，熟悉Java及前后端全栈技术。
• 工作经历涵盖多家公司，涉及银行，政府及科技项目，技术栈主要包括Spring Boot、MySQL、Redis、Kafka等。

2. 中数联科技"路联徽章"项目技术细节

• 项目架构：采用前后端分离模式，后端为Java Spring Boot，前端为Vue，数据库为MySQL，缓存为Redis，异步消息使用Kafka。
• 技术选型：讨论了Nginx与网关的区别。Nginx主要用于负载均衡，而网关则负责协议解析和路由控制。项目初期使用Nginx轮询，后引入网关以增强功能。
• 技术难点与解决方案：
  • 分布式锁：单体应用中的synchronized在分布式环境下失效，需引入分布式锁。
  • 水平越权：提出了通过在返回列表时生成Token，后端校验Token与数据是否匹配的方案，以解决数据越权访问问题。
  • Redis数据一致性：针对Redis与MySQL间的数据不一致问题，提及采用延迟双删、消息补偿及人工干预等多种机制保障数据一致性。

3. 方案评审与AI助手开发

• 方案评审：在中信银行项目中，曾作为安全专家评审方案，重点关注等保、国密及数据安全规范，如对口令加密、传输层加密（HTTPS）、数据完整性校验（哈希）及不可否认性（签名）等进行审查。
• AI助手开发：使用Java调用阿里云API及百炼平台的大模型，实现了多轮对话的上下文记忆功能。通过实现拦截器并结合Redis进行持久化，以支持流式返回数据。

---

B端出货加锁与扫码签收方案评审

会议主题：B端出货加锁与扫码即签收技术方案评审

发言人：张喜、邱毅、王建朝、陈德智、宋洋等12人

会议摘要：本次会议评审了 B 端出货加锁与扫码即签收技术方案，重点敲定了基于 Redis 的分布式锁机制及 MongoDB 分片策略，明确了业务数据校验规则与异常处理流程，并确定了后续集成测试与发版计划。

一、B端出货加锁方案设计

针对防止"一码多出"的业务痛点，会议确认了以数据库唯一索引为基础，结合缓存锁的并发控制方案：

1. 核心锁定与防重机制

• 分布式锁实现：采用 Redis 实现码级别的并发锁，确保同一时间同一码仅能被一人扫描占用。
• 数据库唯一约束：将二维码（Code）作为 MongoDB 的主键 ID 存储，利用其天然唯一性在数据库层面拦截重复插入。
• 状态流转逻辑：扫码接口同步返回结果，成功即落库；若后端已入库但前端超时未收到响应，二次扫码时会提示"已被占用"，由服务端保证幂等性。

2. 过期清理与归档策略

• 定时任务清理：设置 5 分钟执行一次的定时任务，对超过配置时间的记录进行清理。
• 整单过期逻辑：按订单维度分组，取组内最大过期时间为该单的最终过期时间，超出阈值则自动删除锁码记录并归档至历史表。
• 容错时间窗口：为防止临界点操作问题，系统设置了 10 分钟的缓冲时间（可配置），允许用户在过期后短时间内仍可提交。

3. 分片与查询优化

• 分片键选择：采用收货码（Receipt Code）或出货单号作为分片键，确保同一订单下的数据分布在同一个物理节点，提升批量操作效率。
• 查询接口优化：提供按单号分页查询锁码记录的接口，支持前端展示倒计时及被占用的用户信息。

二、扫码即签收方案演进

为简化操作流程，将原有的"扫入缓存+提交"两步操作合并为一步到位的"扫码即签收"：

1. 接口功能整合

• 一步到位签收：新接口将原有两个步骤合二为一，前端调用一次接口即可完成扫码、校验和签收入库。
• 校验逻辑下沉：将距离校验、货权校验、码状态校验等业务规则从客户端迁移至服务端，降低前端复杂度。

2. 全链路防重与一致性保障

• 状态互斥控制：明确了"盘点、查证、售出"三种场景不受加锁限制，其余场景需介入加锁判断。
• 异常场景兜底：针对网络超时等极端情况，制定了"前端重新拉取全量状态"的兜底策略，确保前后端数据一致。

三、业务数据治理与规范

针对多端数据来源不一致的问题，会议确立了统一的数据处理标准：

1. 五段归属原则

• 优先取值规则：确立"有店取店，无店取商"的原则。在业务操作中，若存在门店信息则优先使用门店五段，否则向上追溯所属经销商的五段。
• 跨团队共识：要求该规则必须在三个相关团队（SFA、智慧导购、后端）中达成共识并严格执行，避免因数据源不同导致报表口径混乱。

2. 字段冗余与传输规范

• 基础信息冗余：在数据传输过程中，必须携带"人、商、店、品"四个维度的完整基础信息，以减少对基础数据表的实时关联查询压力。
• 距离属性透传：明确门店距离属性为必传字段，由前端获取后透传给后端，用于风控和报表统计。

四、待办事项

• 准备 Demo 数据演示"不加容错时间"导致的极端差异场景，以便产品侧评估容错时间的合理性。@张喜 @金策
• 梳理"扫码机签收"在极端并发下的异常处理流程，并与前端团队对齐交互体验。@张喜 @金策
• 在下周一下午组织一次上线前的代码走查会，覆盖 528 版本的所有改动点。@张喜 @王建朝
• 在技术文档中补充关于"出货加锁"与"自主签收"共用分布式锁 Key 的设计规划，预留扩展性。@张喜