Work for YILI

Appearance

2026-09-07 工作日志 ​

物码早会：数据治理项目周会 ​

  • 发言人：李亚洲、邢健、孙东栋、余建新、刘晓娜等 6 人
  • 主题摘要：本次会议同步了积分上线、报表及主数据一致性等核心项目进度，重点讨论了新增数据告警问题，并明确了后续项目反馈跟进与文档更新等任务。

小结 ​

一、项目整体进度同步

1. 积分与报表项目

  • 积分上线排期需调整：当前积分上线时间与 10 月 20 日的计划时间过近，需考虑整合版本以减少发版次数，后续将在修订版中更新。
  • 报表项目进入 SIT 阶段：本周报表项目将进入**系统集成测试（SIT）**阶段，整体进度正常。

2. 主数据与数据一致性

  • 门店数据初始化测试准备：主数据今日将导出测试环境的门店数据，供智慧门店进行初始化测试使用。
  • 营销活动中心需求排期待定：主数据已完成旧围栏数据查询接口下线，目前正等待营销活动中心反馈围栏数据应用优化需求的排期。
  • 导购与经销商关系一致性处理：本周需开展导购与经销商关系的一致性处理工作，若底座涉及相关问题需同步调整。
  • 云商一致性告警待解决：周末云商出现产品一致性告警，今日需进行问题分析与解决。
  • 智慧门店告警分析延后：因主数据资源问题，上周智慧门店的数据一致性告警分析未完成，今日将继续推进。

3. 数据监控与告警

  • 新增两条数据告警：周五至周日新增两条数据告警，需今日排查告警原因，其余告警均在已知范围内。

二、后续安排与待跟进事项

1. 运营项目反馈跟进

  • 等待项目业务反馈：运营项目需等待上周六决议及项目业务反馈，暂不推进至公共层，后续将视反馈情况调整。

2. 血缘关系文档更新

  • 在线文档需补充更新：智慧门店与主数据的血缘关系梳理已进行双向核对并识别出小问题，需协调资源对在线文档进行补充和更新。

待办 ​

  • 在修订版中更新积分上线排期，以减少发版次数。 — @余建新
  • 发布修订版后，重新维护并更新相关项目进度。 — @孙东栋
  • 关注并整理项目业务的反馈情况。 — @晓娜（刘晓娜） @建新（余建新）
  • 继续开展智慧门店数据一致性告警的分析工作。 — @邢健
  • 等待营销活动中心反馈 5 段围栏数据应用优化需求的排期。 — （责任人待明确）
  • 开展导购与经销商关系的一致性处理工作。 — @邢健
  • 分析与解决周末云商出现的一致性告警问题。 — @邢健
  • 协调资源对智慧门店与主数据的血缘关系在线文档进行补充和更新。 — @任铭
  • 排查并分析新增的两条数据告警原因。 — @孙东栋

关联与提示：

  1. 发版合并：本场"积分上线与 10.20 计划过近、需整合版本减少发版次数"，与 9.04 物码早会"评估 9、10 月发版合并方案"（责任人待指派）为同一议题的推进版——两次会议均提出减少发版次数，但合并方案的评估结论与责任人至今未落地，建议本周闭环。
  2. 告警连续性：本场三条告警相关待办（云商一致性告警、智慧门店告警分析延后、新增两条告警）延续自 9.04 的"店主告警需排查""告警序号 12/4"，且 9.04 已提示"调阈值忽略微量差异需留痕"。本场为新增两条，需关注是否为同类存量差异问题。
  3. 旧接口下线：主数据已完成旧围栏数据查询接口下线，与 9.04"营销活动中心今日确认排期并下线旧接口"（@邢健）呼应；同时 9.04 记录"内部人员接口受供应商评估影响延至 9.9"，本周需跟踪。

Java 开发工程师技术面试 ​

  • 发言人：张玉龙、张建利、王建朝、薛碧盈、宋洋等 6 人（候选人未在原文中明确标注，按原文保留名单顺序）
  • 主题摘要：本次会议为 Java 后端开发岗位的技术面试，重点考察了候选人在民生金融项目中的高并发处理、分布式事务及微服务组件应用能力，并指出了其在部分底层原理上的理解盲区。

小结 ​

一、候选人基本情况与项目经验

1. 个人背景与核心技术栈

  • 9 年 Java 后端开发经验：技术栈主要集中于 Spring Cloud 微服务架构，近期主导过 0 到 1 的微服务改造项目。

2. 核心项目经历

  • 电网与金融项目经验：曾参与国家电网、南方电网的报表业务，并主导过北京金融交易所计费系统四期项目，担任小组负责人。
  • 民生融资租赁项目：负责消保客服与文档中心模块；近期在金融财务公司为中粮等国企开发风控系统，日常使用 AI 辅助编码工具。

二、民生项目技术难点与解决方案

1. 文档中心高并发与目录创建问题

  • 引入 Redis 可重入锁解决并发冲突：针对高并发下目录重复创建问题，候选人从全路径加锁优化为从根目录开始的一级加锁方案，成功支撑每秒 500 个请求的并发量。
  • 架构优化视角存在盲区：追问架构或设计层面的优化点时，候选人表示未考虑过技术方案之外的优化方向。

2. 批量文件匹配导致的主从延迟问题

  • 多线程与 ES 替换解决延迟：针对定时任务批量匹配文件导致的 MySQL 主从延迟（最高达 3 小时），通过引入多线程分批落库，并将第三层日志转移至 Elasticsearch，最终将延迟降至 2.5 小时以内。
  • 日志存储方案演变：初期因需在前端展示三级目录的详细匹配结果而将日志存入 MySQL，后因性能瓶颈改为存入 ES。

3. PDF 合同生成技术选型

  • 从 PDFBox 切换至 OpenPDF：替换收费的 iTextPDF 时，因 PDFBox 存在文本上浮、复选框值必须唯一的技术限制，最终改用 OpenPDF 完成盖章合同生成，并在内部进行了技术分享。

三、消保客服系统架构与中间件应用

1. 业务背景与技术选型

  • AI 语音助手与 Flowable 工作流：系统接收德助 AI 语音助手的通话记录，采用 Flowable 工作流引擎处理复杂的投诉与调解流程。

2. RabbitMQ 数据同步与幂等性设计

  • 基于 MQ 的最终一致性同步：采用 RabbitMQ 实现 TX 服务与消保客服系统间的数据同步，通过生产者确认机制、消息持久化、消费者手动 ACK 保证最终一致性。
  • 多重幂等性兜底机制：消费端通过 Redis 锁 + 数据库唯一主键查询 + 唯一索引，防止短时间内多次同步调用导致的数据重复。
  • 死信队列人工干预：重试三次仍失败的消息转入死信队列，并提供独立的人工处理页面进行排查与确认。

四、基础组件与框架原理考察

1. RabbitMQ 核心概念考察

  • Exchange 类型记忆模糊：面试官询问 RabbitMQ 支持的 Exchange 类型，候选人表示仅了解但未详细记忆，未能准确回答项目中使用的具体类型。
  • 分布式事务概念理解偏差：面试官指出候选人将"最终一致性"等同于"分布式事务"，候选人随后澄清其方案仅为最终一致性、而非强一致性。

2. 微服务组件认知考察

  • 混淆 Spring Cloud 与 Alibaba 组件：候选人将 Gateway、LoadBalancer 等 Spring Cloud 原生组件误认为 Spring Cloud Alibaba 专属组件，面试官对此进行了纠正。

3. XXL-JOB 应用考察

  • 定时查询发送催办短信：超时工单关闭场景中，候选人未基于 XXL-JOB 进行二次开发，而是编写普通定时任务，每天早 8 点批量查询超时工单并发送短信。

待办 ​

  • （本场为技术面试，无待办事项；最终录用结论未见记录，待补充）

隐私提示：本节含候选人项目经历、技术能力评价与知识盲区记录，属人事敏感信息。本文件位于 VitePress 文档站 docs/work-log/ 目录，是否适合随站点发布/共享，建议确认后再决定是否保留或脱敏。

Java 后端开发技术面试（第二场） ​

  • 发言人：屈宗凯、张建利、王建朝、薛碧盈（候选人未在原文中明确标注；与上一场对比，张建利、王建朝、薛碧盈同为两场出席者，据此推测面试官班底为这三位，首发位疑为候选人，按原文保留未做确定）
  • 主题摘要：本次会议为 Java 后端开发岗位技术面试，重点考察了候选人在实时通信、代码分支管理、数据库优化、Spring Boot 注解及 JVM 内存调优等方面的技术能力与项目经验。

小结 ​

一、候选人项目经验与实时通信架构

1. 核心项目经历

  • 主导医疗全流程管理系统：近期为北京协和等医院开发核医学管理系统，负责患者从签到、诊断到注射检查的全流程后端把控与上线部署。
  • 曾负责 MES 与科研管理系统：过往参与 MES 仓储系统（物料管控与设备状态记录）及北科院科研管理系统（成果上报审批流）的开发。

2. WebSocket 与 MQTT 协议应用

  • WebSocket 解决双向通信问题：患者签到场景中，因 SSE 单向通信无法满足 Pad 端回执需求，改用 WebSocket 长连接，实现 PC 端下发指令与 Pad 端状态同步的实时双向交互。
  • MQTT 与 HTTP 核心差异：MQTT 采用发布订阅模型且报文体积小，适合物联网等长连接场景；HTTP 为一问一答的短连接模型，网络开销相对较大。

3. 消息重复与丢失解决方案

  • 通过唯一 ID 与本地缓存去重：服务端为每条签到指令生成唯一 ID，Pad 端收到消息后先查本地缓存，若 ID 已存在则直接丢弃，避免重复执行业务逻辑。
  • 基于 ACK 机制与状态校对兜底：服务端等待客户端回执、超时则重推；客户端处理完重复消息后仍需回复 ACK 报文，并结合本地持久化 + 服务端状态校对机制保障数据一致性。

二、代码分支管理与协作规范

1. 分支管理策略

  • 主分支与开发分支分离：主分支严格对接线上生产环境且仅接受合并，开发分支作为集成分支，新需求均从该分支拉取，迭代周期约两周。
  • 测试与上线流程：开发完成后合并至开发分支打包部署测试环境，测试人员验证无误后上线，并在线上进行全流程回归。

2. 代码冲突处理

  • 任务拆分与本地同步：团队在任务拆分时尽量减少对同一文件的修改，并要求开发人员随时将开发分支最新代码同步至个人分支。
  • 冲突解决需人工协调：多人修改同一文件导致冲突时，需相关人员共同协调，在本地 IDE 中解决后由提交人合并至开发分支。

三、数据库查询优化与索引原理

1. 慢查询定位与优化

  • 通过慢查询日志定位瓶颈：针对接口响应超时问题，利用 MySQL 慢查询日志获取执行计划，排查索引失效、SQL 函数处理、多表 Join 等问题。
  • 引入 Redis 缓存热点数据：查询较慢的统计类接口将热点数据放入 Redis 缓存，降低数据库查询压力。

2. 联合索引与最左前缀原则

  • 遵循最左前缀匹配原则：ABC 联合索引中，查询条件为 AB 或 AB 加 C 的 Like 前缀匹配时均可命中索引；跳过首列 A 直接查询 BC 则无法命中，会触发全表扫描。
  • 冷热数据分离方案：针对历史数据堆积，建议将不再变更的历史数据迁移至独立归档表，业务表仅保留近期活跃数据。

四、Spring Boot 注解与 JVM 内存管理

1. 常用 Spring Boot 注解

  • 组件声明与配置注解：熟练使用 @Controller、@Service、@Mapper、@SpringBootApplication 等进行组件声明与自动配置。
  • 请求映射与参数处理：掌握 @RequestMapping、@GetMapping、@RequestBody、@Valid 等，用于请求映射、JSON 解析与参数校验。
  • 事务控制注解：了解 @Transactional 在事务控制与回滚中的应用。

2. JVM 内存模型与 OOM 排查

  • JVM 核心内存模块：准确描述程序计数器、虚拟机栈、本地方法栈、Java 堆、方法区的作用及线程私有/共享属性。
  • OOM 溢出原因：指出堆溢出通常由静态变量未清空、长生命周期对象持有短生命周期对象、线程池大对象未释放导致的内存泄漏引起。
  • 内存监控与排查工具：推荐 jps 获取进程号，结合 jstat 监控 GC 变化、jmap 导出内存快照、jstack 排查线程死锁。

待办 ​

  • （本场为技术面试，无待办事项；最终录用结论未见记录，待补充）

隐私提示：同上一场——本节含候选人项目经历与技术能力记录，属人事敏感信息，随 VitePress 站点发布前建议确认是否保留或脱敏。 注：本场为今日第二场 Java 后端面试，两场面试官班底重合（张建利、王建朝、薛碧盈），可作为同一批次招聘面谈记录一并归档。

扫码错误记录与 H5 外网访问方案评审 ​

  • 发言人：张喜、王建朝、李明非、郝梓斐、宋洋等 9 人
  • 主题摘要：本次会议评审了扫码错误记录表技术方案，明确了数据测试与容错要求；因需求归属不明，决定重评二级渠道类型方案；并确认了 H5 页面外网访问与接口转发的部署方案。

小结 ​

一、扫码错误记录表技术方案评审（通过）

1. 核心设计与触发逻辑

  • 四类拦截场景触发：针对生产时间不满两天、货权不一致、码过期、状态校验不符四种扫码错误场景进行拦截。
  • 异步写入不阻塞主流程：错误数据通过自定义线程池异步写入 MongoDB，不影响出货扫码及后续加锁等主流程业务。

2. 数据存储与测试验证

  • MongoDB 时间字段存在 8 小时时差：数据库时间字段为 Date 类型（其余均为 String 类型），且 MongoDB 存储时间默认少 8 小时，需在方案中备注。
  • 测试环境无法全量验证：测试环境码数据为自造，无法关联 TDS 中间表，仅能验证基础数据写入，全量关联分析需线上验证。

3. 数据容错与代码侵入性

  • 允许极小概率数据丢失：中台仅需基于数据做趋势或概率分析，评估无需保证 100% 写入，极端情况下丢失几条不影响业务。
  • 强耦合埋点方式获认可：考虑错误类型固定、改动点少，直接在各报错分支处硬编码埋点比全局 AOP 拦截过滤更高效，方案通过评审。

二、二级渠道类型需求评审（推翻重做）

1. 需求归属冲突

  • 需求来源与文档不一致：主数据提供的技术文档基于液奶底座，但需求实际为积分需求，且涉及冷饮、奶酪、液奶等多个事业部，存在归属混乱。

2. 后续评估安排

  • 需重新编写并整体评估：因需求归属与接口文档均存在错误，决定推翻现有方案，由开发人员重新编写后随积分需求变更整体评审。

三、H5 页面外网访问方案评审（通过）

1. 部署与访问架构

  • 复用外网 Pod 转发内网接口：将 H5 页面与 Nginx 部署在可对外访问的 Pod 中，通过配置二级目录（如 /api）转发请求至内部服务，解决跨域问题。
  • 内外网连通性确认：Pod 内部网络互通，外网域名可正常加载页面，通过 Nginx 配置实现外网请求至内网接口的路由解析。

2. 潜在风险与实施计划

  • 需防范外网域名跨域风险：注意腾讯云外网域名与内网域名之间可能存在的浏览器跨域拦截问题，避免影响调试进度。
  • 先行实施并补充文档：开发人员先按该方案实施与调试，后续需将完整部署方案补充至对应技术文档。

待办 ​

  • 补充扫码错误记录表技术方案文档，备注 MongoDB 时间少 8 小时、数据容错性及强耦合埋点设计。 — @张喜
  • 重新编写二级渠道类型的技术方案，并随积分需求变更整体重新评估。 — @郝梓斐
  • 按 H5 外网访问方案先行实施调试，后续将完整方案补充至对应技术文档中。 — @李明非

关联与提示：

  1. ⚠️ H5 外网方案与 9.01 既有范式不一致：9.01「小智App接入盘点任务H5网络方案评审」确立的是 Controller 迁公网 Pod + Service 留内网走 RPC + 入口强制鉴权（App Key/Secret + Token）；本场采用的是 H5 + Nginx 部署外网 Pod、通过二级目录 /api 反向代理内网接口。两者架构层级不同（应用层拆分 vs 网关层转发），鉴权落点也随之不同——Nginx 反代模式下若鉴权未在 Nginx 或内网服务侧明确实现，内网接口等于对外裸奔。建议明确本方案的鉴权位置，并确定后续同类需求统一采用哪一种范式。
  2. MongoDB 8 小时时差建议按规范处理而非仅"备注"：该表将用于趋势/概率分析，时间口径错 8 小时会直接导致按天聚合的统计结论偏移。建议在方案中明确存储与读取的时区规范（统一 UTC 或统一东八区），并在写入侧固化，而不是留给下游各自换算。
  3. 验收方式需相应调整：测试环境因码数据自造、无法关联 TDS 中间表而只能验证基础写入，全量关联分析须线上验证——建议明确灰度范围、观察周期与回滚判据，避免"上线即验收"。
  4. 归属问题本周再次出现：本场"二级渠道类型"因归属混乱（文档基于液奶底座、实为积分需求、跨冷饮/奶酪/液奶多事业部）被推翻重做。这与 9.02 冷饮 H5 归属之争、SFA 与活动中心任务详情页之争、9.01 人员职务表事业部归属不清为同一类问题，week36 已总结"瓶颈在项目接缝处"，本场说明该问题仍未收敛，建议纳入架构整合专项一并解决。