并发控制常用方案(开发策略)

分布式，并发场景下，一定需要唯一的，幂等的控制。

业务维度：

【业务唯一ID】即 上下游通过唯一的 业务维度+业务ID来实现幂等。该方案较为简单，设置数据库唯一索引即可。比如：上游赠送保险，需要 业务场景+业务ID，我们返回唯一的 ID，用于上下游对账。三方亦然。

“COLD_GIFT"+"123456",我们返回 123321；这样可以识别出唯一的账单。加上场景是为了提高灵活性，防止各渠道业务ID重复，如果拿表主键做业务ID

技术方案维度：

各种分布式锁，DB事务，状态机，mysql的各种锁

【重点】各种中间件，除了关系型数据库，都不算靠谱。因为一般不持久化，不支持ACID事务，分布式中间件多为分布式集群架构，分布式环境十分复杂，

所以个人建议尽可能使用"简单傻瓜"方案–数据库来做控制。一般不需要了解各种中间件的各种乱七八糟情况，简单实用。

但是事务场景不能覆盖跨服务调用，跨基础设计调用（比如事务中调用redis），甚至三方调用场景。所以还可能出现使用分布式锁的场景。

 

常用工具箱

前端：防重复提交，前端涉及资金流链路防重复提交，理论上所有场景都需要防重复提交

后端：

分布式锁(一般最常见的就是使用Redis 分布式锁)、

DB事务(使用事务来保证)、

MySQL乐观锁(DB层面控制，最稳)、

MySQL悲观锁、

MySQL唯一索引(只能执行一次的场景，唯一索引最稳)、

MySQL sql语句(不能使用唯一索引的场景，比如：给用户打款，失败了,可以重新打款。DB有三个状态，PAYING，SUCCESS，FAILD。插入时候，需要校验条件。insert into xxx not exist xxxx 。)、

单元测试(需要使用单元测试，多线程来进行并发测试)、

旁路比对(使用一个旁路，对比数据是否正常， 比如：job对比流水与账户是否一致)