-
订单创建接口，第一次调用超时了，然后调用方重试了一次。是否会多创建一笔订单？
-
订单创建时，我们需要去扣减库存，这时接口发生了超时，调用方重试了一次。是否会多扣一次库存？
-
当这笔订单开始支付，在支付请求发出之后，在服务端发生了扣钱操作，接口响应超时了，调用方重试了一次。是否会多扣一次钱？
因为系统超时，而调用方重试一下，会给我们的系统带来不一致的副作用。
在这种情况下，一般有两种处理方式。
-
一种是需要下游系统提供相应的查询接口。上游系统在 timeout 后去查询一下。如果查到了，就表明已经做了，成功了就不用做了，失败了就走失败流程。
-
另一种是通过幂等性的方式。也就是说，把这个查询操作交给下游系统，我上游系统只管重试，下游系统保证一次和多次的请求结果是一样的。
对于第一种方式，需要对方提供一个查询接口来做配合。而第二种方式则需要下游的系统提供支持幂等性的交易接口。
<>场景
将林志玲账户的余额加 100 元
<>方法一(推荐使用)： 令牌机制（全局ID） （记录并检查操作）
在发送消息时,给每条消息指定一个全局唯一的ID,消费时,先根据这个ID检查这条消息是否有被消费过,如果没有消费过更新数据,然后将消费状态置为已消费。
-
服务器端派发token并将token记录在缓存中, 客户端携带此token请求服务, 如果此token有效证明是有效请求处理请求, 并删除token。token无效忽略此请求。
-
客户端请求携带一个唯一标识(流水号),服务器判断此唯一标识是否已经存在,如果已存在忽略此请求。
<>方法二：利用数据库的唯一约束实现幂等（利用数据库实现幂等性）
我们在数据库中建一张转账流水表，这个表有三个字段：转账单 ID、账户 ID 和变更金额，然后给转账单 ID 和账户 ID 这两个字段联合起来创建一个唯一约束，这样对于相同的转账单 ID 和账户 ID，表里至多只能存在一条记录。
<>方法三：为更新的数据设置前置条件（将方法实现幂等）
-
方法入参传入林志玲的账户余额，拿参数中的余额与数据库中的余额做比较如果相同则执行变更操作。
-
最简单的做法给数据增加一个版本号属性，每次更改数据前，比较当前数据的版本号是否和消息中的版本一致，如果不一致就拒绝更新数据，更新数据的同时将版本号 1。（和乐观锁原理一样）
实现幂等的核心是判断请求是否重复,具体实现方式比较多,想设计一个高可用的幂等方法还需要我们具体业务具体分析具体设计。
小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
最后
终极手撕架构师的学习笔记：分布式+微服务+开源框架+性能优化
91)]
最后
终极手撕架构师的学习笔记：分布式+微服务+开源框架+性能优化
[外链图片转存中...(img-mFAc4CLq-1710418164991)]