标签:mysq reids lock 优化 img redis 难度 src 事务性
《并发扣款,如何保证数据的一致性?》一文的核心观点是:使用CAS乐观锁,在写回余额时加上旧余额的比对,可以在不影响吞吐量的前提下,保证余额的一致性。文章非常多朋友留言问,能不能把余额放到reids里,利用redis的事务性来扣减余额。今天,就这个问题简单的说一下。
本质也是乐观锁。
在redis客户端执行:
$money = GET key
$money = $money - $diff
SET key $money
在并发量大的时候,会遇到和《并发扣款,如何保证数据的一致性?》中描述的并发一致性问题。
redis的WATCH和EXEC可以提供类似事务的机制:
WATCH key
$money = GET key
$money = $money - $diff
MULTI
SET key $money
EXEC
在WATCH之后,EXEC执行之前,如果key的值发生变化,则EXEC会失败。redis的WATCH为何能够保证事务性,本质上,它使用的就是乐观锁CAS机制。
大部分情况下,redis不同的客户端会访问不同的key,所以WATCH碰撞的概率会比较小,在秒杀的业务场景,即使使用WATCH,调用侧仍然需要重试。
画外音:如《同样是高并发,QQ/微博/12306的架构难度一样吗?》所述,key的访问会过滤uid属性,所以可以支持高并发。
在CAS机制这一点上,redis和mysql相比没有额外的优势。
redis的性能之所以高,还是redis内存访问与mysql数据落盘的差异导致的。内存访问的不足是,数据具备“易失性”,如果重启,可能导致数据的丢失。当然redis也可以固化数据,但如果每次都刷盘,redis反而性能会下降很多。
画外音:每个工具都有自己的适用场景,不宜将缓存当数据库用。
最后,redis用单线程来避免物理锁,但mysql多线程也有多线程并发的优势。
画外音:各有优劣。
结论:可以使用redis的事务性扣减余额,但在CAS机制上比mysql没有优势,高性能是因为其内存存储的原因,带来的副作用是数据有丢失风险。
架构师之路-分享技术思路
相关文章:
《并发扣款,如何保证数据的一致性?》
《并发扣款一致性优化,CAS下ABA问题》
《并发扣款一致性,幂等性问题》
《同样是高并发,不同业务为什么难度不同?》
《每秒100W请求,12306秒杀业务,架构如何优化?》
文章不长,如果你GET到了一个redis的新知识点,帮转。
标签:mysq reids lock 优化 img redis 难度 src 事务性
原文地址:https://blog.51cto.com/jyjstack/2548535