了解redis事务的cas操作吗

了解redis事务的cas操作吗

当你使用Redis构建你的服务的时候，一定要记住，你只是找了一个合适的工具来实现你需要的功能。
而不是说你在用Redis构建一个服务，这是很不同的，你把Redis当作你很多工具中的一个，只在合适使用的时候再使用它，在不合适的时候选择其它的方法。

说到事务大家都不陌生，在关系型数据库中，事务时并发控制的基本单位，他是一个操作的序列，可以包含多个指令，并且，对于一个事务，其内部的指令要么全部执行，要么都不执行，内部指令不可分割。
关系型数据库的事务具有四个特性：
1. 原子性
2. 一致性
3. 隔离性
4. 持久性
而在我们redis数据库中，事务回事什么样子的呢？
首先我们给出一个定义：redis的事务中，一次执行多条命令，本质是一组命令的集合，一个事务中所有的命令将被序列化，即按顺序执行而不会被其他命令插入
在redis中，事务的作用就是在一个队列中一次性、顺序性、排他性的执行一系列的命令。
事务的生命周期：
1. 事务的创建：使用MULTI开启一个事务
2. 加入队列：在开启事务的时候，每次操作的命令将会被插入到一个队列中，同时这个命令并不会被真的执行
3. EXEC命令进行提交事务
常用的关于事务的命令有：
1. MULTI：使用该命令，标记一个事务块的开始，通常在执行之后会回复OK，（但不一定真的OK），这个时候用户可以输入多个操作来代替逐条操作，redis会将这些操作放入队列中。
2. EXEC：执行这个事务内的所有命令
3. DISCARD：放弃事务，即该事务内的所有命令都将取消
4. WATCH：监控一个或者多个key，如果这些key在提交事务（EXEC）之前被其他用户修改过，那么事务将执行失败，需要重新获取最新数据重头操作（类似于乐观锁）。
5. UNWATCH：取消WATCH命令对多有key的监控，所有监控锁将会被取消。
注意：关于乐观锁等概念：
乐观锁：就像他的名字，不会认为数据不会出错，他不会为数据上锁，但是为了保证数据的一致性，他会在每条记录的后面添加一个标记（类似于版本号），假设A 获取K1这条标记，得到了k1的版本号是1，并对其进行修改，这个时候B也获取了k1这个数据，当然，B获取的版本号也是1，同样也对k1进行修改，这个时候，如果B先提交了，那么k1的版本号将会改变成2，这个时候，如果A提交数据，他会发现自己的版本号与最新的版本号不一致，这个时候A的提交将不会成功，A的做法是重新获取最新的k1的数据，重复修改数据、提交数据。
悲观锁：这个模式将认定数据一定会出错，所以她的做法是将整张表锁起来，这样会有很强的一致性，但是同时会有极低的并发性（常用语数据库备份工作，类似于表锁）。
那么，现在我们来执行一次具体看看redis的事务机制：
首先我会开启事务，并向数据库中存储4条数据，可以看到没执行一条命令的时候都会显示入队，并不会返回执行结果，说明redis中在事务提交之前，其内部的所有命令将不会被执行：


那么，如果中间有命令出错了会怎样呢？现在我随便打几个字符试一试：


可以看出，在第三条命令中我随便打了几个字符，提交事务的时候并没有成功，这也很符合我们对事务的理解，嗯~具有原子性。但是，有一个细节，那就是错误命令在我输入的时候就已经报错了，也就是说这个条错误命令在进入队列的时候redis就已经知道这是一条错误命令，这样，整个事务的命令将全部失败，那么，有没有一种可能某个错误指令在进入队列的时候redis还没有发现他的错误呢？我们试一试下面这个例子：


问题出现了，我们可以看到，name+1这条指令其实是错误的，但是提交事务的时候会发现，这条错误命令确实没有执行，但是其他正确的命令却执行，这是为什么的？
原因是在redis中，对于一个存在问题的命令，如果在入队的时候就已经出错，整个事务内的命令将都不会被执行（其后续的命令依然可以入队），如果这个错误命令在入队的时候并没有报错，而是在执行的时候出错了，那么redis默认跳过这个命令执行后续命令。也就是说，redis只实现了部分事务。
下面我们来看看刚刚提到的锁的问题，我们说过，redis的锁CAS(check and set)类似于乐观锁，redis的实现原理是使用watch进行监视一个（或多个）数据，如果在事务提交之前数据发生了变化（估计使用了类似于乐观锁的标记），那么整个事务将提交失败，我们可以举一个例子，我们开启两个终端，模拟两个人的操作，设置一条数据为count，初始时100，现在A对其进行监控，并且为count增加20


在没有提交之前，B也获取了这个count，为其减少50，


那么这个时候A如果提交事务，会出现失败提示：


可以看到，在A对数据的修改过程中，B对数据进行了修改，那么这条数据的“标记”就发生了变化，已经不是当初A取出数据的时候的标记了，这样，A的事务也就提交失败了。
最后通过上述的实验，我们总结redis事务的三条性质：
1. 单独的隔离操作：事务中的所有命令会被序列化、按顺序执行，在执行的过程中不会被其他客户端发送来的命令打断
2. 没有隔离级别的概念：队列中的命令在事务没有被提交之前不会被实际执行
3. 不保证原子性：redis中的一个事务中如果存在命令执行失败，那么其他命令依然会被执行，没有回滚机制

阅读全文