从应用到底层：36张图带你进入Redis世界（下）

总感觉哪里不对，但是又说不上来

从应用到底层：36张图带你进入Redis世界（上）

4.6 事务

MySQL 中的事务还是挺多道道的还要，而在Redis中的事务只要有如下三步：

关于事务具体结论：

1、redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。　

2、Redis事务没有隔离级别的概念：批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到。

3、Redis不保证原子性：Redis中单条命令是原子性执行的，但事务不保证原子性。

4、Redis编译型错误事务中所有代码均不执行，指令使用错误。运行时异常是错误命令导致异常，其他命令可正常执行。

5、watch指令类似于乐观锁，在事务提交时，如果watch监控的多个KEY中任何KEY的值已经被其他客户端更改，则使用EXEC执行事务时，事务队列将不会被执行。

4.7、正确开发步骤

上线前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。

上线时：本地 ehcache 缓存 + Hystrix 限流 + 降级，避免MySQL扛不住。上线后：Redis 持久化采用 RDB + AOF 来保证断点后自动从磁盘上加载数据，快速恢复缓存数据。

5、分布式锁

日常开发中我们可以用 synchronized 、Lock 实现并发编程。但是Java中的锁只能保证在同一个JVM进程内中执行。如果在分布式集群环境下用锁呢？日常一般有两种选择方案。

5.1、 Zookeeper实现分布式锁

你需要知道一点基本zookeeper知识：

1、持久节点：客户端断开连接zk不删除persistent类型节点 2、临时节点：客户端断开连接zk删除ephemeral类型节点 3、顺序节点：节点后面会自动生成类似0000001的数字表示顺序 4、节点变化的通知：客户端注册了监听节点变化的时候，会调用回调方法

大致流程如下，其中注意每个节点只监控它前面那个节点状态，从而避免羊群效应。关于模板代码百度即可。

缺点：

频繁的创建删除节点，加上注册watch事件，对于zookeeper集群的压力比较大，性能也比不上Redis实现的分布式锁。

5.2、 Redis实现分布式锁

本身原理也比较简单，Redis 自身就是一个单线程处理器，具备互斥的特性，通过setNX，exist等命令就可以完成简单的分布式锁，处理好超时释放锁的逻辑即可。

SETNX

SETNX 是SET if Not eXists的简写，日常指令是SETNX key value，如果 key 不存在则set成功返回 1，如果这个ke