📚 课程目录第4章高并发与账务一致性

第4章高并发与账务一致性

支付系统在秒杀、批量扣款等高并发场景下，既要保证账户余额不超扣，又要防止重复扣款。核心解法围绕乐观锁、分布式锁、幂等设计展开，同时依赖异步对账兜底最终一致性。面试中通常会从具体业务场景切入，层层追问边界与取舍。

面试官考察点	是否理解原子操作、乐观锁与分布式锁的适用边界，能否考虑并发、重试与对账的整体方案
回答框架	① 使用乐观锁（`UPDATE account SET balance=balance-amount WHERE id=? AND balance>=amount`） ② 配合重试机制（更新行数为0则回滚并重试） ③ 对极端冲突场景引入分布式锁（Redis锁+超时续期） ④ 异步对账兜底，保障最终一致
简短示例回答	一般采用乐观锁，在SQL中利用余额判据原子扣款。若更新行数为0则说明余额不足或并发冲突，业务方重试。对于热点账户，可前置分布式锁减少重试开销，同时设置锁超时和续期，最后通过每日对账发现并修正不一致。
可能追问	乐观锁在极高并发下性能如何？如何避免ABA？分布式锁死锁如何解决？锁超时时间怎么设？
避坑提醒	❌ 不要将余额检查放在应用层（非原子操作） ✅ 必须利用数据库或Redis原子指令 ⚠️ 分布式锁注意锁续期，防止业务未完成锁自动释放

面试官考察点	幂等方案设计能力、唯一ID生成策略、去重表与缓存的配合、补偿机制
回答框架	① 请求方生成全局唯一幂等键（UUID/雪花ID） ② 服务端先查Redis幂等表，存在则直接返回历史结果 ③ 不存在则执行扣款，并写入DB唯一索引幂等表（与业务事务同库或可靠消息） ④ 超时情况做状态机查询，配合定时清理过期记录
简短示例回答	每次扣款携带全局唯一ID，服务端先检查Redis，若命中则直接返回；否则执行扣款事务，同时向幂等表中插入该ID（利用数据库唯一索引防并发），事务成功则写入Redis。超时或失败时客户端重试，服务端返回已有结果。
可能追问	幂等表如何清理？分布式场景下幂等键生成策略？补偿（冲正）与幂等关系？如何保证幂等检查与业务操作原子性？
避坑提醒	❌ 幂等键由服务端生成（客户端无法保证重传时唯一） ✅ 必须由客户端提交并携带 ⚠️ 避免用业务订单号直接作为幂等键（可能被伪造或重复提交）

面试官考察点	对三种锁原理与性能的深入理解，能否根据并发量、失败代价做出合理选型
回答框架	① 乐观锁：适合低冲突、短事务场景（常见账户扣款），利用version或余额判据，重试成本低 ② 悲观锁（SELECT FOR UPDATE）：适合高冲突、长事务（对账批次、红包拆分），死锁风险需关注 ③ 分布式锁（Redis/zk）：适合跨服务、跨库操作同一资源，注意锁超时、脑裂、性能开销
简短示例回答	乐观锁适用于普通扣款，使用version字段，冲突少时性能极高。悲观锁用于对账批次等长操作，防止其他事务修改。分布式锁用于跨服务操作同一账户（如组合支付），搭配Redlock解决脑裂，但需容忍性能损失。选型核心看冲突概率与失败重试代价。
可能追问	乐观锁一定比悲观锁好吗？分布式锁如何降级？同时使用乐观锁与分布式锁是否矛盾？
避坑提醒	❌ 不要一刀切认为乐观锁最优（热点账户冲突高时重试压垮DB） ✅ 热点账户推荐排队串行化+分布式锁 ⚠️ 悲观锁长事务可能导致锁超时或死锁，需设置超时时间

💡 面试策略：回答时先抛出核心方案（如乐观锁+幂等+对账），再根据面试官追问深入细节。准备一个自己亲身参与或设计的扣款系统案例（例如“某支付平台秒杀活动，日扣款500万笔”），用STAR结构描述冲突率、锁超时、对账延迟等真实指标，会极大加分。

第4章 高并发与账务一致性