一、Redis事务原理分析
一、Redis事务原理分析
在Redis的事务里面，采用的是乐观锁，主要是为了提高性能，减少客户端的等待。由几个命令构成：WATCH, UNWATCH, MULTI, EXEC, DISCARD。
通过WATCH，可以实现CAS操作。使用WATCH监听一些键，然后去检查键的值，然后根据键的值来决定是否还需要进行MULTI，如果键的值被改了，则重新。（因为有可能在执行WATCH前，键的值被改了，所以需要先WATCH，然后再作判断）。在执行MULTI命令后，如果中途WATCH的键的值被修改了，后续再执行EXEC时，整个事务都会被终止。
Redis事务实现原理 ： 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分析 ：
- Atomicity
指的是要么不执行，要么全部执行。当其中一部分执行了，但是另外一部分没有执行，那么作为整个事务，是全部要回滚，都不执行的，而Redis在执行过程中，如果出现操作和类型不一致，则会导致一部分执行，而一部分错误的情况，即不满足原子性。当然，除去部分失误外，还是能够保证原子性的，但是这并不是严格的原子性要求。 - Durability
持久性，事务提交后，无论出现任何情况，包括系统断电之类的，重启后都是可以恢复的。对于Redis来说，即使开启了AOF以及设置为always，也存在命令执行一部分后，系统宕机而导致数据不一致的情况，不能恢复。一般都是通过write-ahead-logging来实现的，即事先写日志，而Redis是边执行边写日志。 - Consistency
一致性，指从一个有效的状态转到另一个有效的状态，不满足上述的两个条件，也无法保存一致性，即会出现中间状态。比如从一个人的账户转到另外一个人上面，执行了转出，但是没有执行转入的时候宕机了，就会导致数据的不一致。 - Isolation
隔离性，在多个事务并发的情况下，事务之间不会被影响。对于Redis来说，事务的执行是串行的，中途不会插入其它命令的执行，所以是满足隔离性的。
WATCH命令实现 ：
WATCH监听Key，首先就要有地方保存监听的Key，Redis针对不同的客户端，会在客户端的结构体里面维护一个WATCH监听Key的列表，以及在Server里面维护一个全局的哈希表，Key为被监听的Key，Value则为一个链表，里面保存了所有监听该Key的客户端。
当执行WATCH account时，则首先会判断该Key是否已在客户端里面，如果存在，则直接返回，否则加入到客户端对应的watched_keys列表里面，然后再将其加入到对应DB的watched_keys字典表里面，Key为 account，Value则为该客户端。
