一、Redis事务原理分析

在Redis的事务里面,采用的是乐观锁,主要是为了提高性能,减少客户端的等待。由几个命令构成:WATCH, UNWATCH, MULTI, EXEC, DISCARD。
通过WATCH,可以实现CAS操作。使用WATCH监听一些键,然后去检查键的值,然后根据键的值来决定是否还需要进行MULTI,如果键的值被改了,则重新。(因为有可能在执行WATCH前,键的值被改了,所以需要先WATCH,然后再作判断)。在执行MULTI命令后,如果中途WATCH的键的值被修改了,后续再执行EXEC时,整个事务都会被终止。

 

事务实现原理 : Redis是通过WATCH命令,来保证当前事务的数据是否被修改过,如果被修改了,则整个事务会中止,不再执行。那么,Redis在实现的时候,会保存对应的watch key,然后中途如果该Key被修改了,则会将对应的所有客户端(server端保存所有客户端watch链表)的标志位都置为CLIENT_DIRTY_CAS,表示数据被修改,后续执行EXEC的时候则会被中断,从而实现事务。而UNWATCH命令则是从保存的watch_keys里面移除。MULTI命令仅仅将客户端的标志位flags置为CLIENT_MULTI,表示处于MULTI状态,该状态下,后续的命令(除了MULTI/WATCH/DISCARD/EXEC)外,其它命令都会被保存到一个列表里面,直到EXEC或者DISCARD命令执行。如果中途出现了语法错误之类的命令,则会将flags置为CLIENT_DIRTY_EXEC。后续执行EXEC时,如果flags存在CLIENT_DIRTY_CAS或者CLIENT_DIRTY_EXEC,则整个事务会被中止,不执行任何命令。

 

ACID分析 :

  1. Atomicity
    指的是要么不执行,要么全部执行。当其中一部分执行了,但是另外一部分没有执行,那么作为整个事务,是全部要回滚,都不执行的,而Redis在执行过程中,如果出现操作和类型不一致,则会导致一部分执行,而一部分错误的情况,即不满足原子性。当然,除去部分失误外,还是能够保证原子性的,但是这并不是严格的原子性要求。
  2. Durability
    持久性,事务提交后,无论出现任何情况,包括系统断电之类的,重启后都是可以恢复的。对于Redis来说,即使开启了AOF以及设置为always,也存在命令执行一部分后,系统宕机而导致数据不一致的情况,不能恢复。一般都是通过write-ahead-logging来实现的,即事先写日志,而Redis是边执行边写日志。
  3. Consistency
    一致性,指从一个有效的状态转到另一个有效的状态,不满足上述的两个条件,也无法保存一致性,即会出现中间状态。比如从一个人的账户转到另外一个人上面,执行了转出,但是没有执行转入的时候宕机了,就会导致数据的不一致。
  4. Isolation
    隔离性,在多个事务并发的情况下,事务之间不会被影响。对于Redis来说,事务的执行是串行的,中途不会插入其它命令的执行,所以是满足隔离性的。

WATCH命令实现 :

监听Key,首先就要有地方保存监听的Key,Redis针对不同的客户端,会在客户端的结构体里面维护一个WATCH监听Key的列表,以及在Server里面维护一个全局的哈希表,Key为被监听的Key,Value则为一个链表,里面保存了所有监听该Key的客户端。

当执行WATCH account时,则首先会判断该Key是否已在客户端里面,如果存在,则直接返回,否则加入到客户端对应的watched_keys列表里面,然后再将其加入到对应DB的watched_keys字典表里面,Key为 account,Value则为该客户端。