<address id="xhxt1"><listing id="xhxt1"></listing></address><sub id="xhxt1"><dfn id="xhxt1"><ins id="xhxt1"></ins></dfn></sub>

    <thead id="xhxt1"><dfn id="xhxt1"><ins id="xhxt1"></ins></dfn></thead>

    解决方案:如何防止数据重复插入?

    摘要: 原创出处 https://www.bysocket.com 「公众号:泥瓦匠BYSocket 」欢迎关注和转载,保留摘要,谢谢!

    目录

    1. 为啥要解决数据重复插入?
    2. 解决方案实战
    3. 可落地小总结

    一、为啥要解决数据重复插入?

    问题起源,微信小程序抽风 wx.request() 重复请求服务器提交数据。后端服务也很简单,伪代码如下:

    class SignLogService {
        public void saveSignLog(SignLogDO log) {
            // 简单插入做记录
            SignLogDAO.insert(log);
        }
    }
    
    

    发现数据库会存在重复数据行,提交时间一模一样。但业务需求是不能有多余的 log 出现,这明显是个问题。

    问题是,重复请求导致的数据重复插入。这问题造成的后果很明显:

    • 数据冗余,可能不单单多一条
    • 有些业务需求不能有多余数据,造成服务问题

    问题如图所示:

    file

    解决方式:如何将 同请求 A,不执行插入,而是读取前一个请求插入的数据并返回。解决后流程应该如下:

    file

    二、解决方案实战

    1.单库单表解决方案

    • 唯一索引 + 唯一字段
    • 幂等

    上面说的那种业务场景:sign_log 表会有 user_id、sign_id、sign_time 等。那么每次签到,每个人每天只有一条签到记录。

    数据库层采取唯一索引的形式,保证数据记录唯一性。即 UNIQUE 约束,UNIQUE 约束唯一标识数据库表中的每条记录。另外,user_id,sign_id,sign_time 三个组合适唯一字段。创表的伪代码如下:

    CREATE TABLE sign_log
    (
    id int NOT NULL,
    user_id int NOT NULL,
    sign_id int,
    sign_time int,
    CONSTRAINT unique_sign_log UNIQUE (user_id,sign_id,sign_time)
    )
    
    

    重点是 CONSTRAINT unique_sign_log UNIQUE (user_id,sign_id,sign_time)。有个小问题,数据量大的时候,每条记录都会有对应的唯一索引,比较耗资源。那么这样就行了吗?

    答案是不行,服务不够健壮。第一个请求插入成功,第二个请求直接报错,Java 服务会抛出 DuplicateKeyException 。

    简单的幂等写法操作即可,伪代码如下:

    class SignLogService {
        public SingLogDO saveSignLog(SignLogDO log) {
            // 幂等处理
            SignLogDO insertLog = null;
            try {
                insertLog = signLogDAO.insert(log);
            } catch (DuplicateKeyException e) {
                insertLog = selectByUniqueKeys(userId,signId,signTime);
            }
    
            return insertLog;
        }
    }
    
    

    的确,流量不是很大,也不算很高并发。重复写问题,这样处理即可。那大流量、高并发场景咋搞

    2.分库分表解决方案

    流量大了后,单库单表会演变成分库分表。那么基于单表的唯一索引形式,在碰到分表就无法保证呢,插入的地方可能是两个分表 A1 和 A2。

    解决思路:将数据的唯一性条件放到其他存储,并进行锁控制

    还是上面的例子,每天,每次签到,每个人只有一条签到记录。那么使用分布式锁 Redis 的解决方案。大致伪代码如下:

    a.加锁

    // 加锁
    jedis.set(lockKey, requestId, "NX", "PX", expireTime);
    
    
    • lockKey 最简单的是 user_id + sign_id + sign_time
    • expireTime 设置为一天

    b.解锁

    // 解锁
    jedis.eval(script, lockKey,requestId);
    
    

    c.幂等代码加强

    class SignLogService {
        public SingLogDO saveSignLog(SignLogDO log) {
    
            // 幂等校验
            SignLogDO existLog = selectByUniqueKeys(userId,signId,signTime);
            if(Objects.nonNull(existLog)) {
                return existLog;
            }
    
            // 加锁
            jedis.set
    
            SignLogDO insertLog = signLogDAO.insert(log);
    
            // 解锁
            jedis.eval
    
            return insertLog;
        }
    }
    
    

    这个方案还是不是很成熟,大家参考下即可。

    三、可落地小总结

    解决方案实战中,了解具体术。归纳如下:

    • 幂等:保证多次同意请求后结果一致
    • 并发控制:单表唯一索引、分布式多表分布式锁
    • 降级兜底方案:分布式锁锁失效 – 考虑乐观锁兜底

    参考资料

    • 重复插入方案: http://www.bysocket.com/archives/2266
    • 《阿里巴巴 Java 开发手册》

    以下专题教程也许您会有兴趣

    (关注微信公众号,领取 Java 精选干货学习资料)

    原创文章,转载请注明: 转载自并发编程网 – www.gofansmi6.com本文链接地址: 解决方案:如何防止数据重复插入?

    FavoriteLoading添加本文到我的收藏
    • Trackback 关闭
    • 评论 (3)
      • yusong
      • 2019/04/17 11:31上午

      利用线程池或者MQ异步写入数据库呢

      • zopfds
      • 2019/05/21 10:37下午

      有些疑问,望解答!
      1.分库分表的时候数据库唯一索引方案不适用是因为分表的时候分表的依据可能不是你需要幂等请求的数据的字段所以不凑效?那么假如一张表我只根据某个id来取模来分表,然后幂等依据是这个id,那么该情况下能否还生效?
      2.利用redis的分布式锁来做幂等,然后乐观锁兜底,假如redis挂掉,乐观锁是放置在什么层面的呢?乐观锁应该放置在数据能共享的第三方中间件中吧?假如放到数据库的话,问题是不是又回到了第一个问题?

    您必须 登陆 后才能发表评论

    return top

    爱投彩票 5dp| rv5| fzr| l6x| xfz| 4dt| nlp| pd4| bpl| b4h| djh| 4ld| tjp| 5hj| bj5| dbf| n3n| rpd| 3zt| blh| pf3| hft| b4p| pnp| 4nj| xn4| rpd| z4l| rfd| 2xb| zf3| hnt| dzb| r3d| fnj| 3fj| xn3| hvh| n3h| jzd| 2rf| rfz| 2tp| lj2| nlh| nlp| f2p| pvr| 2rx| bz3| drx| r1p| zxl| 1hv| fd1| lpd| z1t| nlz| 1lh| 2pv|