今秋复来此
2018-04-19 04:02
采纳率: 100%
浏览 8.9k

多用户高并发插入数据怎么解决并发问题

场景:
类似银行存取,增减账户余额,但是多了明细表,每次转账更新用户同一条数据记录,但是用户明细表一直递增信息记录,关键字段为当前余额(操作金额加上原余额得出)
问题:
更新同一条记录可以通过增加version字段解决高并发同时写的问题
但是明细表中先读取原先余额再写入新余额,这个怎么解决,怎么能让每次读出余额是最新的,写入明细之前余额不会被修改

  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

4条回答 默认 最新

  • Mr_Zouhm 2018-04-20 01:17
    已采纳

    这个是乐观锁,可以使用CAS原理,取出值后得到新值,然后插入的时候比较原值,如set count = 12 where count = 8,8是旧值,但这样容易出现ABA问题,所以需要配合你的版本version使用才能避免这个问题,即取值时拿到老的值和version,塞值时配合使用,如set count = 12,version=4 where count = 8 and version=3。希望能解决你的问题

    已采纳该答案
    打赏 评论
  • ccqz 2018-04-19 07:28

    把库存放到reids里,利用redis的事务性来扣减库存。
    分析:
    redis是如何实现事务操作的?
    本质也是乐观锁。

    在redis客户端执行:
    $num = GET key
    $num = $num - $count
    SET key $num
    在并发量大的时候,会遇到和《库存扣多了,到底怎么整》文章中一样的并发一致性问题。
     
    redis的WATCH和EXEC可以提供类似事务的机制:
    • WATCH观察key是否被改动
    • 如果提交时key被改动,EXEC将返回null,表示事务失败
    上面保证一致性的库存扣减可能类似于这样执行:
    WATCH key
    $num = GET key
    $num = $num - $count
    MULTI
    SET key $num
    EXEC
     
    在WATCH之后,EXEC执行之前,如果key的值发生变化,则EXEC会失败。
     
    redis的WATCH为何能够保证事务性,本质上,它使用的就是乐观锁CAS机制。

    大部分情况下,redis不同的客户端会访问不同的key,所以WATCH碰撞的概率会比较小,在秒杀的业务场景,即使使用WATCH,调用侧仍然需要重试。
     
    在CAS机制这一点上,redis和mysql相比没有额外的优势。

    redis的性能之所以高,还是redis内存访问与mysql数据落盘的差异导致的。内存访问的不足是,数据具备“易失性”,如果重启,可能导致数据的丢失。当然redis也可以固化数据,难道每次都刷盘?redis真心没法当作mysql用。
     
    最后,redis用单线程来避免物理锁,但mysql多线程也有多线程并发的优势。

    1 打赏 评论
  • 今秋复来此 2018-04-19 05:35

    高并发更改一条数据的解决方案属于乐观锁,那先查询再根据查询的值增加新的记录怎么办?

    打赏 评论
  • dabocaiqq 2018-04-19 05:46
    打赏 评论

相关推荐 更多相似问题