支付微服务设计方案格式模板_何为幂等性？如何保证微服务接口的幂等性？讨论了2种设计方案。...

何为幂等性？

幂等性-指一次或多次请求某一个资源，具有同样的作用。如果使用公式表达，就是f(x)=f(f(x))。

在微服务系统中，为了保证数据的最终一致性，可以采用基于Spring-tryer优雅的重试方案。

基于Spring-tryer 优雅的重试方案(含源码)

还可以采用分布式事务模型，如Saga、TCC事务模型等等。

分布式事务-Saga事务模型和TCC事务模型

另外，基于可靠消息模式的补偿方案，也是不错的选择。

在分布式系统中，如何实现最终一致性？多种设计方案深入分析。

在基于消息队列的模式中，比如Kafka、RocketMQ等等，这些消息中间件，都采用了至少一次(At least once)的消息发送模式，以确保不丢失消息。

在这种情况下，提高了消息中间件的可靠性，但是这样会导致重复消费消息，因此需要消息消费服务提供幂等性接口。除了查询功能具有天然的幂等性之外，增加、更新、删除都要保证幂等性。那么如何来保证幂等性呢？

1. 全局唯一ID或幂等令牌(Idempotency Key)

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

如下是基于Redis 来实现幂等性的方案，在Redis 中，用令牌 Token 作为key，value有2个值：1 表示正在处理；2 表示已经处理完成。

(1)Client 发起请求时，需要携带令牌 Token；

(2)Server 在收到请求的时候，先去Redis 查询令牌。

如果查不到，则通过 SET 命令保存 Token，需要设置过期时间。

如果查询到的结果为1，则休眠一段时间重试。

如果查询到的结果为2，则返回成功。

2. 在数据库中实现幂等性

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

可能不一定所有数据表都有唯一约束索引，那怎么解决呢？

可以利用唯一键增加一张流水表，通过在流水表设置唯一约束索引，或者判重检查，也可以达到目标。