一、事务：

1. 事务概述：

1.1 什么是事务：

指可以一次执行多个命令，本质是一组命令的集合。 一个事务中的所有命令都会序列化，按顺序的串行化执行而不会被其他命令插入，不许加塞。 即：一个队列中，一次性、顺序性、排他性的执行一系列命令。

1.2 与传统关系型数据库的事务相比redis事务的不同之处：

我觉得最关键的一个不同就是redis事务不能保证原子性，在MySQL的一个事务里的命令要么全部成功要么全部失败， 但是在redis事务里，它只会把这个事务里的一系列命令执行完，不管成功与否，事务都算结束了。

2. 事务的常用操作：

2.1 事务正常执行：

输入MULTI命令标记开启一个事务，之后的每条命令都会进入对列，显示QUEUED即已经进入队列。 输入EXEC命令，会执行事务块内(队列)的所有命令。

2.2 放弃事务：

在事务块内输入命令DISCARD，该事务块内的所有命令不会执行，并且退出该事务块。

2.3 事务异常（执行前异常）：

执行前异常一般是这种命令出错（编译错误）的异常

2.4 事务异常（执行后异常）：

执行后异常一般指执行错误的异常，这种异常，除了出错的命令外，正常执行的命令都会在这个事务块执行后成功运行。不能保证原子性的原因。

2.5 watch监控：

1）加监控且没有被篡改的情况：

2）加监控出现加塞篡改的情况：

说明：

watch命令是一种乐观锁的实现，Redis在修改的时候会检测数据是否被更改，如果更改了，则执行失败 第一个窗口蓝色框第5步执行结果返回为空，也就是相当于是失败，整个事务的命令都不会成功执行，相当于DISCARD

复习：悲观锁和乐观锁

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。 乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据。 乐观锁策略:提交版本必须大于记录当前版本才能执行更新 redis是性能优先的数据库，肯定是使用的乐观锁实现，因为悲观锁实现会频繁加锁，对性能的消耗大。

3）unwatch： 开启unwatch后，在该命令之前的监控全部失效，不会对数据进行监控

4）注意： 一旦执行了EXEC，之前加的监控锁都会被取消掉；当客户端连接断开时，所有监控锁会被取消。

二、管道：

1. 管道概述：

1.1 管道出现的背景：

Redis是一种基于客户端-服务端模型以及请求/响应协议的TCP服务。一个请求会遵循以下步骤： 1） 客户端向服务端发送命令分四步(发送命令→命令排队→命令执行→返回结果)，并监听Socket返回，通常以阻塞模式等待服务端响应。 2） 服务端处理命令，并将结果返回给客户端。 上述两步称为：Round Trip Time(简称RTT,数据包往返于两端的时间) 如果同时需要执行大量的命令，那么就要等待上一条命令应答后再执行，这中间不仅仅多了RTT（Round Time Trip），而且还频繁调用系统IO，发送网络请求，同时需要redis调用多次read()和write()系统方法，系统方法会将数据从用户态转移到内核态，这样就会对进程上下文有比较大的影响了，性能不太好，o(╥﹏╥)o

1.2 管道的定义：

管道是为了解决命令往返过于频繁而导致的RTT时长过长，仅仅是将命令打包一次性发送，对整个redis的执行不造成其他任何影响。 它属于批处理命令变种优化措施，类似redis的原生批处理命令(mset和mget)，但是这种批处理命令（例如mset）只能对string类型的数据批处理， 如果需要对多种类型数据批处理，就必须使用管道了 所以，管道的出现能对频繁的命令往返进行优化，从而提升redis的性能。

2. 管道实操：

2.1 先清空数据库（方便直观地显示操作结果）：

2.2 使用管道进行批处理：

这时候再去查询数据库会发现，这些命令都被成功且正确的执行了

2.3 管道与原生批命令对比：

2.4 管道与事务对比：

2.5 注意：

管道缓冲的指令只是会依次执行，不保证原子性，如果执行过程中指令发生异常，将会继续执行后续的指令。 使用管道组装的命令个数也不能太多，不然数据量过大，客户端阻塞的时间可能过久，同时服务端此时也被迫回复一个队列答复，占用很多内存。