微服务接口的幂等性设计

概念

幂等性, Idempotence, 这个词来源自数学领域, 百科 上一元运算的幂等性解释如下： > 设 f 为一由 {x} 映射至 {x} 的一元运算, 则 f 为幂等的, 当对于所有在 {x} 内的 x: > f(f(x)) = f(x) > 特别的是，恒等函数一定是幂等的，且任一常数函数也都是幂等的。

幂等性衍生到软件工程中, 它的语义是指: 函数/接口可以使用相同的参数重复执行, 不应该影响系统状态, 也不会对系统造成改变 .

 

在我们实际中，在微服务架构的时候，我们在完成一个支付订单常常会遇到下面的场景: 1.在预下单创建订单,第一次调用超时(timeout),然后重试了一次 2.在订单创建时，我们需要去扣减库存，这时接口发生了超时，调用方重试了一次 3.一个订单状态更新接口，调用方连续发送了两个消息，一个是已创建，一个是已付款。但是你先接收到已付款，然后又接收到了已创建 4.在支付完成订单之后，需要发送一条短信，当一台机器接收到短信发送的消息之后，处理较慢。消息中间件又把消息投递给另外一台机器处理 以上的问题，就是在单体架构转成微服务架构之后，带来的问题,并不是说单体架构没有这个，而是单体架构下同样也要防止重复提交。但是出现的问题相当小。 为了解决以上的问题,我们就需要保证设计的接口幂等性。幂等的接口实际上就是接口可以重复调用,每次接口调用的结果都是一样的。

全局唯一ID

如果使用全局唯一ID，就是根据业务的操作和内容生成一个全局ID，在执行操作前先根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。如果不存在则把全局ID，存储到存储系统中，比如数据库、Redis等。如果存在则表示该方法已经执行。 从工程的角度来说，使用全局ID做幂等可以作为一个业务的基础的微服务存在，在很多的微服务中都会用到这样的服务，在每个微服务中都完成这样的功能，会存在工作量重复。另外打造一个高可靠的幂等服务还需要考虑很多问题，比如一台机器虽然把全局ID先写入了存储，但是在写入之后挂了，这就需要引入全局ID的超时机制。 使用全局唯一ID是一个通用方案，可以支持插入、更新、删除业务操作。但是这个方案看起来很美但是实现起来比较麻烦，下面的方案适用于特定的场景，但是实现起来比较简单。

去重表

这种方法适用于在业务中有唯一标的插入场景中，比如在以上的支付场景中，如果一个订单只会支付一次，所以订单ID可以作为唯一标识。这时，我们就可以建一张去重表，并且把唯一标识作为唯一索引，在我们实现时，把创建支付单据和写入去去重表，放在一个事务中，如果重复创建，数据库会抛出唯一约束异常，操作就会回滚。

插入或更新

这种方法插入并且有唯一索引的情况，比如我们要关联商品品类，其中商品的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()

多版本控制

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

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

在实现时可以如下

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