一、技术类问题

问题：大促期间系统如何支持每分钟3万单？具体用了哪些技术手段？

回答： “这个问题我们当时分了三步解决：

• 第一步是优化线程池。比如审单模块的线程池，核心线程数按机器CPU核数×2设置，最大线程数设到100，队列用LinkedBlockingQueue防止任务丢失，拒绝策略选了CallerRunsPolicy（让提交任务的线程自己执行）。这样既能吃满CPU，又不会压垮系统。
• 第二步是消息队列削峰。订单创建后先扔到RabbitMQ，消费者按固定速率拉取，比如每秒500单。这样即使瞬间来3万单，系统也能慢慢消化，不会崩。
• 第三步是SQL和缓存优化。比如库存回传，原来每条订单都实时更新数据库，后来改成批量处理，每攒100条更新一次。同时用Redis缓存库存数据，用Lua脚本保证原子性。 像完美日记的双11项目，这三板斧下去，系统硬是扛住了每分钟3万单，客户那边零故障。后来复盘时，我们还发现审单模块的CPU占用从90%降到了60%，效果特别明显。”

大促期间如何保证每分钟处理3万单？

“首先是优化线程池配置。比如核心线程数根据机器CPU核数翻倍设置，队列用LinkedBlockingQueue防止任务丢失，同时设了拒绝策略兜底。其次是削峰填谷，用RabbitMQ把订单先堆积到队列里，再匀速消费。最后是SQL优化，比如把实时库存更新改成异步批量处理。像完美日记双11项目，我们通过这些手段硬是把系统扛住了，客户那边零故障。”

库存超卖问题怎么解决？

“我们用了Redis分布式锁+数据库乐观锁的组合拳。用户下单时，先用Redis锁住库存Key，防止其他线程同时扣减。然后数据库更新库存时用version字段做乐观锁，保证最终一致性。比如花西子的促销活动，高峰期每秒几千请求，这套方案基本没出过超卖问题。”

二、项目类问题

问题：OMS和OFS系统如何协同工作？你在这两个项目中最大的贡献是什么？

回答： “OMS负责订单的‘计划’，比如客户下单后，OMS决定从哪个仓库发货、促销规则怎么算、库存怎么分配；OFS负责‘执行’，比如把订单分到仓库、生成物流单、回传发货状态。两个系统通过接口实时同步数据。 我在OMS项目里最大的贡献是重构库存计算逻辑。原来的库存数据分散在几十张表里，每次计算要关联查询，大促时经常超时。后来我重新设计了数据结构，把渠道库存、店铺库存统一用Redis的Hash结构存储，用Lua脚本保证原子更新。这一改，库存计算速度直接提升了30%，高峰期系统再也没卡过。 在OFS项目里，我主导了多平台对接方案。比如抖音和拼多多的订单格式差异很大，我们抽象了一层通用接口，把不同平台的订单转成内部标准格式。举个例子，抖音的订单号是字符串，拼多多是数字，我们在适配层统一转成‘平台+ID’的格式，后续处理完全不用关心来源。这套方案后来对接了十几个平台，开发效率提升了50%。”

OMS和OFS的区别是什么？

“OMS是订单管理系统，主要负责订单创建、库存分配这些‘计划层’的事；OFS是订单履行系统，负责实际执行，比如分单、物流路由、发货。举个例子，OMS告诉你有100件货能卖，OFS负责把这100件分到不同仓库，安排快递送出去。两个系统通过接口实时同步数据，像武汉中百的项目里，我们就是靠OMS和OFS联动，把订单处理效率提了30%。”

对接多个电商平台时，怎么设计通用接口？

“不同平台的API差异很大，比如淘宝用RESTful，拼多多用自定义协议。我们的方案是抽象一层适配器，把各平台的订单数据转成内部统一格式。比如抖音的订单拉取接口，我们封装了一个代理模块，自动处理签名、分页这些细节。这样后续对接新平台，只需要加个适配器，不用动核心代码。不过兼容性问题还是有的，比如小红书返回的字段经常变，我们就加了监控告警，一有异常立马修复。”

完美日记双11项目中的最大挑战？

“最大的挑战是瞬间流量太高，系统扛不住。比如订单审单模块，平时每秒处理几百单，双11直接飙到上万。我们当时紧急做了两件事：一是把审单逻辑从同步改成异步，用消息队列缓冲；二是优化库存缓存，把Redis的读写从单节点改成集群模式。最后系统稳定支持了每分钟3万单，客户还专门发邮件表扬了我们团队。”

三、管理类问题

如何分配任务并保证项目按时交付？

“我一般会先拆解需求，把任务分成‘核心功能’和‘优化项’。核心功能必须按时完成，优化项可以适当后置。比如武汉中百项目，我们优先保证订单流程跑通，界面美化放到二期。每天站会同步进度，如果有风险提前拉人支援。之前有个新人进度慢了，我就安排老员工和他结对编程，最后项目反而提前两天上线了。”

团队成员技术水平参差不齐怎么办？

“我会根据能力分配任务，比如新人做增删改查，高手攻坚性能优化。同时定期组织技术分享，比如让负责Redis的同事讲讲缓存设计，大家互相学习。之前带团队时，我还搞了个‘代码实验室’，每周抽半天一起Review代码，讨论怎么改进。半年下来，团队的整体代码质量明显提升，Bug率降了20%。”

如何应对客户紧急需求与系统稳定性的冲突？

“先评估需求的影响范围。比如客户要求加个新促销规则，如果改动不大，可以临时发版；如果涉及核心逻辑，就说服客户分阶段上线。之前易恒健康有个需求要改库存计算方式，我带着产品和客户开会，用数据说明风险，最后客户同意先灰度测试，再全量发布。这样既满足了客户，又没让系统崩掉。”

作为技术经理，如何保证团队代码质量？

回答： “我主要用了三个方法：

• 第一是强制代码评审。每个需求必须有至少两人Review才能合并，重点检查性能隐患和边界条件。比如有一次新人写了段全表扫描的SQL，被评审时发现后立马优化，避免了线上事故。
• 第二是定期技术培训。每周五下午留两小时，轮流让团队成员分享技术难点，比如Redis持久化机制、MyBatis批量插入优化。我还会把项目里的典型问题整理成案例，比如‘库存超卖事故复盘’，让大家一起讨论解决方案。
• 第三是自动化工具。我们引入了SonarQube做静态代码检查，CI/CD流程里加了单元测试覆盖率要求（不能低于70%）。之前有个项目因为赶进度没写测试，结果上线后连环报错，后来我们定死规矩——没测试的代码不准上线。 半年下来，团队的Bug率降了25%，客户投诉也少了一大半。”

四、业务理解类问题

OMS系统在供应链中的核心价值是什么？

“OMS就像供应链的大脑，它把订单、库存、物流这些环节串联起来。比如客户下一个订单，OMS要决定从哪个仓库发货、怎么分配库存、促销规则怎么算。我们给花西子做的OMS，把订单处理时间从5分钟压到10秒以内，还能实时同步到所有电商平台，这就是它的价值——提升效率，减少人工干预。”

未来供应链系统的发展趋势？

“我觉得有两个方向：一是智能化，比如用AI预测销量，自动调拨库存；二是全渠道一体化，比如线上线下库存打通，消费者在哪下单都能快速发货。之前我们尝试过用算法优化调拨路径，把武汉中百的运输成本降了15%，这可能就是未来的常态。”

问题：OMS系统如何提升供应链效率？举个实际例子。

回答： “OMS的核心价值是全链路协同。比如武汉中百的项目，他们原来线下门店和线上商城库存是分开管理的，经常出现线上显示有货，实际仓库没货的情况。我们通过OMS把线上线下库存打通，设置了一套自动分配规则：线上订单优先从中心仓发货，线下订单从门店仓调拨。 同时，OMS还接入了抖音、拼多多的实时订单。举个例子，抖音直播卖爆一款商品，OMS能自动触发库存预警，提醒采购部门补货。这套系统上线后，武汉中百的订单处理时间从平均2小时压缩到10分钟，人工干预减少了80%，客户直接续签了三年合同。”

五、行为类问题

举一个主动学习新技术并应用的例子？

“之前团队用MyBatis时，遇到复杂查询性能差的问题。我自学了MyBatis-Plus的Lambda表达式和动态SQL，重新封装了数据访问层，把查询代码量减少了40%。后来还组织了一次分享，教团队用新写法，大家反馈说开发效率高多了。”

为什么从开发转向技术管理？

“其实我一开始更喜欢钻研技术，但后来发现很多问题光靠写代码解决不了。比如带团队做武汉中百项目时，要协调前后端、和客户沟通需求，这比写代码更有挑战性。现在我的目标是成为既懂技术又懂业务的管理者，能带着团队做出真正解决痛点的产品。”

问题：举一个你主动推动技术改进的例子。

回答： “在OFS项目里，我发现订单分单模块用的是随机算法，导致某些仓库爆单，有些仓库闲置。我主动调研了智能分单方案，比如根据仓库库存、物流成本、配送时效动态计算最优路径。 为了验证效果，我先用Python写了个模拟脚本，对比随机分单和智能分单的成本。数据跑出来发现，智能分单能降低15%的物流费用。后来我带着两个同事用Java重构了分单模块，接入了高德地图的API计算距离，还加了实时库存权重。 这个功能上线后，客户易恒健康的物流成本当月就降了10%，他们CTO还专门打电话来夸我们这个改进‘既有技术含量，又懂业务’。”

红色文字

• 符号表示：::
• 符号说明：双冒号为方法引用运算符，而它所在的表达式被称为方法引用
• 应用场景：如果 Lambda 所要实现的方案，已经有其他方法存在相同方案，那么则可以使用方法引用

方法引用的格式

• 符号表示：::
• 符号说明：双冒号为方法引用运算符，而它所在的表达式被称为方法引用
• 应用场景：如果 Lambda 所要实现的方案，已经有其他方法存在相同方案，那么则可以使用方法引用