为啥要避免，重试按重试的规则处理一遍也行啊


【 在 chzhang7901 的大作中提到: 】
: 今天面试的时候，人家问到。
: 我说放个Redis，进API调用的时候去看看Key、value在不在，在的话直接丢弃。
: 面试官说，可以用Queue，不过Queue也不能完全保证唯一性。
: ...................
--
FROM 223.104.41.*

我做过支付，所以举了这样的例子

我再解释下场景：
在分布式的情况下，系统的之间的状态很容易不一致，因此，系统会出现自动的重试或者报文的补发，在这种情况下，为了系统间状态一致，需要小心的对每次请求做幂等处理

幂等处理的一大原则就是：某一次请求，如果已经处理过，那相同的请求重试的时候，返回的结果应该是一样的，不然的话，分布式系统之间的状态就不一致了。

所以，做幂等，第一重要的是这个请求要判断是否是已经处理过的请求，如果不是处理过的请求，那就该怎么处理就怎么处理。如果是已经处理过的请求（两次不同的支付不是同样的请求，要搞清楚），那么，就小心构造一个跟上次一样的处理结果给对方，这样的话，调用方和被调用方状态就一致了，这个很重要。


请仔细理解我说的话。

【 在 Mikov 的大作中提到: 】
: 标  题: Re: 如何避免同一个请求被调用多次？
: 发信站: 水木社区 (Wed May 31 13:34:02 2023), 站内
:
: 你没做过支付吧? 做过的就不会举这样的例子了
:
: 【 在 licy 的大作中提到: 】
: : 幂等性说的是同样的请求应该得到同样的结果。
: : 比如你支付一个订单，发了一个请求，返回订单成功，那么，如果这个请求由于某种原因再次重试的话，应该得到的是相同的结果，即支付成功。这样调用方和被调用方结果就一致了。
: : 这个是幂等性，而不是返回一个“该请求过，不能重试”，要是这样的话，调用方和被调用方状态就永远不能一致了。
: : ...................
:
: --
:
: ※ 来源:·水木社区 http://www.mysmth.net·[FROM: 220.181.41.*]
--
FROM 60.253.163.*

我从网搜上搜了一个幂等的含义：“对同一个系统，使用同样的条件，一次请求和重复的多次请求对系统资源的影响是一致的。”

广义的讲，这个系统资源的影响应该包含调用方和被调用方。

只不过很多系统设计采用不同策略来保证幂等，被调用方对同一请求只处理一次是一个简化的幂等版本。只保证了对自身的影响是一致的，没有考虑对调用方的影响。做的更好的情况下，应该保证返回值是一样的，这样才能保证分布式情况下资源状态是一致的。

所以题主的问题也一样，上来直接问的问题就是怎么保证不被重复处理，其实这个问题已经曲解了幂等的含义，不是要避免多次调用，是要保证多次调用对自己和对方产生的效果是一致的（对业务数据产生的效果一致，但是记录些技术日志之类的不影响幂等）。



【 在 Mikov 的大作中提到: 】
: 标  题: Re: 如何避免同一个请求被调用多次？
: 发信站: 水木社区 (Sun Jun  4 23:08:59 2023), 站内
:
: 你就说你是做商户还是做通道吧, 是接通道还是接两联
:
: 支付一个流程从下单发起, 到回调确认, 后面还有分账和退款, 哪一家也不敢跟你保证, 同样的请求给你同样的返回. 这中间七弯八拐的情况太多了.
:
: 幂等就一个定义: 对同一资源ID的多次请求只处理一次
:
: 至于返回结果要不要一样, 这是次要的, 各家有各家的定义.
:
: 幂等不是用"返回结果"这个东西来解释的, 不要误导.
:
:
:
: 【 在 licy 的大作中提到: 】
: : 我做过支付，所以举了这样的例子
: : 我再解释下场景：
: : 在分布式的情况下，系统的之间的状态很容易不一致，因此，系统会出现自动的重试或者报文的补发，在这种情况下，为了系统间状态一致，需要小心的对每次请求做幂等处理
: : ...................
:
: --
:
: ※ 来源:·水木社区 http://www.mysmth.net·[FROM: 115.47.107.*]
--
FROM 124.64.23.*