分布式系统实现幂等性的方式

本文探讨了接口设计中幂等性的实现方法,包括乐观锁、去重表、悲观锁、全局唯一ID及token机制,旨在确保多次相同请求的效果等同于一次请求。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

幂等性:接口的幂等性就是同样的数据,在实现方法的多次调用,得到的结果一致。对于查询接口,天然的保持幂等性,但是对于cud来说,如何保持幂等性。

看法:从以下方式来看,要保证幂等性,必须要有一个标识,至始至终的保持不变的标识,只有这样,后来的操作才可以依据这个标识判断是否曾经更改过,从而实现幂等性

方式1:使用乐观锁:

在系统设计的过程中,合理的使用乐观锁,通过version版本条件进行控制,来做乐观锁的判断条件,这样保证更新操作即使在并发的情况下,也不会有太大的问题。(对于不是该版本的数据,修改不成功)

方式2:添加去重表+状态

在针对该业务表的不同状态的操作时,可以建立去重表进行跟踪记录,根据业务表主键查询是否有去重表记录,并根据状态对业务表进行不同的业务操作。

通过重表记录业务表的唯一主键,进行cud时,查询是否操作过

方式3:悲观锁

select for update,整个执行过程中锁定该订单对应的记录。注意:这种在DB读大于写的情况下尽量少用,比较耗性能。

4. select + insert

并发不高的后台系统,或者一些任务JOB,为了支持幂等,支持重复执行,简单的处理方法是,先查询下一些关键数据,判断是否已经执行过,在进行业务处理,就可以了。注意:核心高并发流程不要用这种方法。

5.全局唯一ID

如果使用全局唯一ID,就是根据业务的操作和内容生成一个全局ID,在执行操作前先根据这个全局唯一ID是否存在,来判断这个操作是否已经执行。如果不存在则把全局ID,存储到存储系统中,比如数据库、redis等。如果存在则表示该方法已经执行。

6. token机制,防止页面重复提交

业务要求:页面的数据只能被点击提交一次

发生原因:由于重复点击或者网络重发,或者nginx重发等情况会导致数据被重复提交

数据提交前要向服务的申请token,token放到redis或jvm内存,token有效时间

提交后后台校验token,同时删除token,生成新的token返回

token特点:要申请,一次有效性,可以限流

 

参考原文:http://www.sohu.com/a/284541897_100028126

 

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值