聊聊Redis的事务

目前对于 Redis 的事务支持，我们知道的有如下几点：

首先明确一点，不能使用关系数据库 (特别是单机) 的强事务标准来要求 Redis，毕竟不是一个血统的，但我们也可以通过一些手段尽量来避免事务的失败；在我们目前的项目中，做了一些工作，总结起来有几点。

随用随取之线程变量

Redis 官方推荐的 java 客户端是 jedis，我们使用他自带的连接池 pool，同时尽量做到当前同一个请求线程使用的是同一个客户端实例，即在一次请求开始到结束，所有的操作都尽量使用同一个 jedis 实例（是尽量而不是保证全部），这样可以减少对 pool 的存取操作，同时减少服务端的连接。

因为 jedis 客户端使用了 2 个类来分别对应普通操作和事务操作，即 Jedis 和 Transaction，要实现以上的需求我们可以将这 2 个对象存入线程变量 ThreadLocal 中，当前请求过程中所有的需要使用客户端的地方，从线程变量中获取即可；根据情况需要用什么就取什么。

事务操作何时开始何时提交之嵌套调用

对于每个需要保证事务的业务操作，我们利用 Spring 的 AOP(这部分内容不在本篇文章范围之内) 在每个业务操作之前和之后加入 jedis 客户端实例初始化逻辑和事务提交逻辑，其实初始化逻辑只在第一次业务逻辑调用时做了一次，同时每次初始化时都递增方法调用计数器 level（第一次初始化时 level=1）；下面执行业务逻辑代码，最后到事务提交逻辑，如果此时业务逻辑代码中没有嵌套调用其他的业务逻辑，那么就可以直接提交事务了，因为我们是根据 level-1 的值进行判断的，结果为 0 时，即可提交事务，看似完美，但实际情况是业务逻辑代码很傻很天真，不停的调用其他的业务逻辑，这种调用也分为 3 种情况：

调用当前业务类中其他方法

X( ) ++++++++++++++ # initial: level = 1 a( ) # initial: level = 2, commit: level = 1 b( ) # initial: level = 2, commit: level = 1 c( ) # initial: level = 2, commit: level = 1 X( ) ++++++++++++++ # commit: level = 0

调用其他业务类的方法

X( ) ++++++++++++++ # initial: level = 1 BS1.a( ) # initial: level = 2 BS2.b( ) # initial: level = 3 BS3.c( ) # initial: level = 4, commit: level = 3 BS2.b( ) # commit: level = 2 BS1.a( ) # commit: level = 1 x( ) ++++++++++++++ # commit: level = 0

混合调用式

这种情况下，有可能是同一个业务类方法调用了其他业务类中的方法，同时再次调用了同一个业务类的方法等等情况；规则依然如上面列举的 2 中情况一样，进入方法计数器加一，退出时减一，判断是否可以提交事务。

事务操作和普通操作之混合式

如果一个事务操作单元很小，那我们必须让这个单元在一个事务中完成操作，但是对于某个比较大的业务逻辑单元，其中即包含了诸多小事务单元也同时包含了诸多普通操作单元（使用 Jedis 实例对象而不是 Transaction 对象实例操作），我们的措施就是 --- 同化操作，如果当前已经开启了事务模式，此时进入了一个普通操作单元，那就将这个普通操作转为事务操作，即使用 Transaction 实例进行操作；反过来，如果当前使用的普通操作模式，此时进入一个事务操作单元，这种情况并没有多大影响，因为普通操作单元执行命令马上就会有结果，事务操作开始后，以及其后面所有的操作都将进入事务模式，直到业务逻辑结束时一齐提交命令。

事务操作命令之依赖

就如文章开头提到的第三点，两个操作直接存在依赖关系，如一个写操作需要依赖一个读操作的结果，但是在事务中读操作还没有真正执行，没有结果，怎么办？我们的办法就是当断即断，立即提交事务，redis 这种内存数据库，操作都是毫秒级的，在开启事务的情况下，读取的值是有保障的，可以作为写操作的依赖；这里有个小技巧，就是每次立即提交事务后，都要清空线程变量 threadlocal 中的 jedis 客户端实例，因为事务提交后，jedis 客户端对象本身的状态也会发生变化，下次使用需要重新生成。

watch 之监视

对于更严格的事务要求，使用 watch 命令对 key 进行监视，保证一致性；当然对于不能回滚的问题，还没有好的解决办法！

总结一下

使用 redis 不能苛求强事务标准，尽量使用简单的业务逻辑 选择适当的业务场景，充分利用 redis 高效存取速度的优势