【高并发】- 幂等性设计你知道多少?
Cansluck
共 5241字,需浏览 11分钟
·
2023-05-05 22:25
1. 有关幂等性设计的场景 用户在电商平台购物,看到自己心仪的商品,于是将其加入购物车,之后进入购物车下单结算。这时,由于网络不通畅,用户在点击“提交订单”按钮时卡住了,用户以为没有提交成功,就又点击了一次“提交订单”按钮。最终,订单系统给该用户生成了两个订单,其实之前那个订单已经生成成功了。
这就是一个典型的幂等性问题。由于下单接口没有做好幂等性设计,所以导致用户进行了两次同样的下单操作,系统给用户创建了两个订单。
2. 什么是幂等性
所谓幂等性是指,用户对于同一个操作发起一次请求或者多次请求,得到的结果都是一样的,不会因为请求了多次而出现异常现象。
为了理解幂等性,下面来看一个非幂等的场景:
例如,在支付时,用户点击了两次“立即支付”按钮,发生了重复支付。最终,用户发现被扣了两次款,支付系统也生成了两条支付记录,这就是一个非幂等的场景。
2.1 需要幂等性的场景
幂等性主要用在重复请求上,有如下几种场景:
- 用户多次请求,比如重复点击页面上的按钮。
- 网络异常,由于网络原因导致在一定时间内未返回调用成功的信息,触发了框架层的重试机制。
- 页面回退后再次提交的动作。
- 程序上的重试机制:对于未及时响应的请求发起重试操作。
2.2 数据库操作的幂等性分析
数据库的上层业务操作分为CRUD(即新增、读取、更新、删除4个动作)。
-
新增(Create):如果自增主键唯一,则数据库会生成多条相同记录,不具备幂等性,如:
insert into(id, name, age, balance) values(1, 'test', 18, 100);
- 读取(Read):无论请求多少次,读取的结果都是一样的,所以读取是天然幂等的,如:
select name, age, balance from user where id = 1;
- 更新(Update):条件语句中带有计算的更新是非幂等的;反之,则是天然幂等的,如:
非幂等 update user set balance = balance + 100 where id = 1;
幂等 update user set balance = 200 where id = 1;
- 删除(DELETE):无论删除多少次,结果都是一样的,所以删除动作是天然幂等的,如:
delete from user where id = 1;
可以看出,读取和删除是天然幂等的,无论执行多少次请求,最终的结果都是一样的。从这里很容易联想到RESTful规范中的HTTP请求方法:POST(C)、GET(R)、PUT(U)、DELETE(D)。
- POST:相当于新增,不具备幂等性。
- GET:对资源的获取。在浏览器中通过地址进行访问,每次结果都是一样的,是天然幂等的。
- PUT;将一个资源替换成另一个资源。这是非计算型的更新,无论更新多少次,结果都是一样的,是天然幂等的。
- DELETE:同数据库的删除动作。无论删除多少次,结果都是一样的,是天然幂等的。
3. 如何避免重复提交 如果用户连续点击了两次“立即下单”按钮后,订单系统为用户生成了两个订单,这是不行的。这是重复请求所导致的。要防止重复提交订单(即请求多次和请求一次的最终效果是一样的),则需要订单系统在创建订单时具备幂等性。
3.1 利用全局唯一ID防止重复提交 在向数据库新增一条记录时,有时会出现错误信息“result in duplicate entry for key primary”,原因是插入了相同ID的信息。
利用数据库的主键唯一特性,可以解决重复提交的问题:对于相同Id的信息,数据库会抛出异常,这样新增数据的请求会失败。现在已经知道方案了,那么这个ID该如何和系统进行绑定呢?下面来看一下具体的落地流程。
(1)搭建一个生成全局唯一ID的服务。建议加入一些业务信息到该服务中,例如,在生成的订单ID中可以包含业务信息的订单元素(如“OD”20230201620005600001)。该全局唯一ID服务可以参考雪花算法SnowFlow进行搭建。 (2)在订单确定页面中,调用全局唯一ID服务生成订单号。 (3)在提交订单时带上订单号,请求到达订单系统的下单接口。
(4)将数据库订单表Id和订单号进行映射,将订单号作为订单表的ID。 (5)订单系统在创建订单信息时,订单号使用前端传过来的订单号,然后直接将该订单信息插入订单库中。 (6)如果订单写入成功,则是第一次提交,返回下单成功;如果报ID冲突信息,则是重复提交,在订单表中只保留之前的记录,不会写入相同的新记录。 (在报“订单重复提交”错误时,不要向客户端抛出错误信息,因为重复提交的订单不一定全部失败。如果给用户展示错误,则用户可能还会提交订单,这会使得用户体验不好。可以直接向用户展示下单成功)
(1)订单系统提供一个发放Token的接口。这个Token是一个防重令牌,即一串唯一字符串(可以使用UUID算法生成)。
(2)在“订单确认页”中调用获取Token的接口,该接口向订单确认页返回Token,同时将此Token写入Redis缓存中,并依据实际业务对其设置一定的有效期。
(3)用户在“订单确认页”中点击“提交订单”按钮时,将第(2)步获取的Token以参数或者请求头的形式封装进订单信息中,然后请求订单系统的下单接口。
(4)下单接口在收到提交下单的请求后,首先判断在Redis中是否存在当前传入的Token:
- 如果存在,则代表这是第一次请求,会删除这个Token,继续创建订单的其他业务。
- 如果不存在,则代表这不是第一次请求,而是重复的请求,会终止后面的业务操作。
所以,在应对并发修改场景下,对于Token的获取、比对和删除,需要使用原子操作。在Redis中可以用Lua脚本进行原子操作。
利用数据库的主键唯一特性和Token机制来避免重复提交,是一种比较常用的接口幂等性方案。对于重复提交的场景,需要依据业务进行分析,分析当前场景是否具备幂等性,如果不具有幂等性,则需要进行幂等性设计。
(幂等性设计方案远不止以上两种,例如,可以利用数据库的悲观锁和乐观锁,或者分布式场景下的分布式锁等,来防止重复提交)
4 如何避免更新中的ABA问题 前面讲到数据库更新时,如果是类似计算型的更新,则其是非幂等的;如果不是计算型的更新,则其实天然幂等的。因为,无论更新多少次,最终结果都是一样的。这种情况在大部分场景都是没有问题的,但是在高并发场景下,就有可能是非幂等的,从而造成数据的不一致。 场景: 用户在和商家讨价还价后,提交订单等待商家修改价格,商家在商品页上将订单价格从原来的100元,修改为80元。改完后,商家发现改错了,于是返回重新修改为90元,订单系统对于上架这两次的修改都执行成功了。 但是,由于网络异常原因,订单系统未及时将“前一次修改为80元成功的结果”返回给订单页,从而触发了重试逻辑,所以,商品价格在被修改为90元之后,又被修改为80元,即最终成交价格变成了80元,这就造成了数据的不一致,对商家也是一个损失。这是一个经典的ABA问题。 解决ABA问题一个常用的方案是:使用数据库的乐观锁来解决。即在订单系统的订单表中增加一个字段版本号(version),在每次更新时都判断两个版本号是否相等,如果不相等则不更新。具体流程如下: (1)在订单页获取修改订单时,同时将订单版本号作为订单属性一起返回给前端页面。 (2)在前端订单页修改订单时,将订单关键信息,如订单ID(orderId)、修改的价格(newPrice)及获取的版本号(version)等,一起传到订单修改接口中。 (3)订单系统的订单修改接口,在收到价格修改的请求后,首先判断当前传过来的版本号和数据库当前订单的版本号是否一致。如果不一致,则拒绝当前更新;如果一致,则更新当前数据,同时版本号加1。 “比较版本号”、“更新数据”、“对版本号加1”这几个动作都必须保证原子性,即要在一个事务内,SQL语句如下:
通过版本号可以保证从“订单在订单页被查询”到“成功更新这条数据”这期间内没有其他人能够修改这条数据。只要有人修改了这条数据,版本号就会增加。版本号增加了,当前更新拿到的就是旧版本号,会更新失败,需要重新发起查询请求以获取最新的版本号。update order set price = 80, version = version + 1
where order_id = 10001 and version = 1
加上版本号控制后,再来看一下是否保证了“订单并发修改”的数据一致性。
- 当商家修改价格为80元时,携带了版本号version = 0,订单系统匹配发现刚传的版本号与数据库中的版本号是一致的,所以更新价格为80元成功,同时将版本号加1.
- 当商家又将价格修改为90元时,刚传的version = 0,但当前订单的version = 1,所以当前价格更新失败。
- 商家看到更新失败的原因,就可以刷新当前页面,重新获取最新的版本号(version = 1),进行订单修改。
本章节总结了高并发系统中关于幂等性设计的场景及解决方案,小伙伴们可以根据自身业务进行取舍。设计出符合当前公司实际的幂等性设计。
![f97f3e48c6efdb03c3c07708109185f8.webp](https://filescdn.proginn.com/5f887bf7c8ca74dd88b6c24175440e24/f97f3e48c6efdb03c3c07708109185f8.webp)
点个在看你最好看
评论