架构思想之-不一样的幂等设计

什么是幂等？

简单一句话说，就是相同的请求，任何时刻，任何地点，任何次数。效果都是一样。
举例：订单支付接口，假设用户点击了两次，针对同一个订单，发了两次订单支付请求。我们就得保证订单支付接口幂等。只能保证一个请求生效，最终效果还是只付款了一笔订单。

为什么要保证幂等？

1. 现在的微服务架构，由于网络分区。服务于服务之间不是在同机上。肯定存在网络问题，导致偶尔请求不同，那上游系统必定要重试
2. 现在很多场景都用到消息中间件。大部分消息中间件都有重试机制，主要保证消息100%可达
3. 等等其他场景。

上面这些场景，基本都是为了保证请求100% 或者 99% 可达。以冗余重试机制来保证。
那么有些写请求，也可能被重试。那么数据就可能被多次写入。导致商品超卖等等现象。

抛开问题看本质，解决幂等最关键是啥？

解决幂等有很多方法，这里说一种比较常用的利用分布式锁来实现。

其实我们看看这个问题的本质：其实我们只要把请求重试请求串行化+前置校验。不就可以了么？

加锁
{
	1、执行业务逻辑前判断，这条请求是否被处理过，如果处理过 直接return
	2、如果没有被处理过则继续执行
		logic。。。。。。。。
	3、标记该请求已处理过
}
解锁

串行化：主要是保证相同请求只允许放进来一个来处理业务逻辑
前置校验：放进来的请求，判断当次请求是否有效了。

串行化实现方式：通过分布式锁来实现。再此不去展开说，参见我下篇博客
前置校验实现方式：这里要结合业务来实现，例如我们就以订单支付接口为例

加锁
{
	1、根据订单id判断订单状态是否已支付
	2、如果订单未支付开始下面逻辑
		logic。。。。。。。。
	3、支付完成将订单状态修改为已支付
}
解锁

通过这个小例子希望大家能理解利用分布式锁，来实现幂等的思想。结合自己的业务去实现。
理解这类问题背后的根源问题。才能设计出更好的解决方案。