聊聊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 高效存取速度的优势