- 主题:如何避免同一个请求被调用多次?
幂等性是对双方而言的。
对于客户端,幂等性的请求不管发送多少次,都会得到相同的返回结果。
对于服务端,处理多次重复的请求之后的状态,应该与只处理一次请求的状态保持一致。
所以你的例子要满足幂等性,从服务端的角度看,应该只有一个payment资源被创建。如
果每次都创建一个新的payment,那服务端是不满足幂等性要求的。
另外,幂等性所指的服务端的状态变化,并不包含服务端处理请求时所导致的一些副作用。比如服务端可能在每次处理重复请求的时候都会记录新的日志,但这并不违反幂等性。因为服务端记日志的目的通常只是为了从运维和监控角度出发,而不是从业务角度处理客户端的请求所必须要做的操作。因此可以不把新增加的日志视为服务端状态的变化。
【 在 chzhang7901 的大作中提到: 】
: 你说的挺有道理的,但是有个疑问:
: 幂等性是相对于调用端而言的还是对双方而言的呢?
: 比如:客户端POST一个payment过去,得到消息“调用成功,payment已创建”。
: ...................
--
FROM 111.199.216.*
ChatGPT是这么回答的:
可以通过以下方法来避免同一个请求被调用多次:
1.使用HTTP缓存:客户端可以使用HTTP头中的缓存控制标头来请求服务器在一段时间内缓存响应。服务器在接收到第一次请求时,将响应存储在缓存中,并在下一次相同请求时返回缓存的响应。这样可以减少服务器的负载和提高响应速度。
2.使用令牌(Token):令牌是一种在客户端和服务器之间传输的凭证,用于验证和授权客户端访问服务器资源。客户端可以在请求中携带令牌,服务器可以验证令牌并拒绝重复请求。
3.使用幂等性操作:幂等性操作是指无论操作被执行多少次,结果都是一样的操作。比如在PUT请求中更新资源的操作,如果多次执行,结果也只会更新一次。
4.使用防重放攻击的措施:防重放攻击是指攻击者试图使用已经被使用过的请求来伪造请求。客户端可以在每个请求中包含一个随机数,服务器可以验证请求是否是重复请求,如果是,则拒绝该请求。
--
FROM 175.36.143.*
多谢解释
这里用payment做例子不是很合适
因为post去创建payment,每次应该返回新payment id
【 在 appletree 的大作中提到: 】
: 幂等性是对双方而言的。
: 对于客户端,幂等性的请求不管发送多少次,都会得到相同的返回结果。
: 对于服务端,处理多次重复的请求之后的状态,应该与只处理一次请求的状态保持一致。
: ...................
--
FROM 120.244.234.*
总觉得gpt3.5只适合写常见的程序。
其他很多的事情,问它也是白问
【 在 dpblue 的大作中提到: 】
: ChatGPT是这么回答的:
: 可以通过以下方法来避免同一个请求被调用多次:
: 1.使用HTTP缓存:客户端可以使用HTTP头中的缓存控制标头来请求服务器在一段时间内缓存响应。服务器在接收到第一次请求时,将响应存储在缓存中,并在下一次相同请求时返回缓存的响应。这样可以减少服务器的负载和提高响应速度。
: ...................
--
FROM 120.244.234.*
这个其实就是接口幂等性问题,关键是如何识别幂等,也就是说如何识别出这两个请求确实是同一个,还是不同请求
识别出幂等后唯一性标识,至于用redis还是map,其实都是唯一性识别方法,当然也有开源的比如resubmit拿来即用
至于面试官说的queue有点搞笑,队列只是解决高并发问题,队列内部唯一性识别还得用kv
--
修改:herowzz FROM 111.203.85.*
FROM 111.203.85.*
幂等
mi
【 在 herowzz 的大作中提到: 】
: 这个其实就是接口冥等性问题,关键是如何识别冥等,也就是说如何识别出这两个请求确实是同一个,还是不同请求
: 识别出冥等后唯一性标识,至于用redis还是map,其实都是唯一性识别方法,当然也有开源的比如resubmit拿来即用
: 至于面试官说的queue有点搞笑,队列只是解决高并发问题,队列内部唯一性识别还得用kv
: ...................
--
FROM 222.70.23.*
我艹居然打错了,谢谢,错别字已改
【 在 oldwatch 的大作中提到: 】
: 幂等
: mi
--
FROM 111.203.85.*
赞
【 在 herowzz 的大作中提到: 】
: 这个其实就是接口幂等性问题,关键是如何识别幂等,也就是说如何识别出这两个请求确实是同一个,还是不同请求
: 识别出幂等后唯一性标识,至于用redis还是map,其实都是唯一性识别方法,当然也有开源的比如resubmit拿来即用
: 至于面试官说的queue有点搞笑,队列只是解决高并发问题,队列内部唯一性识别还得用kv
--
FROM 223.104.41.*
同意,用queue搞定幂等性,有点奇葩,用Redis感觉有些场景似乎不适用。
好久不搞交易类的系统了,手生了。
不过幂等确实很重要,最近听说一家的系统在订单处理上没解决好,重复收单了,还是过了一年多才发现账对不上,后面一堆破事儿,很恶心。
【 在 herowzz 的大作中提到: 】
: 这个其实就是接口幂等性问题,关键是如何识别幂等,也就是说如何识别出这两个请求确实是同一个,还是不同请求
: 识别出幂等后唯一性标识,至于用redis还是map,其实都是唯一性识别方法,当然也有开源的比如resubmit拿来即用
: 至于面试官说的queue有点搞笑,队列只是解决高并发问题,队列内部唯一性识别还得用kv
: ...................
--
FROM 219.236.233.*
是类似API调用次数限制的那种吗?
【 在 chzhang7901 (唯有不断前行) 的大作中提到: 】
: 今天面试的时候,人家问到。
:
: 我说放个Redis,进API调用的时候去看看Key、value在不在,在的话直接丢弃。
:
--
FROM 223.104.106.*