幂等性设计

幂等性设计不能脱离业务来讨论，一般情况下，去重表同时也是业务数据表，而针对分布式的去重ID，可以参考以下几种方式：

• UUID
• Snowflake
• 数据库自增ID
• 业务本身的唯一约束
• 业务字段+时间戳拼接

1 全局唯一ID

如果使用全局唯一ID，就是根据业务的操作和内容生成一个全局ID，在执行操作前先根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。如果不存在则把全局ID，存储到存储系统中，比如数据库、Redis等。如果存在则表示该方法已经执行。

使用全局唯一ID是一个通用方案，可以支持插入、更新、删除业务操作。但是这个方案看起来很美但是实现起来比较麻烦，下面的方案适用于特定的场景，但是实现起来比较简单。

2 去重表

这种方法适用于在业务中有唯一标识的插入场景中，比如在以上的支付场景中，如果一个订单只会支付一次，所以订单ID可以作为唯一标识。这时，我们就可以建一张去重表，并且把唯一标识作为唯一索引，用以记录订单支付信息，在我们实现时，把创建支付单据和写入去去重表，放在一个事务中，如果重复创建，数据库会抛出唯一约束异常，操作就会回滚。这个方法其实也是用到唯一ID，与上面全局唯一ID不同的是，他是针对具体单个业务流程的，实现起来相对简单。

3 插入或更新

这种方法插入并且有唯一索引的情况，比如我们要关联商品品类，其中商品的ID和品类的ID可以构成唯一索引，并且在数据表中也增加了唯一索引。这时就可以使用InsertOrUpdate操作。在mysql数据库中如下：

insert into goods_category    
(goods_id,category_id,create_time,update_time) 
  values(#{goodsId},#{categoryId},now(),now()) 
on DUPLICATE KEY UPDATE update_time=now()

4 多版本控制

这种方法适合在更新的场景中，比如我们要更新商品的名字，这时我们就可以在更新的接口中增加一个版本号，来做幂等：

boolean updateGoodsName(int id,String newName,int version);

在实现时可以如下：

update goods set name=#{newName},version=#{version} where  
id=#{id} and version<${version}

5 悲观锁

　　select for update，整个执行过程中锁定该订单对应的记录。注意：这种在DB读大于写的情况下尽量少用。

6 状态机控制

这种方法适合在有状态机流转的情况下，比如就会订单的创建和付款，订单的付款肯定是在之前，这时我们可以通过在设计状态字段时，使用int类型，并且通过值类型的大小来做幂等，比如订单的创建为0，付款成功为100，付款失败为99。在做状态机更新时，我们就这可以这样控制：

update goods_order set status=#{status} where id=#{id} and   
status<#{status}

7 对外提供接口的api如何保证幂等 

　　如银联提供的付款接口：需要接入商户提交付款请求时附带：source来源，seq序列号。source+seq在数据库里面做唯一索引，防止多次付款，(并发时，只能处理一个请求)

以上就是保证接口幂等性的一些方法。