事务四大特征：原子性，一致性，隔离性和持久性(ACID)

转载链接
事务四大特征：原子性，一致性，隔离性和持久性。
1. 原子性（Atomicity）
一个原子事务要么完整执行，要么干脆不执行。这意味着，工作单元中的每项任务都必须正确执行。如果有任一任务执行失败，则整个工作单元或事务就会被终止。即此前对数据所作的任何修改都将被撤销。如果所有任务都被成功执行，事务就会被提交，即对数据所作的修改将会是永久性的。
2. 一致性（Consistency）
一致性代表了底层数据存储的完整性。它必须由事务系统和应用开发人员共同来保证。事务系统通过保证事务的原子性，隔离性和持久性来满足这一要求; 应用开发人员则需要保证数据库有适当的约束(主键，引用完整性等)，并且工作单元中所实现的业务逻辑不会导致数据的不一致(即，数据预期所表达的现实业务情况不相一致)。例如，在一次转账过程中，从某一账户中扣除的金额必须与另一账户中存入的金额相等。
3. 隔离性（Isolation）
隔离性意味着事务必须在不干扰其他进程或事务的前提下独立执行。换言之，在事务或工作单元执行完毕之前，其所访问的数据不能受系统其他部分的影响。
4. 持久性（Durability）
持久性表示在某个事务的执行过程中，对数据所作的所有改动都必须在事务成功结束前保存至某种物理存储设备。这样可以保证，所作的修改在任何系统瘫痪时不至于丢失。

Redis 提供的事务机制与传统的数据库事务有些不同，传统数据库事务必须维护以下特性：原子性(Atomicity), 一致性(Consistency), 隔离性(Isolation), 持久性(Durability)，简称ACID。
我们逐项考察下 Redis 在事务的 ACID 上做出的权衡与取舍：

原子性(Atomicity)
原子意味着操作的不可再分，要么执行要么不执行。Redis 本身提供的所有 API 都是原子操作，那么 Redis 事务其实是要保证批量操作的原子性。Redis 实现批量操作的原理是在一个事务上下文中（通过 MULTI命令开启），所有提交的操作请求都先被放入队列中缓存，在 EXEC 命令提交时一次性批量执行。这样保证了批量操作的一次性执行过程，但 Redis 在事务执行过程的错误情况做出了权衡取舍，那就是放弃了回滚。
Redis 官方文档对此给出的解释是：

Redis 操作失败的原因只可能是语法错误或者错误的数据库类型操作，这些都是在开发层面能发现的问题不会进入到生产环境，因此不需要回滚。
Redis 内部设计推崇简单和高性能，因此不需要回滚能力。
据实而说第一条说法感觉有点站不住脚，可以想象得到 Redis 操作失败的原因绝对不止语法层面的错误，特别是一些像依赖操作系统、文件系统的操作。第二条说法更实在，Redis 的应用场景明显不是为了数据存储的高可靠而设计的，而是为了数据访问的高性能而设计，设计者为了简单性和高性能而部分放弃了原子性。
出于以上考虑 Redis 的事务执行有以下特点：

批量操作在发送 EXEC 命令前被放入队列缓存
收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行
在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中

一致性(Consistency)
一致性意味着事务结束后系统的数据依然保证一致。在事务开始之前，数据保持有效的状态，事务结束后也如此。显然在前面讨论原子性时，Redis
舍弃了回滚的设计，基本上也就舍弃对数据一致性的有效保证。不过对于一个高效的 key-value store 或 data structure server，数据操作一致性很多时候更多应该依赖应用层面，事实也是我们使用 Redis 时很多时候都是分片和集群的，数据一致性无法依靠任何事务机制。

隔离性(Isolation)
隔离性保证了在事务完成之前，该事务外部不能看到事务里的数据改变。也不能访问一些中间状态，因为假如事务终止的话，这些状态将永远不会发生。Redis 采用单线程设计，在一个事务完成之前，其他客户端提交的各种操作都无法执行因此自然没法看见事务执行的中间状态，隔离性得到保证。

持久性(Durability)
Redis 一般情况下都只进行内存计算和操作，持久性无法保证。但 Redis 也提供了2种数据持久化模式，SNAPSHOT 和 AOF，SNAPSHOT的持久化操作与命令操作是不同步的，无法保证事务的持久性。而AOF模式意味着每条命令的执行都需要进行系统调用操作磁盘写入文件，可以保证持久性，但会大大降低
Redis 的访问性能。

Redis 在2.6版本开始提供脚本（Lua scripting）能力，一种更灵活的批量命令组织方式用于取代目前的事务机制。脚本提供了更强大和灵活的编程能力，但也是一把双刃剑，由于 Redis 需要保证脚本执行的原子性和隔离性，脚本执行期间会阻塞其他命令的执行，因此建议写一些高效的脚本。不过从开发者的角度来说使用Lua脚本的成本（学习成本、开发成本、维护成本）都要更大，特别是一些开发者如果将应用的业务逻辑放入脚本中来执行，是不是让人想起了数据库的存储过程。