订单模型与状态机

订单中心搭到第二个月，我们发现线上一半的疑难故障都指向同一个根因：状态不明确。用户取消后又能支付，支付失败后状态停在待支付，客服看到的状态和库里对不上。这一章彻底解决它：先把表设计干净，再把状态机的转移规则写死在代码里，最后用锁和分区表兜住并发与数据量。

章节 核心问题
2.1 表设计 订单、明细、状态字段如何分层
2.2 状态机 十种状态之间的合法转移
2.3 防重复下单 分布式锁与幂等键
2.4 分区表 按时间治理大表

表设计决定状态机长什么样，状态机决定并发防护的边界，三者环环相扣。说穿了，订单中心的代码量不大，难的是每一个决策都有依据：状态能不能逆向、库存该谁写、分区键选什么。这些决策做错一个，后面十篇文章都救不回来。如果你对分库分表的大表治理感兴趣，可以先翻 MySQL 分库分表实战 找个对照，再回来看我们单库分区的做法。

延伸阅读