幂等性


 

幂等性的概念

对于同一操作发起的请求(一次或者多次请求),任意多次执行对资源本身产生的影响均与一次执行产生的影响相同,不会因为多次相同操作而产生副作用。

 

比如一个用户注册,点击“注册”,由于某些原因(比如服务器负载大),长时间转圈圈,你多次点击“注册”,这多次请求都是完全相同的,应该只插入一条用户记录,而不是点多次“注册”每次都插入一条用户记录。

比如下单购买,点击“提交”,卡住了,什么破手机|网络,疯狂点“提交”,这多次请求完全相同,应该只产生一个订单,而不是每次点击都产生一个订单。

 

 

http请求方式(restful)

在其他条件不变的情况下(资源没有被其它操作修改):

  • get  查询,相同的查询操作,比如select username where id=1  from tb_user;执行多次,查询到的结果都是相同的,get是幂等的
  • post  插入,相同的插入操作,比如insert into tb_order (...) values (...);  执行多次,虽然可能会因为主键已存在、某个字段的值要唯一等原因插入失败,但每次都会尝试插入一条新纪录,如果满足约束,每次都会插入一条记录,结果可能不同(产生了新纪录),post不是幂等的
  • put  更新,相同的更新操作,比如update tb_user username='chy',age=20 where id=1;  不管执行多少次,id=1的这条记录,name都是chy,age都是20,结果都是相同的,put是幂等的
  • delete  删除,相同的删除操作,比如delete from tb_user where id=1 ,不管执行多少次,结果都是删除了id=1的记录,结果相同,delete是幂等的

 

 

消息消费者与幂等性

消息可能会被重复投递、消费,比如第一次投递的消息还在queue中,为确保消息投递的可靠性,延时又投递了一次消息,消费者应确保同一消息只进行一次消费。

 

 


 

 

 

幂等常见的实现方式

核心思想:

使用唯一的业务单号来标识一个业务,如果业务单号相同,就认为是同一笔业务,只执行一次。(去掉重复的业务)

存储执行过的业务的业务单号,先根据业务单号查询这笔业务是否已经执行过了,如果没执行过,才执行。

如果系统是单线程的,查询单号、执行这笔业务2个过程都不用加锁;如果过多个线程并发访问执行过的业务单号(有读有写),就需要给执行过的业务单号加锁(幂等是查询时加锁),执行过程往往也需要给共享数据加锁。

 

业务单号可以用流水号,也可以唯一id+指纹码,总之要能唯一标识一笔业务。

比如order的id,只用id是可以唯一标识一个订单,但不能标识是这个order的增改删查哪个业务,也不能标识是这个order的第几次修改操作。需要再加一个指纹码,比如时间戳、业务规则什么的。

 

 

1、数据库主键去重

单独用一张tb_order_ handled来存储执行过的订单的业务单号,使用列no存储业务单号(主键、unique约束),外键order_id关联order表的id,

执行业务时先select count(*) from tb_order_handled where no=xxx; 根据业务单号查询这笔业务是否已执行,数量为1表示有这条记录,这笔业务已处理过,不再处理;为0表示没处理过,就处理这笔业务。

这种方式的缺点是增加了数据库IO次数,数据库性能很容易成为系统性能的瓶颈,往往需要分库分表把业务单号所在的表拆分出来,来提升数据库性能。

 

 如果这个服务只有数据库更新操作的话,也可以使用数据库的乐观锁(版本号机制)。

 

 

2、分布式锁(推荐)

把处理过的业务单号作为键值对的key,存储在redis上,处理业务时先查询redis上有没有这个key,有就说明处理过了,不再处理,没有就说明这笔业务没有处理过,开始处理。

简单、且性能高,推荐。

 

 

3、缓冲区

把一段时间内要处理的业务都放到缓冲区中,先去掉重复的业务,再执行。

缺点:处理有时延、不能马上返回处理结果。不太常用。

 


作者:chenhongyong,发布于:2020/03/26
原文:https://www.cnblogs.com/chy18883701161/p/12561765.html