记录线上问题,事务和分布式锁之间发生的问题

本文探讨了在消费外部系统产品信息并入库时遇到的重复问题,通过分析发现是并发执行导致的。作者应用了加锁和事务控制,但在实际操作中事务未提交导致问题持续。最终揭示了问题原因并提出解决方案,包括在判断重复时加入事务锁确保一致性。
摘要由CSDN通过智能技术生成

1,背景

我们消费其他系统过来的产品信息,然后插入我们数据库使用,但是对方不知道什么原因总是会重复的发送一些产品,因此做了产品判重。但发现没有作用。
经过排查,发现对方会在几乎同时发送同样的产品信息过来。

2,问题1:

由于几乎同时执行,所以,当线程一进来进行插入,线程2也进来了,这时候线程1还没插入成功,线程2就判断是否存在,存在就不插入,不存在就插入,此时会插入成功。因为线程1还没插入成功。

解决方案:

在执行判断是否已经插入操作的方法上加锁,保证线程1插入成功后,线程2再进行判断:伪代码如下:

 @Transactional
    public Boolean test(Long id,String businessJsonString) {

        RLock lock_test = redissonClient.getLock("lock_test");
        lock_test.lock();
        try {
            //业务代码
            //根据id判断,保证不重复消费
            //插入数据库
            boolean isExist;
            if (true){
                //更新
            }else {
                //插入
            }

        } catch (Exception e) {
            //日志打印
        } finally {
            lock_test.unlock();
        }
        //..
        return true;
    }

此时感觉上面没问题了。

但是结果发现还是会出现重复的数据。经过查看代码发现,此方法有事务

也就是说,即使线程1执行插入成功了,解锁后,线程2进来进行判断重复还是会发现查询不到,会进行插入,导致重复。

问题的原因是事务导致,线程1插入了,但是事务还没提交,线程2进来依然查询不到。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

技术砖家--Felix

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值