概念

什么原子性？程序在执行过程中，要么全部都执行，要么全部都不执行，不可能执行了一半，滞留了一半。我们知道redis是IO多路复用模型，即一个线程来处理多个TCP连接，这样的好处就是，即使客户端并发请求，也得排队处理，一定程度上解决了多线程模型带的并发问题，所以redis是并发安全的？从redis本身的架构模式来说，并发是安全的，不存在同时执行两个客户端的命令。但是如果因为某些业务场景用的有问题，那么即使是单线程的redis也无能为力。

库存问题

假设现在redis有个叫stock的key，用于存放商品的库存数据，只要进货了库存就加一，出货了库存就减一。于是这时候机智的程序员小王这样设计了一下，每次通过get获取stock的值，然后再set stock=stock+1。这时候有两个业务员A、B分别进货了，由于时间线的问题，程序大概是这样跑的：

1. A先获取value=100
2. B先获取value=100
3. A设置value=101
4. B设置value=101 整个流程下来，发现库存丢了一个，这正是因为整个操作不是原子性的，导致A影响了B，或者B影响了A。

解决方式

原生的原子命令

incr是原子操作的，对于这种场景，可以不用获取原来的值，直接用redis的incr实现read和write的打包原子操作，就不会出现读了一半，然后被别人篡改了。真实场景可能不仅仅是这种库存问题，那么像批量设置多个值的场景可以用mset，批量获取多个值的mget，与incr相对应的decr，这些都是原子的。

单机锁or分布式锁

加锁可以解决，先抢占了锁的用户，可以去操作，没抢到锁的，自旋等待下次去获取锁，然后操作。如果不是分布式系统，可以用类似golang sync.mutex锁，如果是分布式系统得用分布式锁了，可以用类似zookeeper或者redis本身的setnx。

watch + 事务

结合watch和事务也可以解决，每个客户端可以通过watch来监控自己即将要更新的key，这样在事务更新的时候，如果发现自己监控的key被修改了，那么拒绝执行，事务执行失败，这样就不会存在更新覆盖的问题。watch的本质还是乐观锁，当客户端执行watch的时候，实际上是watch的key会维护一个客户端的队列，这样就知道这个key被哪些客户端监视了。当其中的一个客户端执行完毕之后，那么它会从这个队列中移除，并且会把这个列表中剩余的所有客户端的CLIENT_DIRTY_CAS标识打开，这样剩余的客户端在执行exec的时候，发现自己的CLIENT_DIRTY_CAS已经被打开，那么就会拒绝执行。

客户端1:

127.0.0.1:6379> watch store
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET store 99
QUEUED
127.0.0.1:6379> EXEC
1) OK
127.0.0.1:6379> GET store
"99"

客户端2:

127.0.0.1:6379> watch store
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET store 100
QUEUED
127.0.0.1:6379> EXEC
(nil)
127.0.0.1:6379> GET store
"99"

客户端1和客户端2都尝试来修改store的值，然而客户端2修改失败了。

lua脚本

即使redis支持很多原子命令，但是还是无法满足所有场景，于是redis在2.6之后开始支持开发者编写lua脚本传到redis中，使用lua脚本的好处就是：

1. 减少网络开销，通过lua脚本可以一次性的将多个请求合并成一个请求。
2. 原子操作，redis将lua脚本作为一个整体，执行过程中，不会被其他命令打断，不会出现竞态问题。
3. 复用，客户端发送的lua脚本会永远存在redis服务中。

127.0.0.1:6379> EVAL "redis.call('SET',KEYS[1],ARGV[1]);redis.call('EXPIRE',KEYS[1],ARGV[2]);return 1;" 1 name sun 60
(integer) 1
127.0.0.1:6379> get name
"sun"
127.0.0.1:6379> ttl name
(integer) 56

通过eval关键字指明导入lua，在redis收到lua指令时，会把整个lua指令作为一个整体，比如上面的set和expire之间不会有其他客户端请求的指令，一定是set和expire一起做完之后，其他的命令才能执行。