聊聊 Redis 的事务

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

• 提供事务支持，保证一串命令操作的原子性，即开启事务后，所有命令放入一个队列中，然后一起执行，在此过程中不允许其他客户端操作来打断
• 当队列中的命令在执行过程中，某个命令发生错误，或者是由于网络等原因导致，那么事务将终止，且执行过的命令不能回滚
• 在事务执行过程中，如果两个操作之间存在依赖关系，如一个写操作依赖一个读操作的话，因为命令实质还没有执行，所以被依赖的操作不会有返回值，这种情况会导致事务失败；此种依赖操作在一个事务中应尽量避免
• 将操作某个key的命令加入事务队列时，此刻其他客户端有可能对该key进行操作，并没有做任何的同步措施，此种情况我们需要使用watch来监视该key，在当前事务exec之前，如果该key的值发生变化，那么整个事务就会失败（乐观锁）

首先明确一点，不能使用关系数据库(特别是单机)的强事务标准来要求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高效存取速度的优势