关于幂等介绍
@[TOC]标题
# 目录
## 二级目录
### 三级目录
什么是幂等?
定义:同一个数据操作,因为各种可能的失误或者系统异常,而导致不可避免的被执行了多次,但是其执行结果跟只操作一次得到的结果完全相同。
为什么要使用幂等?
在一个规范的大数据系统中,对一个业务模块的数据处理,一定会经过一条完整的数据处理链路,数据接入-数据源落地-数据计算-结果存储。我们更加关注的是数据的业务结果,是否能够做到真正的准确(幂等)。也就是最终结果既不能丢失,也不要重复。这个可以通过表设计和最终的结果写入程序优化来实现。而数据处理的中间各个环节,不可能也没有必要做到完全的严格幂等性。我们只需要在最大程度上保证数据不丢失就可以,至于数据是否重复发送和重复消费,没有必要过于关心,因为少许的过程数据重复,对于整个系统来说丝毫不受影响。对于一个大数据系统而言,实现幂等性是一个系统性工程,是一种架构设计思想,绝对不是单一的一个配置。
使用幂等的场景有哪些?
- 前端重复提交
用户在新增页面上快速点击多次,造成发了多次请求,后端重复保存了多条一模一样的数据。如用户提交订单,生成很多重复的订单。
- 消息重复消费
消息重复消费,一般指的是消息中间件,如RabbitMQ, 由于网络抖动,MQ Broker将消息发送给消费端消费,消费端进行了消费,在返回ack给MQ Broker时网络中断等原因,导致MQ Broker认为消费端没能正常消费消息,这时候MQ Broker会重复将这条消息发给消费端进行消费,如果没有做幂等,就会造成客户端重复消费同一条消息。
- 页面回退再次提交
举个例子,用户购买商品的时候,如果第一次点击下单按钮后,提示下单成功,跳转到下单成功页面,这时候如果用户点击浏览器返回按钮,返回上一个下单页面,重新点击下单按钮,这时候如果没有做幂等的话,也会造成重复下单的问题。
- 微服务互相调用
分布式系统中,服务之间的通信一般都通过RPC或者 Feign进行调用,难免网络会出小问题,导致此次请求失败,这时候这些远程调用,如feign都会触发重试机制,所以我们也需要保证接口幂等。
- 用户的重复提交或用户的恶意攻击后,后端收到好几次请求。
- 分布式系统中调用接口,有可能会因为网络原因而调用失败,一般在设计的时候会
对接口调用加上失败重试的机制。
幂等设计方案有哪些?
后端处理:
- select + insert+主键/唯一索引冲突
- 直接insert +主键/唯一索引冲突
- 状态机幂等
- 抽取防重表
- 幂等处理的八种方案
- token令牌:
首先客户端请求token接口,获取到token
服务端生成token并在redis中存一份
每次请求的时候,客户端将token带过来,由拦截器检验token
token存在redis中则说明是第一次请求, 完成数据处理,并删除redis中的token
第二次客户端再携带token时,去redis中查,如果redis中没有,那么说明是第二次请求了,返回重复操作提示。
- 悲观锁(如select for update)
- 乐观锁
- 分布式锁
如何进行测试?
可以通过压测,不断向服务器请求接口。
更多推荐
关于幂等介绍
发布评论