- 主题:如何避免同一个请求被调用多次？
今天面试的时候，人家问到。
我说放个Redis，进API调用的时候去看看Key、value在不在，在的话直接丢弃。
面试官说，可以用Queue，不过Queue也不能完全保证唯一性。
专家们你们意下如何？
--
FROM 120.244.234.*
赞
【 在 hothail 的大作中提到: 】
: 可以，都可以，
: 这题目只提了要求“阻止请求”
: redis挺好的，还带单线程操作，也有点queue的意思啊
: ...................
--
FROM 120.244.234.*
今天看了密等性的一个文章
说的就是这个事情
你可以搜搜
【 在 licy 的大作中提到: 】
: 为啥要避免，重试按重试的规则处理一遍也行啊
:
--
FROM 120.244.234.*
你说的挺有道理的，但是有个疑问：
幂等性是相对于调用端而言的还是对双方而言的呢？
比如：客户端POST一个payment过去，得到消息“调用成功，payment已创建”。
因为客户端网络抖动，这个POST被发了10次，每次都得到消息“调用成功，payment已创建”。
这时候，这个调用是幂等的吗？
同样的场景，在服务器端看，会有两个结果：
1. 如果加入了去重机制，那只会有一个payment在服务器端创建（理想情况）。第一次创建，后面直接返回。
这种情况下，在服务器端看是幂等的吗？
2. 没有加入去重机制，这时候有10个payment被创建。
这种情况下，在服务器端看是幂等的吗？每次都创建了。
【 在 licy 的大作中提到: 】
: 幂等性说的是同样的请求应该得到同样的结果。
: 比如你支付一个订单，发了一个请求，返回订单成功，那么，如果这个请求由于某种原因再次重试的话，应该得到的是相同的结果，即支付成功。这样调用方和被调用方结果就一致了。
: 这个是幂等性，而不是返回一个“该请求过，不能重试”，要是这样的话，调用方和被调用方状态就永远不能一致了。
: ...................
--
FROM 120.244.234.*
我研究下你说的这个
谢谢！
【 在 Xjt 的大作中提到: 】
: 每次调用都需要用加了nonce的signature鉴权，每次的签名都不能重复。这样第二次调用的时候虽然签名是相同的，会被API gateway拦住。
: 至于API gateway如何实现每个签名只能被请求一次，redis就是很好的方案吧。
: 反而面试官说的Queue，比如Kafka，需要做到exactly once，可麻烦了。。。
--
FROM 223.104.41.*
多谢解释
这里用payment做例子不是很合适
因为post去创建payment，每次应该返回新payment id
【 在 appletree 的大作中提到: 】
: 幂等性是对双方而言的。
: 对于客户端，幂等性的请求不管发送多少次，都会得到相同的返回结果。
: 对于服务端，处理多次重复的请求之后的状态，应该与只处理一次请求的状态保持一致。
: ...................
--
FROM 120.244.234.*
总觉得gpt3.5只适合写常见的程序。
其他很多的事情，问它也是白问
【 在 dpblue 的大作中提到: 】
: ChatGPT是这么回答的：
: 可以通过以下方法来避免同一个请求被调用多次：
: 1.使用HTTP缓存：客户端可以使用HTTP头中的缓存控制标头来请求服务器在一段时间内缓存响应。服务器在接收到第一次请求时，将响应存储在缓存中，并在下一次相同请求时返回缓存的响应。这样可以减少服务器的负载和提高响应速度。
: ...................
--
FROM 120.244.234.*
赞
【 在 herowzz 的大作中提到: 】
: 这个其实就是接口幂等性问题，关键是如何识别幂等，也就是说如何识别出这两个请求确实是同一个，还是不同请求
: 识别出幂等后唯一性标识，至于用redis还是map，其实都是唯一性识别方法，当然也有开源的比如resubmit拿来即用
: 至于面试官说的queue有点搞笑，队列只是解决高并发问题，队列内部唯一性识别还得用kv
--
FROM 223.104.41.*
是相同请求被重复发的限制
【 在 nikezhang 的大作中提到: 】
: 是类似API调用次数限制的那种吗？
--
FROM 120.244.234.*
做外包去了……
【 在 laserxhp 的大作中提到: 】
: lz拿到offer了没
: 发自「今日水木 on iPhone XR」
--
FROM 223.104.41.*