一一中文网

手机浏览器扫描二维码访问

第13章 一面 技术经理（第2页）

两个难点。

讲到库存扣减时，他特意提到了最初使用数据库行锁导致性能瓶颈，后来引入Redis+Lua脚本实现分布式锁和预扣库存的方案。

王磊一直安静听着，偶尔在面前的笔记本上记录几笔。

等林晨说完，他推了推眼镜：“你提到用Redis做库存预扣。

如果Redis集群出现网络分区（脑裂），导致部分节点数据不一致，怎么保证最终扣减的准确性？你们有做补偿或对账机制吗”

？

这个问题有点深。

林晨略一思索，答道：“有的。

我们当时设计了两层保障。

第一层，所有扣减操作除了写Redis，还会异步发消息到mq，由另一个服务落库作为‘操作日志’。

第二层，有定时任务，在每天业务低峰期，跑批将Redis里的库存快照与数据库里的‘操作日志’进行核对，如果发现不一致，以数据库日志为准进行修正，并报警。

虽然不能做到强一致，但保证了最终一致和业务可追溯”

。

“代价是延迟修正和数据短暂不一致的可能”

。

王磊指出。

“是的”

，林晨点头，“这是权衡的结果。

秒杀场景下，性能和高可用优先级高于强一致。

我们通过设置合理的库存安全阈值和监控，将风险控制在可接受范围。

实际运行两年，未因此产生过重大资损”

。

王磊不置可否，接着问：“好。

下一个问题，还是这个系统，你提到订单查询慢，优化后qpS提升五倍。

具体优化手段”

？

“主要是数据库层面”

。

林晨进入更熟悉的领域，“当时订单表数据量过亿，查询用户历史订单的接口响应很慢。

我们分析了慢查询日志和SqL执行计划，发现几个问题：一是查询条件经常组合变化，索引命中率低；二是存在大量回表查询；三是有些关联查询写法不优”

。

“怎么解决的”

？“第一，针对核心查询路径，我们重新设计了联合索引，考虑查询频率和区分度，比如把‘用户Id+下单时间’作为最左前缀。

第二，对一些高频且字段固定的查询，比如只查订单号、状态、金额，我们做了覆盖索引，避免回表。