Redis并发竞争key问题的解决

1. 问题描述

并发竞争key这个问题简单讲就是：

同时有多个客户端去set一个key。

示例场景 1

例如有多个请求一起去对某个商品减库存，通常操作流程是：

• 取出当前库存值

• 计算新库存值

• 写入新库存值

假设当前库存值为 20，现在有2个连接都要减 5，结果库存值应该是 10 才对，但存在下面这种情况：

示例场景 2

比如有3个请求有序的修改某个key，按正常顺序的话，数据版本应该是 1->2->3，最后应该是 3。

但如果第二个请求由于网络原因迟到了，数据版本就变为了 1->3->2，最后值为 2，出问题了。

2. 解决方案

2.1 乐观锁

乐观锁适用于大家一起抢着改同一个key，对修改顺序没有要求的场景。

watch 命令可以方便的实现乐观锁。

需要注意的是，如果你的 redis 使用了数据分片的方式，那么这个方法就不适用了。

watch 命令会监视给定的每一个key，当 exec 时如果监视的任一个key自从调用watch后发生过变化，则整个事务会回滚，不执行任何动作。

2.2 分布式锁

适合分布式环境，不用关心 redis 是否为分片集群模式。

在业务层进行控制，操作 redis 之前，先去申请一个分布式锁，拿到锁的才能操作。

分布式锁的实现方式很多，比如 ZooKeeper、Redis 等。

2.3 时间戳

适合有序需求场景，例如 A 需要把 key 设置为 a，然后 B 设置为 b，C 再设置为 c，最后的值应该是 c。

这时就可以考虑使用时间戳的方式：

A => set key1 {a 11:01}

B => set key1 {b 11:02}

C => set key1 {c 11:03}

就是在写入时保存一个时间戳，写入前先比较自己的时间戳是不是早于现有记录的时间戳，如果早于，就不写入了。

假设 B 先执行了，key1 的值为 {b 11:02}，当A执行时，发现自己的时间戳11:01早于现有值，就不执行 set 操作了。

2.4 消息队列

在并发量很大的情况下，可以通过消息队列进行串行化处理。这在高并发场景中是一种很常见的解决方案。

3. 小结

“Redis 并发竞争” 问题就是高并发写同一个key时导致的值错误。

常用的解决方法：

• 乐观锁，注意不要在分片集群中使用

• 分布式锁，适合分布式系统环境

• 时间戳，适合有序场景

• 消息队列，串行化处理