经过前面的学习，我们就对于Redis数据库可以进行基本的操作，从这一节开始，我们就正式学习Redis数据库的相关知识，为以后工作打下坚实的基础。

目录

一、事务（了解）

1.1 Redis的事务概念  

1.2 Redis事务机制命令

1.2.1 正常执行事务

1.2.2 放弃事务

1.2.3 编译型异常

1.2.4 执行时异常

二、Redis的乐观锁 Watch（面试）

2.1 悲观锁（Pessimistic Lock）

2.2  乐观锁（Optimistic Lock）

---

一、事务（了解）

1.1 Redis的事务概念  

         事务的本质： 一组命令的集合！一个事务中的所有命令都会被序列化，在事务执行过程中，会按照顺序执行！ 一次性，顺序性，排他性，执行一系列的命令！ MySQL中的事务，要么同时成功，要么同时失败，必须保证原子性！ Redis中的事务中的命令按顺序执行，但 Redis 不提供回滚机制。如果事务中的某个命令失败，其他命令仍会继续执行。Redis单条命令是保证原子性的，所有事务内的命令要么全部执行，要么全部不执行，但不保证部分命令失败时的回滚。事务执行时，所有命令被一次性发送到服务器， Redis事务是没有隔离级别的概念。

1.2 Redis事务机制命令

 Redis的事务使用过程：

1.  开启事务：multi 
2.  命令入队 ...
3.  执行事务： exec

所有的命令在事务中，并没有直接被执行！只有发起执行命令的时候才会执行！

1.2.1 正常执行事务

1.2.2 放弃事务

1.2.3 编译型异常

命令有错， 事务中所有的命令都不会被执行

1.2.4 执行时异常

如果事务队列中存在语法性错误，执行命令的时候，错误命令抛出异常，其他命令可以正常执行，

二、Redis的乐观锁 Watch（面试）

       这只是解决问题的一种思路。

2.1 悲观锁（Pessimistic Lock）

       悲观锁假设并发冲突会频繁发生，因此在事务开始时就加锁，以防止其他客户端同时修改数据。悲观锁会阻塞其他客户端对数据的访问，直到事务结束。很悲观，认为什么时候都会出问题，无论做什么都会加锁！但是影响效率！

2.2  乐观锁（Optimistic Lock）

        乐观锁假设并发冲突不会频繁发生，因此不会在事务开始时加锁，而是在提交事务时检查数据是否被修改。如果数据在事务期间被其他客户端修改，事务将失败并需要重试。很乐观，认为什么时候都不会出问题，所以不会加锁！更新数据时去判断一下，在此期间是否有人 修改过这个数据！MySQL的version的使用：先获取version，更新数据时比较version，看version 是否被修改

Redis的监视测试：

        watch监测的对象在我修改时，别人也修改了，此次操作就会失败。

1、正常执行成功！

2、多线程修改值，使用watch可以当做Redis的乐观锁操作！在命令执行之前，第二个客户端执行了修改了a的值，就会导致事务执行失败

至此，Redis数据库第四节就介绍完毕，这一节内容作个简单了解，更多精彩内容见后期博客！感谢阅读，如果喜欢，点赞加关注！