有柳岩问：高并发库存扣减一致性问题，怎么用redis解决？（第42讲）

$num = GET key$num = $num - $countSET key $num

redis 的 WATCH 和 EXEC 可以提供类似事务的机制 ：

1. WATCH 观察 key 是否被改动；

2. 如果提交时 key 被改动， EXEC 将返回 null ，表示事务失败；

保证一致性的库存扣减可以优化为：

WATCH key$num = GET key$num = $num - $countMULTISET key $numEXEC

在 WATCH 之后， EXEC 执行之前，如果 key 的值发生变化，则 EXEC 会失败。

redis 的 WATCH 为何能够保证事务性？

本质上，和 上一篇 文章中提到的 乐观锁 CAS 机制是一样的，详见：

《 库存扣多啦，怎么用两行代码破解？（第41讲） 》

大部分情况下， redis 不同的客户端会访问不同的 key ，所以 WATCH 碰撞的概率会比较小，在秒杀的业务场景，使用 WATCH ，也会有一定的冲突，需要 针对秒杀业务做单独的优化 ，详见：

《 秒杀架构优化的核心原则！（第18讲） 》

为什么redis更能应对超高并发的库存管理？

根本原因 ，还是 redis 内存访问与 mysql 数据落盘 的性能差异。

redis库存管理有什么需要注意的？

数据具备“易失性”，如果重启， 数据可能丢失 ，所以 redis大部分时候是用来存储允许cache miss的数据 。如果实在要用redis来存储业务上不能够丢失的数据，需要重点设计 一致性 与 可用性 。

当然， redis 也可以固化数据，但 如果把redis当做DB用，为什么不直接使用mysql呢？

稍作总结：

1. 可以使用 redis