标准答案
- 代码层适合修复线程安全、取消、资源释放和局部执行器问题。
- 数据库层适合唯一约束、条件更新、事务和版本裁决，尤其是最终事实在数据库时。
- 中间件层适合削峰、分区、顺序、重试和可恢复投递，但不替代业务状态和权限。
- 产品规则层必须明确重复提交、超时受理、库存预留和支付未知状态如何对用户承诺。
题目解析
定位并发问题时先找共享不变式和权威事实：是不能重复创建、不能超卖、状态不能倒退，还是资源不能被打满。代码、中间件和数据库可能都参与，但必须指定哪一层最终裁决。
代码层适合修复局部同步、取消和资源生命周期；数据库适合用约束、条件更新和事务裁决事实；中间件适合削峰、顺序和可恢复投递。任何一层都不能替产品规则决定“超时受理算不算成功”。
一个可靠方案要同时说清入口如何止血、最终写入如何保证、失败如何恢复以及如何对账。只描述某个组件的“成功配置”，无法证明跨层行为正确。
常见误区
- 误区：把所有并发问题交给分布式锁。改正：先判断唯一约束、状态机、条件更新或按 Key 队列能否直接表达不变式。
- 误区：把消息顺序当数据库事务。改正：消息只能帮助协调和投递，最终数据仍需事务、约束和幂等保护。
- 误区：业务规则未定义就承诺强一致。改正：先明确超时、重复、库存预留和支付未知状态的用户语义，再选择技术保证。