redis如何实现事务性？
本质也是乐观锁。
在redis客户端执行：
$money = GET key$money = $money - $diffSET key $money
在并发量大的时候，会遇到和《并发扣款，如何保证数据的一致性？》中描述的并发一致性问题。
redis的WATCH和EXEC可以提供类似事务的机制：
- WATCH观察key是否被改动
- 如果提交时key被改动，EXEC将返回null，表示事务失败
上面保证一致性的余额扣减可能类似于这样执行：
WATCH key$money = GET key$money = $money - $diffMULTISET key $moneyEXEC
在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没有优势，高性能是因为其内存存储的原因，带来的副作用是数据有丢失风险。