场景:
类似银行存取,增减账户余额,但是多了明细表,每次转账更新用户同一条数据记录,但是用户明细表一直递增信息记录,关键字段为当前余额(操作金额加上原余额得出)
问题:
更新同一条记录可以通过增加version字段解决高并发同时写的问题
但是明细表中先读取原先余额再写入新余额,这个怎么解决,怎么能让每次读出余额是最新的,写入明细之前余额不会被修改
浏览 8.9k
已采纳
多用户高并发插入数据怎么解决并发问题
- 写回答
- 赞 踩
- 关注问题
- 收藏
- 分享
- 邀请回答
微信扫一扫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