架构体系-黑马学习2：-业务幂等性技术架构体系(1)

news2024/11/25 12:39:17

25min

以下涉及到的都是一人操作时候，多次点击造成的并发，对幂等性问题的影响。

大多适用场景，都是单表。没有兼顾数据库分库分表分区场景。

幂等性定义：无论对某一个资源操作了多少次，其影响都应该是相同的。换句话说，在接口重复调用的情况下，对系统产生的影响是一样的，但是返回值允许不同，如查询。

1）幂等性的概念

幂等性不仅仅只是一次或者多次操作对资源没有产生影响，也包含第一次操作产生影响后，以后多次操作不会再产生影响。并且幂等性关注的是是否对资源产生影响，而不关注结果。

2）接口幂等性方案-----------------------------

在增删改查中，一般是增会产生幂等性问题，需要去规避。

前端，防止幂等性的做法总结：

防止重复提交，加遮罩；防止刷新页面或者前进后退导致页面重复提交，利用重定向成功后转向一个成功提交页面

后端方案：token机制

给客户端一个token，两种细节方案：1.redis存token，客户操作时候验证redis是否有token，有的话操作业务然后删除redis中的token，但是对两个操作需要加锁，防止错误；2.借助redis单线程和incr的原子性，这次redis中存储以token为key的键值对，对值自增，第一次获取token，值是1，第二次操作业务的时候，如果返回值只能是2的时候，允许操作业务。另外一种有问题的场景需要避免，是可能执行业务的时候超时或者异常，于是采用的是先删除token，再执行业务，业务有问题，客户重新去获取token执行新的操作。

缺点：多次交互，执行一次业务操作，需要多次交互，资源浪费大；单线程并发量有限，但是能满足大多数性能要求了

思考：这种幂等性的代码，遍布在每个功能中，导致代码重复度很高，有没有一劳永逸的办法？

55min

怎么不用token，也能达成效果，降低浪费？

1h03min

提取公共的业务：拦截器，认证token，并且删除token

3）服务幂等性方案-----------------------------

1.防重表，（多建立一张表，对一个字段或者多字段建立唯一索引）只适用于数据新增的情况，缺点：不适用于分库分表的场景

2.select+insert操作，mysql乐观锁应对比较简单的方式，（搜索到了，提示重复；搜索不到，进行业务操作；数据库必须设置唯一索引,利用了乐观锁思想，查询默认没有被修改，修改时候利用数据库表的行锁机制）缺点：只适合并发量不高的操作。

注意：更多的是防止个人调用的时候多次点击，

注意：数据库必须设置唯一索引，只适用于单表；分库分表分区后不再适用。

锁失效：方法上syconizeded 和@transtaction 一起使用出现失效

transaction操作的是方法对象的代理对象。锁锁住的是方法本身。导致两个操作的不是同一个对象

解决办法：

乐观锁的定义

重点：读的时候，认为无人修改；改的的时候，锁住表

悲观锁：读的时候，也会锁住表。

乐观锁的使用，适用于修改场景，如库存减少的并发场景

版本号控制方式也只使用修改，不好使用添加，因为添加的版本每次是0；版本号不需要自增，版本号达不到控制的效果了。

高并发下的减库存（update）出现幂等性问题，数据不一致，怎么解决？

syconnizsed 加在方法上，不行，会失效。原因：当前synchonized会和方法上的注解Tranaction有不统一， Transaction会有代理类，代理对象，而synchronized锁定的是当前方法对象，所以两个操作了不同的对象，synchronized失效.

解决方法：

1.表字段加version。前端传递过来参数version是确定的，比如0，事务执行完毕以后version变成1，并发执行的的请求带的是0，在dao层，update table where version =#{version}都不符合了。优点缺点：控制了多并发情况下只能有一个成功的场景，拍卖；减库存，库存量不止一个的情况。

2.减库存，更合适的方案,不发生超卖就是合适的：在dao层，update table set amount = amount - #{num} where amount - #{num}>=0

总结：乐观锁保证并发问题，只适用于修改场景，不适用于新增场景