使用分布式锁解决多次回调问题

问题

系统有一个支付回调接口,偶尔出现了秒级内回调2次的情况。我们在回调接口中写了推送任务。结果就是2次重复推送。伪代码如下:

1. 获得订单
2. 更改信息和状态(已支付)
3. 通知,推送,定时任务

在接口加入状态判断仍然有2次推送的情况出现。也就是说2个线程出现了并发的情况。这个时候就要使用到分布式锁来限制程序的并发执行。

1. 获得订单
x. 如果订单状态为已支付,则抛异常或直接return
2. 更改信息和状态(已支付)
3. 通知,推送,定时任务

分布式锁

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。在分布式系统中,常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源,那么访问这些资源的时候,往往需要互斥来防止彼此干扰来保证一致性,在这种情况下,便需要使用到分布式锁。

分布式系统中,常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源,那么访问这些资源的时候,往往需要互斥来防止彼此干扰来保证一致性,这个时候,便需要使用到分布式锁。

首先,为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件:

  • 互斥性。在任意时刻,只有一个客户端能持有锁。
  • 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁。
  • 具有容错性。只要大部分的Redis节点正常运行,客户端就可以加锁和解锁。
  • 解铃还须系铃人。加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了。

Redis实现分布式锁

@Slf4j
public class RedisLock {

    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";
    private static final Long RELEASE_SUCCESS = 1L;


    /**
     * 尝试获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @param expireTime 超期时间
     * @return 是否获取成功
     */
    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
//        log.info("lock -> {} lockKey -> {} request -> {}" ,result, lockKey, requestId);
        return LOCK_SUCCESS.equals(result);

    }


    /**
     * 释放分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @return 是否释放成功
     */
    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {

        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));
        return RELEASE_SUCCESS.equals(result);

    }
}

简单的测试,controller省略

public void updateStatus(String id) throws Exception {
        Jedis jedis = jedisPool.getResource();
        String requestId = SerialGenerator.randomUUID();
        boolean isGetLock = RedisLock.tryGetDistributedLock(jedis, "onPaySuccess" + id, requestId , 5);
        if (isGetLock) {
            Optional<MerchantOrder> byId = merchantOrderRepository.findById(id);
            MerchantOrder order = byId.get();
            if (order.getStatus() == OrderStatus.PAID) {
                throw new  BaseException("重复消费");
            }
            order.setStatus(OrderStatus.PAID);
            merchantOrderRepository.save(order);
        }
        RedisLock.releaseDistributedLock(jedis, "onPaySuccess" + id,requestId);
    }

JMeter测试

分别 启用10个和100个线程对接口进行测试。从log可以看出只有一个线程的log打印出了sql语句,后面的都显示重复消费。

额外的单机非集群思路

  • 只要在update t set state =1 where state=0时接受下row
  • 如果row=0,再查一次幂等返回
  • 毕竟前置已经查过了,更新时碰撞概率太低

碰到问题,解决问题,仅做记录。如有问题,欢迎指教。

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • 引题 比如在同一个节点上,两个线程并发的操作A的账户,都是取钱,如果不加锁,A的账户可能会出现负数,正确的方式是对...
    阿康8182阅读 4,851评论 0 75
  • 锁 分布式锁 distributed locks 资源有限,争抢难免,最简单粗暴的办法是谁的拳头大谁就可以抢到最好...
    曲水流觞TechRill阅读 11,564评论 9 43
  • 伴随着一声突如其来的开门声。 女子扬起脸惊喜的问到“你回来了吗?”,满脸的欣喜,眸子里全是甜蜜。 ...
    林小澜阅读 208评论 0 0
  • 新鲜的东西太诱惑人,当时有多沉醉,后来就可能有多残忍。 高杨是互联网时代下典型的富二代和创二代,所以他可以在大浪淘...
    回聲echo阅读 345评论 0 0
  • 其实,在写这篇文章之前,我特意去看了一下去年今天写的文章,每年的这一天,大家都会跟这一年挥手说告别,迎接崭新的一年...
    筱静的幸福生活阅读 346评论 0 0