返回

幂等性问题以及解决方案

发布时间:2023-02-18 14:51:14 295
# 前端# 服务器# 数据# 脚本# 工具

幂等性问题以及解决方案_redis

概述

如今很多的服务都会基于分布式或微服务思想完成对系统的架构设计。那么在一个系统就会存在若干个微服务,而且服务间也会产生通信从而相互调用。那么既然产生了服务调用,就会存在服务调用延迟或失败的问题。当出现这种问题,服务端会进行重试等操作或客户端有可能会进行多次点击提交。如果这样请求多次的话,那最终处理的数据结果就一定要保证统一,如支付场景。此时就需要通过保证业务幂等性方案来完成。

什么是幂等

幂等本身是一个数学概念。即 f(n) = 1n ,无论n为多少,f(n)的值永远为1。在编程开发中,对于幂等的定义为:无论对某一个资源操作了多少次,其影响都应是相同的。 换句话说就是:在接口重复调用的情况下,对系统产生的影响是一样的,但是返回值允许不同,如查询。 幂等性不仅仅只是一次或多次操作对资源没有产生影响,还包括第一次操作产生影响后,以后多次操作不会再产生影响。并且幂等关注的是是否对资源产生影响,而不关注结果

以sql为例

#此SQL无论执行多少次,虽然结果有可能出现不同,都不会对数据产生改变,具备幂等性。
select * from table where id=1

#此SQL如果id或name有唯一性约束,多次操作只允许插入一条记录,则具备幂等性。如果不是,则不具备幂等性,多次操作会产生多条数据。
insert into table(id,name) values(1,'heima')

#此SQL无论执行多少次,对数据产生的影响都是相同的。具备幂等性。
update table set score=100 where id = 1

#此SQL涉及到了计算,每次操作对数据都会产生影响。不具备幂等性。
update table set score=50+score where id = 1

#此SQL多次操作,产生的结果相同,具备幂等性
delete from table where id = 1
复制代码

幂等性设计主要从两个维度进行考虑:​​空间​​、​​时间​​。 空间:定义了幂等的范围,如生成订单的话,不允许出现重复下单。 时间:定义幂等的有效期。有些业务需要永久性保证幂等,如下单、支付等。而部分业务只要保证一段时间幂等即可。 同时对于幂等的使用一般都会伴随着出现锁的概念,用于解决并发安全问题。

接口幂等

解决方案

对于幂等的考虑,主要解决两点​​前后端交互​​和​​服务间交互​​。这两点有时都要考虑幂等性的实现。从前端的思路解决的话,主要有三种:前端防重、PRG模式、Token机制

前端防重

通过前端防重保证幂等是最简单的实现方式,前端相关属性和JS代码即可完成设置。可靠性并不好,有经验的人员可以通过工具跳过页面仍能重复提交。主要适用于表单重复提交或按钮重复点击。

PRG模式

PRG模式即POST-REDIRECT-GET。当用户进行表单提交时,会重定向到另外一个提交成功页面,而不是停留在原先的表单页面。这样就避免了用户刷新导致重复提交。同时防止了通过浏览器按钮前进/后退导致表单重复提交。 是一种比较常见的前端防重策略。

token机制

方案介绍 通过token机制来保证幂等是一种非常常见的解决方案,同时也适合绝大部分场景。该方案需要前后端进行一定程度的交互来完成。

幂等性问题以及解决方案_redis_02

  • 服务端提供获取token接口,供客户端进行使用。服务端生成token后,如果当前为分布式架构,将token存放于redis中,如果是单体架构,可以保存在jvm缓存中。
  • 当客户端获取到token后,会携带着token发起请求。
  • 服务端接收到客户端请求后,首先会判断该token在redis中是否存在。如果存在,则完成进行业务处理,业务处理完成后,再删除token。如果不存在,代表当前请求是重复请求,直接向客户端返回对应标识。

思考

但是现在有一个问题,当前是先执行业务再删除token。在高并发下,很有可能出现第一次访问时token存在,完成具体业务操作。但在还没有删除token时,客户端又携带token发起请求,此时,因为token还存在,第二次请求也会验证通过,执行具体业务操作。

对于这个问题的解决方案的思想就是并行变串行。会造成一定性能损耗与吞吐量降低。 第一种方案:对于业务代码执行和删除token整体加线程锁。当后续线程再来访问时,则阻塞排队。 第二种方案:借助redis单线程和incr是原子性的特点。当第一次获取token时,以token作为key,对其进行自增。 然后将token进行返回,当客户端携带token访问执行业务代码时,对于判断token是否存在不用删除,而是对其继续incr。如果incr后的返回值为2。则是一个合法请求允许执行,如果是其他值,则代表是非法请求,直接返回。

那如果先删除token再执行业务呢?其实也会存在问题,假设具体业务代码执行超时或失败,没有向客户端返回明确结果,那客户端就很有可能会进行重试,但此时之前的token已经被删除了,则会被认为是重复请求,不再进行业务处理。

这种方案无需进行额外处理,一个token只能代表一次请求。一旦业务执行出现异常,则让客户端重新获取令牌,重新发起一次访问即可。推荐使用先删除token方案 但是无论先删token还是后删token,都会有一个相同的问题。每次业务请求都回产生一个额外的请求去获取token。但是,业务失败或超时,在生产环境下,一万个里最多也就十个左右会失败,那为了这十来个请求,让其他九千九百多个请求都产生额外请求,就有一些得不偿失了。虽然redis性能好,但是这也是一种资源的浪费。

服务幂等

防重表

对于防止数据重复提交,还有一种解决方案就是通过防重表实现。防重表的实现思路也非常简单。首先创建一张表 作为防重表,同时在该表中建立一个或多个字段的唯一索引作为防重字段,用于保证并发情况下,数据只有一条。 在向业务表中插入数据之前先向防重表插入,如果插入失败则表示是重复数据。

对于防重表的解决方案,可能有人会说为什么不使用悲观锁。悲观锁在使用的过程中也是会发生死锁的。悲观锁是 通过锁表的方式实现的。 假设现在一个用户A访问表A(锁住了表A),然后试图访问表B; 另一个用户B访问表 B(锁住了表B),然后试图访问表A。 这时对于用户A来说,由于表B已经被用户B锁住了,所以用户A必须等到用 户B释放表B才能访问。 同时对于用户B来说,由于表A已经被用户A锁住了,所以用户B必须等到用户A释放表A才 能访问。此时死锁就已经产生了。

Mysql乐观锁

MySQL乐观锁是基于数据库完成分布式锁的一种实现,实现的方式有两种:基于版本号基于条件。但是实现思 想都是基于MySQL的行锁思想来实现的。

幂等性问题以及解决方案_redis_03

通过版本号控制是一种非常常见的方式,适合于大多数场景。但现在库存扣减的场景来说,通过版本号控制就是多 人并发访问购买时,查询时显示可以购买,但最终只有一个人能成功,这也是不可以的。其实最终只要商品库存不 发生超卖就可以。那此时就可以通过条件来进行控制。

mysql乐观锁更适用于一些需要计数的表上,而且在竞争不激烈,出现并发冲突几率较小时,推荐使用乐观锁。虽 然通过MySQL乐观锁可以完成并发控制,但锁的操作是直接作用于数据库上,这样就会在一定程度上对数据库性能产生影响。并且mysql的连接数量是有限的,如果出现大量锁操作占用连接时,也会造成MySQL的性能瓶颈。

Zookeeper分布式锁

实现思想

对于分布式锁的实现,zookeeper天然携带的一些特性能够很完美的实现分布式锁。其内部主要是利用znode节点 特性和watch机制完成。

在zookeeper中节点会分为四类,分别是: 持久节点: 一旦创建,则永久存在于zookeeper中,除非手动删除。 持久有序节点: 一旦创建,则永久存在于zookeeper中,除非手动删除。同时每个节点都会默认存在节点序号,每个节点的序号都是有序递增的。如demo000001、demo000002.....demo00000N。 临时节点: 当节点创建后,一旦服务器重启或宕机,则被自动删除。 临时有序节点: 当节点创建后,一旦服务器重启或宕机,则被自动删除。同时每个节点都会默认存在节点序号,每个节点的序号都是有序递增的。如demo000001、demo000002.....demo00000N。

watch监听机制

watch监听机制主要用于监听节点状态变更,用于后续事件触发,假设当B节点监听A节点时,一旦A节点发生修 改、删除、子节点列表发生变更等事件,B节点则会收到A节点改变的通知,接着完成其他额外事情。

幂等性问题以及解决方案_幂等_04

实现原理

其实现思想是当某个线程要对方法加锁时,首先会在zookeeper中创建一个与当前方法对应的父节点,接着每个要 获取当前方法的锁的线程,都会在父节点下创建一个临时有序节点,因为节点序号是递增的,所以后续要获取锁的 线程在zookeeper中的序号也是逐次递增的。根据这个特性,当前序号最小的节点一定是首先要获取锁的线程,因 此可以规定序号最小的节点获得锁。所以,每个线程再要获取锁时,可以判断自己的节点序号是否是最小的,如果 是则获取到锁。当释放锁时,只需将自己的临时有序节点删除即可。

幂等性问题以及解决方案_幂等_05

在并发下,每个线程都会在对应方法节点下创建属于自己的临时节点,且每个节点都是临时且有序的。 那么zookeeper又是如何有序的将锁分配给不同线程呢? 这里就应用到了watch监听机制。每当添加一个新的临时 节点时,其都会基于watcher机制监听着它本身的前一个节点等待前一个节点的通知,当前一个节点删除时,就轮 到它来持有锁了。然后依次类推。

优缺点

  • zookeeper是基于cp模式,能够保证数据强一致性。
  • 基于watch机制实现锁释放的自动监听,锁操作性能较好。
  • 频繁创建节点,对于zk服务器压力较大,吞吐量没有redis强。

Redis分布式锁

分布式锁的一个很重要的特性就是互斥性,同一时间内多个调用方加锁竞争,只能有一个调用方加锁成功。而redis是基于单线程模型的,可以利用这个特性让调用方的请求排队,对于并发请求,只会有一个请求能获取到锁。 redis实现分布式锁也很简单,基于客户端的几个API就可以完成,主要涉及三个核心API: setNx():向redis中存key-value,只有当key不存在时才会设置成功,否则返回0。用于体现互斥性。 expire():设置key的过期时间,用于避免死锁出现。 delete():删除key,用于释放锁。

编写工具类实现加锁

通过jedis.set进行加锁,如果返回值是OK,代表加锁成功 如果加锁失败,则自旋不断尝试获取锁,同时在一定时间内如果仍没有获取到锁,则退出自旋,不再尝试获取锁。 requestId:用于标识当前每个线程自己持有的锁标记

public class SingleRedisLock {

JedisPool jedisPool = new JedisPool("192.168.200.128",6379);

//锁过期时间
protected long internalLockLeaseTime = 30000;

//获取锁的超时时间
private long timeout = 999999;

/**
* 加锁
* @param lockKey 锁键
* @param requestId 请求唯一标识
* @return
*/
SetParams setParams = SetParams.setParams().nx().px(internalLockLeaseTime);

public boolean tryLock(String lockKey, String requestId){

String threadName = Thread.currentThread().getName();

Jedis jedis = this.jedisPool.getResource();

Long start = System.currentTimeMillis();

try{
for (;;){
String lockResult = jedis.set(lockKey, requestId, setParams);
if ("OK".equals(lockResult)){
System.out.println(threadName+": 获取锁成功");
return true;
}
//否则循环等待,在timeout时间内仍未获取到锁,则获取失败
System.out.println(threadName+": 获取锁失败,等待中");
long l = System.currentTimeMillis() ‐ start;
if (l>=timeout) {
return false;
}
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}finally {
jedis.close();
}

}
}
复制代码

解锁时,要避免当前线程将别人的锁释放掉。假设线程A加锁成功,当过了一段时间线程A来解锁,但线程A的锁已 经过期了,在这个时间节点,线程B也来加锁,因为线程A的锁已经过期,所以线程B时可以加锁成功的。此时,就 会出现问题,线程A将线程B的锁给释放了。 对于这个问题,就需要使用到加锁时的requestId。当解锁时要判断当前锁键的value与传入的value是否相同,相 同的话,则代表是同一个人,可以解锁。否则不能解锁。 但是对于这个操作,有非常多的人,会先查询做对比,接着相同则删除。虽然思路是对的,但是忽略了一个问题, 原子性。判断与删除分成两步执行,则无法保证原子性,一样会出现问题。所以解锁时不仅要保证加锁和解锁是同 一个人还要保证解锁的原子性。因此结合lua脚本完成查询&删除操作。

/**
* 解锁
* @param lockKey 锁键
* @param requestId 请求唯一标识
* @return
*/
public boolean releaseLock(String lockKey,String requestId){

String threadName = Thread.currentThread().getName();
System.out.println(threadName+":释放锁");
Jedis jedis = this.jedisPool.getResource();

String lua =
"if redis.call('get',KEYS[1]) == ARGV[1] then" +
" return redis.call('del',KEYS[1]) " +
"else" +
" return 0 " +
"end";

try {
Object result = jedis.eval(lua, Collections.singletonList(lockKey),
Collections.singletonList(requestId));
if("1".equals(result.toString())){
return true;
}
return false;
}finally {
jedis.close();
}

}
复制代码

测试类

public class LoclTest {

public static void main(String[] args) {

//模拟多个5个客户端
for (int i=0;i<5;i++) {
Thread thread = new Thread(new LockRunnable());
thread.start();
}
}

private static class LockRunnable implements Runnable {
@Override
public void run() {

SingleRedisLock singleRedisLock = new SingleRedisLock();

String requestId = UUID.randomUUID().toString();
boolean lockResult = singleRedisLock.tryLock("lock", requestId);
if (lockResult){

try {
TimeUnit.SECONDS.sleep(5);
} catch (InterruptedException e) {
e.printStackTrace();
}
}

singleRedisLock.releaseLock("lock",requestId);
}
}
}
复制代码

此时可以发现,多线程会竞争同一把锁,且没有获取获取到锁的线程会自旋不断尝试去获取锁。每当一个线程将锁 释放后,则会有另外一个线程持有锁。依次类推。

存在的问题

锁续期

当对业务进行加锁时,锁的过期时间,绝对不能想当然的设置一个值。假设线程A在执行某个业务时加锁成功 并设置锁过期时间。但该业务执行时间过长,业务的执行时间超过了锁过期时间,那么在业务还没执行完 时,锁就自动释放了。接着后续线程就可以获取到锁,又来执行该业务。就会造成线程A还没执行完,后续线 程又来执行,导致同一个业务逻辑被重复执行。因此对于锁的超时时间,需要结合着业务执行时间来判断, 让锁的过期时间大于业务执行时间。 上面的方案是一个基础解决方案,但是仍然是有问题的。 业务执行时间的影响因素太多了,无法确定一个准确值,只能是一个估值。无法百分百保证业务执行期间, 锁只能被一个线程占有。 如想保证的话,可以在创建锁的同时创建一个守护线程,同时定义一个定时任务每隔一段时间去为未释放的 锁增加过期时间。当业务执行完,释放锁后,再关闭守护线程。 这种实现思想可以用来解决锁续期。

服务单点&集群问题

在单点redis虽然可以完成锁操作,可一旦redis服务节点挂掉了,则无法提供锁操作。 在生产环境下,为了保证redis高可用,会采用异步复制方法进行主从部署。当主节点写入数据成功,会异步的将 数据复制给从节点,并且当主节点宕机,从节点会被提升为主节点继续工作。假设主节点写入数据成功,在没有将 数据复制给从节点时,主节点宕机。则会造成提升为主节点的从节点中是没有锁信息的,其他线程则又可以继续加 锁,导致互斥失效

Redisson分布式锁

redisson是redis官网推荐实现分布式锁的一个第三方类库。其内部完成的功能非常强大,对各种锁都有实现,同 时对于使用者来说非常简单,让使用者能够将更多的关注点放在业务逻辑上。此处重点利用Redisson解决单机 Redis锁产生的两个问题。

单机Redisson实现

依赖

org.apache.commons
commons‐pool2



org.redisson
redisson‐spring‐boot‐starter
3.13.1

复制代码
配置文件
server:
redis:
host: 192.168.200.150
port: 6379
database: 0
jedis:
pool:
max‐active: 500
max‐idle: 1000
min‐idle: 4
复制代码

启动类

@Value("${spring.redis.host}")
private String host;

@Value("${spring.redis.port}")
private String port;

@Bean
public RedissonClient redissonClient(){
RedissonClient redissonClient;

Config config = new Config();
String url = "redis://" + host + ":" + port;
config.useSingleServer().setAddress(url);

try {
redissonClient = Redisson.create(config);
return redissonClient;
} catch (Exception e) {
e.printStackTrace();
return null;
}
}
复制代码

锁工具

@Component
public class RedissonLock {

@Autowired
private RedissonClient redissonClient;

/**
* 加锁
* @param lockKey
* @return
*/
public boolean addLock(String lockKey){

try {
if (redissonClient == null){
System.out.println("redisson client is null");
return false;
}

RLock lock = redissonClient.getLock(lockKey);

//设置锁超时时间为5秒,到期自动释放
lock.lock(5, TimeUnit.SECONDS);

System.out.println(Thread.currentThread().getName()+": 获取到锁");

//加锁成功
return true;
} catch (Exception e) {
e.printStackTrace();
return false;
}
}

public boolean releaseLock(String lockKey){

try{
if (redissonClient == null){
System.out.println("redisson client is null");
return false;
}

RLock lock = redissonClient.getLock(lockKey);
lock.unlock();
System.out.println(Thread.currentThread().getName()+": 释放锁");
return true;
}catch (Exception e){
e.printStackTrace();
return false;
}
}
}
复制代码

测试类

@SpringBootTest
@RunWith(SpringRunner.class)
public class RedissonLockTest {

@Autowired
private RedissonLock redissonLock;

@Test
public void easyLock(){
//模拟多个10个客户端
for (int i=0;i<10;i++) {
Thread thread = new Thread(new LockRunnable());
thread.start();
}

try {
System.in.read();
} catch (IOException e) {
e.printStackTrace();
}
}

private class LockRunnable implements Runnable {
@Override
public void run() {
redissonLock.addLock("demo");
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
redissonLock.releaseLock("demo");
}
}
}
复制代码

根据执行效果可知,多线程并发获取所时,当一个线程获取到锁,其他线程则获取不到,并且其内部会不断尝试获 取锁,当持有锁的线程将锁释放后,其他线程则会继续去竞争锁。

特别声明:以上内容(图片及文字)均为互联网收集或者用户上传发布,本站仅提供信息存储服务!如有侵权或有涉及法律问题请联系我们。
举报
评论区(0)
按点赞数排序
用户头像
精选文章
thumb 中国研究员首次曝光美国国安局顶级后门—“方程式组织”
thumb 俄乌线上战争,网络攻击弥漫着数字硝烟
thumb 从网络安全角度了解俄罗斯入侵乌克兰的相关事件时间线
下一篇
我终于会写 Java 的定时任务了! 2023-02-18 14:09:15