Transaction（事务）是计算机的特有术语，它一般指单个逻辑工作单位，由一系列的操作组合而成，在这些操作执行的时候，要么都执行成功，要么都不执行，防止数据结果的不一致性。
简而言之，事务是一个不可分割的工作逻辑单位。为了衡量工作单元是否具备事务能力，需要满足四个特征：ACID，即 原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。
原子性（Atomicity）：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性（Consistency）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的数据必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
隔离性（Isolation）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
持久性（Durability）：事务处理结束后，对数据的修改就是永久的，会持久化到硬盘上，即便系统故障也不会丢失。
Redis 支持事务机制，他实现事务的关键命令包括：
MULTI、EXEC、DISCARD 、 WATCH
根据上述命令，Redis 事务的执行过程包含三个步骤：
Client 通过 MULTI 命令显式开启一个事务，随后执行的操作将会暂时缓存在Queue中，实际并没有立即执行。
Client 端 把事务中的要执行的一系列操作指令发送到Service 端。 Redis服务端 实例接收到指令之后，并不是马上执行，而是暂存在命令队列中。
当Client端向Service端发送的命令都Ready了之后，可以发送提交执行或者丢弃事务的命令，如果是执行则操作队列中的具体指令，如果是丢弃则是清空队列命令。
通过 MULTI 和 EXEC 执行一个事务过程：
#开启事务
> MULTI
OK
# 定义一系列指令
> set 'name' 'brand'
QUEUED
> set 'age' 18
QUEUED
> INCR 'age'
QUEUED
> GET 'name'
QUEUED
> GET 'age'
QUEUED
# 实际执行事务
> EXEC
# 获取执行结果
1) OK
2) OK
3) 19
4) "brand"
5) "19"
从上面可以看出来，每个读写指令执行后的返回结果都是 QUEUED，代表这些操作只是暂存在指令队列中，并没有实际执行。
当发送了 EXEC 命令之后，才真正执行并获取结果。
通过 MULTI 和 DISCARD 丢弃执行，清空指令队列：
# 初始化订数据
> SET 'name' 'brand'
OK
> SET 'age' 18
OK
# 开启事务
> MULTI
OK
# 数据增量1
> INCR 'age'
QUEUED
# 丢弃
> DISCARD
OK
# 执行结果是增量前的数据
> get 'age'
"18"
体现原子性，再发生故障的时候，要么执行都成功，要么执行都失败
# 开启事务
> MULTI
OK
# 初始一个数据
> SET 'age' 18
OK
# 对该数据进行更新，但Redis不支持该命令，返回报错信息
> UPD 'age' 17
(error) ERR unknown command `UPD`, with args beginning with: `age`, `17`,
# 继续发送一个指令 ，降低age的值，该指令是正确的
> DECR 'age'
QUEUED
# 执行exec，但是之前有错误，所以Redis放弃了事务，不再执行
> EXEC
(error) EXECABORT Transaction discarded because of previous errors.
类似MySQL的事务，Redis 事务一次性可以执行多个指令， 而这多个指令通过以下的方式来保证：
在事务执行的过程中，可能遇到这几种命令执行错误：
执行前错误是指命令入队（Queue）时，Redis 就会发现并记录报错。
即使执行了 EXEC命令之后，Redis也会拒绝执行指令队列中的所有指令，返回事务失败的结果。
这样一来，所有的指令都不会被执行，保持了原子性。下面是指令入队列的报错的实例，跟上面的举例一致：
# 开启事务
> MULTI
OK
# 初始一个数据
> SET 'age' 18
OK
# 对该数据进行更新，但Redis不支持该命令，返回报错信息
> UPD 'age' 17
(error) ERR unknown command `UPD`, with args beginning with: `age`, `17`,
# 继续发送一个指令 ，降低age的值，该指令是正确的
> DECR 'age'
QUEUED
# 执行exec，但是之前有错误，所以Redis放弃了事务，不再执行
> EXEC
(error) EXECABORT Transaction discarded because of previous errors.
这个跟上面的情况正好相反，指令入Queue时，命令的类型虽然不匹配，但是并没有在预编译的时候检查出。
只有在EXEC 命令之后，实际执行指令的时候才会报错。其他正确的指令还是会执行成功，不保证原子性。 参考下面：
# 开启事务
> MULTI
OK
> set age 18
QUEUED
> set name 'brand'
QUEUED
> INCR age
QUEUED
# 这边对String类型进行DECR，没有报错，但是在执行指令的时候会报错误
> DECR name
QUEUED
# 执行，会发现其他三条执行执行成功，只有一条执行失败，返回报错信息
> EXEC
1) OK
2) OK
3) 19
4) ERR value is not an integer or out of range
# 查看结果
> get name
"brand"
> get age
"19"
可以使用AOF日志，把未完成的事务操作从AOF日志中去除，之后使用AOF进行恢复时就不会被再次执行，以此保证整个操作的原子性。
这个需要Redis启用AOF日志这个持久化能力。
跟原子性类似，一致性会受到错误指令、执行异常、Redis故障等情况的影响，主要有如下几种情况：
从隔离性这个角度，事务执行的时机可以分成两种：
如果前后有变化，说明被修改了，这时就放弃事务执行，避免事务的隔离性被破坏。
Redis 操作命令是单线程执行的，所以在EXEC 命令执行后，不会乱入其他操作，Redis 会保证把指令队列中的所有指令都操作完成之后。
在执行后续的命令，所以，这种模式并发操作不会破坏事务的隔离性。它具有天然的隔离能力。
因为Redis的持久化特性，所以有如下三种可能性：