本篇文章主要介绍redis中的Pipeline和事务相关的内容。
Pipeline
redis执行命令一般包含四个过程，发送命令、命令排队、命令执行、结果响应四个步骤。由于Redis 本身是基于Request/Response协议（停等机制）的，虽然Redis已经提供了像mget 、mset 这种批量的命令，但是好哥哥们想一下，如果某些操作根本就不支持或没有批量的操作，是不是就要一条一条的执行命令。那这样岂不是和我大 Redis 高性能背道而驰了（因为每执行一条命令都要消耗请求与响应的时间）。好哥哥们会问了，那有什么办法能解决这个问题呢，答案就是Pipeline。
在Redis中通过Pipeline机制能改善上面这类问题，它能将一组Redis命令进行组装，通过一次传输给Redis并返回结果集。如下图
实现Pipeline功能，需要客户端和服务器端的支持。
Redis服务器端支持处理一个客户端通过同一个TCP连接发来的多个命令。可以理解为，这里将多个命令切分，和处理单个命令一样，处理完成后会将处理结果缓存起来，所有命令执行完毕后统一打包返回。这里就会涉及到一个问题就是如果Pipeline一次的命令条数过多时，会使响应结果撑爆Socket接收缓冲区，所以好哥哥们要控制一下每次的命令条数。
客户端方面像Jedis实现的逻辑是，通过API生成一个Pipeline对象，每次往Pipeline中添加命令时，Jedis会将命令写入（只是写入还没有发送给 Redis）到Outputstream（Jdedis 封装了自己的输入/输出流）。当真正调用获取结果时会调flush()方法然后阻塞获取返回结果，然后将结果包装返回给调用方。
批量命令、Pipeline对比
- 原生批量命令是原子的，Pipeline 是非原子的。
- 原生批量命令是一个命令对应多个key，Pipeline支持多个命令。
- 原生批量命令是Redis服务端支持实现的，而Pipeline需要服务端和客户端的共同实现
适用场景
Peline是Redis的一个提高吞吐量的机制，适用于多key读写场景，比如同时读取多个key的value，或者更新多个key的value，并且允许一定比例的写入失败、实时性也没那么高，那么这种场景就可以使用了。比如 10000条一下进入redis，可能失败了2条无所谓，后期有补偿机制就行了，像短信群发这种场景，这时候用pipeline最好了。
注意点
- Pipeline是非原子的，在上面原理解析那里已经说了就是Redis实际上还是一条一条的执行的，而执行命令是需要排队执行的，所以就会出现原子性问题。
- Pipeline中包含的命令不要包含过多。
- Pipeline每次只能作用在一个Redis节点上。
- Pipeline不支持事务，因为命令是一条一条执行的。
事务
Redis通过MULTI、EXEC、WATCH等命令来实现事务（transaction）功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。
redis事务从开始到结束通常会有以下三个阶段：
- 事务开始：通过MULTI开始一段事务
- 命令入队：将执行的命令按照操作前后，放入队列，在执行的时候会按照先后顺序进行执行
- 事务执行：当一个处于事务状态的客户端向服务器发送EXEC命令时，这个EXEC命令将立即被服务器执行。服务器会遍历这个客户端的事务队列，执行队列中保存的所有命令，最后将执行命令所得的结果全部返回给客户端。
WATCH命令
WATCH命令是一个乐观锁，它可以在EXEC命令执行之前，监视任意数量的数据库键，并在EXEC命令执行时，检 查被监视的键是否至少有一个已经被修改过了，如果是的话，服务器将拒绝执行事务，并向客户端返回代表事务执行失败的空回复。
底层是保存了一个watched_keys字典，这个字典的键是某个被WATCH命令监视的数据库键，而字典的值则是一个链表，链表中记录了所有监视相应数据库键的客户端。
所有对数据库进行修改的命令，比如SET、LPUSH、SADD、ZREM、DEL、FLUSHDB等等，在执行之后都会调用multi.c/touchWatchKey函数对watched_keys字典进行检查，查看是否有客户端正在监视刚刚被命令修改过的数据库键，如果有的话，那么touchWatchKey函数会将监视被修改键的客户端的REDIS_DIRTY_CAS标识打开，表示该客户端的事务安全性已经被破坏。
当服务器接收到一个客户端发来的EXEC命令时，服务器会根据这个客户端是否打开了REDIS_DIRTY_CAS标识来决定是否执行事务：
- 如果客户端的REDIS_DIRTY_CAS标识已经被打开，那么说明客户端所监视的键当中，至少有一个键已经被修改过了，在这种情况下，客户端提交的事务已经不再安全，所以服务器会拒绝执行客户端提交的事务。
- 如果客户端的REDIS_DIRTY_CAS标识没有被打开，那么说明客户端监视的所有键都没有被修改过（或者客户端没有监视任何键），事务仍然是安全的，服务器将执行客户端提交的这个事务。
redis事务的ACID性质
原子性：
事务具有原子性指的是，数据库将事务中的多个操作当作一个整体来执行，服务器要么就执行事务中的所有操作，要么就一个操作也不执行。在redis中不会因为一个命令执行失败而不执行后续的命令，相反即使错误，也会顺序执行后面的操作。
一致性：
事务具有一致性指的是，如果数据库在执行事务之前是一致的，那么在事务执行之后，无论事务是否执行成功，数据库也应该仍然是一致的。“一致”指的是数据符合数据库本身的定义和要求，没有包含非法或 者无效的错误数据。
Redis通过谨慎的错误检测和简单的设计来保证事务的一致性，
- 入队错误： 如果一个事务在入队命令的过程中，出现了命令不存在，或者命令的格式不正确等情况，那么Redis将拒绝执行这个事务。
- 执行错误： 除了入队时可能发生错误以外，事务还可能在执行的过程中发生错误。关于这种错误有两个需要说明的地方：
- 执行过程中发生的错误都是一些不能在入队时被服务器发现的错误，这些错误只会在命令实际执行时被触发。
- 即使在事务的执行过程中发生了错误，服务器也不会中断事务的执行，它会继续执行事务中余下的其他命令，并且已执行的命令（包括执行命令所产生的结果）不会被出错的命令影响。
- 服务器停机：如果Redis服务器在执行事务的过程中停机，那么根据服务器所使用的持久化模式，可能有以下情况出现：
- 如果服务器运行在无持久化的内存模式下，那么重启之后的数据库将是空白的，因此数据总是一致的。
- 如果服务器运行在RDB模式下，那么在事务中途停机不会导致不一致性，因为服务器可以根据现有的RDB文件来恢复数据，从而将数据库还原到一个一致的状态。如果找不到可供使用的RDB文件，那么重启 之后的数据库将是空白的，而空白数据库总是一致的。
- 如果服务器运行在AOF模式下，那么在事务中途停机不会导致不一致性，因为服务器可以根据现有的AOF文件来恢复数据，从而将数据库还原到一个一致的状态。如果找不到可供使用的AOF文件，那么重启之后的数据库将是空白的，而空白数据库总是一致的。
隔离性
事务的隔离性指的是，即使数据库中有多个事务并发地执行，各个事务之间也不会互相影响，并且在并发状态下执行的事务和串行执行的 事务产生的结果完全相同。
因为Redis使用单线程的方式来执行事务（以及事务队列中的命令），并且服务器保证，在执行事务期间不会对事务进行中断，因此， Redis的事务总是以串行的方式运行的，并且事务也总是具有隔离性。
持久性
事务的持久性指的是，当一个事务执行完毕时，执行这个事务所得的结果已经被保存到永久性存储介质（比如硬盘）里面了，即使服务器在事务执行完毕之后停机，执行事务所得的结果也不会丢失。
因为Redis的事务不过是简单地用队列包裹起了一组Redis命令，Redis并没有为事务提供任何额外的持久化功能，所以Redis事务的耐久性由Redis所使用的持久化模式决定：
- 当服务器在无持久化的内存模式下运作时，事务不具有耐久性：一旦服务器停机，包括事务数据在内的所有服务器数据都将丢失。
- 当服务器在RDB持久化模式下运作时，服务器只会在特定的保存条件被满足时，才会执行BGSAVE命令，对数据库进行保存操作，并且异步执行的BGSAVE不能保证事务数据被第一时间保存到硬盘里面，因 此RDB持久化模式下的事务也不具有耐久性。
- 当服务器运行在AOF持久化模式下，并且appendfsync选项的值为always时，程序总会在执行命令之后调用同步（sync）函数，将命令数据真正地保存到硬盘里面，因此这种配置下的事务是具有耐久性的。
- 当服务器运行在AOF持久化模式下，并且appendfsync选项的值为everysec时，程序会每秒同步一次命令数据到硬盘。因为停机可能会恰好发生在等待同步的那一秒种之内，这可能会造成事务数据丢失，所以这种配置下的事务不具备持久性。
- 当服务器运行在AOF持久化模式下，并且appendfsync选项的值为no时，程序会交由操作系统来决定何时将命令数据同步到硬盘。因为事务数据可能在等待同步的过程中丢失，所以这种配置下的事务不具有耐久性