Hello Redis，我有7个问题想请教你( 二 ) _Redis

文章插图

依然去执行一个错误的事务，在事务执行的过程中会识别出来并进行错误处理，这些错误并不会对数据库作出修改，也不会对事务的一致性产生影响。
②宕机对一致性的影响
暂不考虑分布式高可用的 Redis 解决方案，先从单机看宕机恢复是否能满意数据完整性约束。
无论是 RDB 还是 AOF 持久化方案，可以使用 RDB 文件或 AOF 文件进行恢复数据，从而将数据库还原到一个一致的状态。
③再议一致性
上面执行错误和宕机对一致性的影响的观点摘自黄健宏《Redis 设计与实现》。
当在读这章的时候还是有一些存疑的点，归根到底 Redis 并非关系型数据库。
【Hello Redis，我有7个问题想请教你】如果仅仅就 ACID 的表述上来说，一致性就是从 A 状态经过事务到达 B 状态没有破坏各种约束性，仅就 Redis 而言不谈实现的业务，那显然就是满意一致性。
但如果加上业务去谈一致性，例如，A 转账给 B，A 减少 10 块钱，B 增加 10 块钱，因为 Redis 并不具备回滚，也就不具备传统意义上的原子性，所以 Redis 也应该不具备传统的一致性。
其实，这里只是简单讨论下 Redis 在传统 ACID 上的概念怎么进行对接，或许，有可能是我想多了，用传统关系型数据库的 ACID 去审核 Redis 是没有意义的，Redis 本来就没有意愿去实现 ACID 的事务。
隔离性
隔离性指的是，数据库中有多个事务并发的执行，各个事务之间不会相互影响，并且在并发状态下执行的事务和串行执行的事务产生的结果是完全相同的。
Redis 因为是单线程操作，所以在隔离性上有天生的隔离机制，当 Redis 执行事务时，Redis 的服务端保证在执行事务期间不会对事务进行中断，所以，Redis 事务总是以串行的方式运行，事务也具备隔离性。
持久性
事务的持久性指的是，当一个事务执行完毕，执行这个事务所得到的结果被保存在持久化的存储中，即使服务器在事务执行完成后停机了，执行的事务的结果也不会被丢失。
Redis 是否具备持久化，这个取决于 Redis 的持久化模式：

纯内存运行，不具备持久化，服务一旦停机，所有数据将丢失。
RDB 模式，取决于 RDB 策略，只有在满足策略才会执行 Bgsave，异步执行并不能保证 Redis 具备持久化。
AOF 模式，只有将 Appendfsync 设置为 always，程序才会在执行命令同步保存到磁盘，这个模式下，Redis 具备持久化。(将 appendfsync 设置为 always，只是在理论上持久化可行，但一般不会这么操作)

简单总结：

Redis 具备了一定的原子性，但不支持回滚。
Redis 不具备 ACID 中一致性的概念。(或者说 Redis 在设计时就无视这点)
Redis 具备隔离性。
Redis 通过一定策略可以保证持久性。

Redis 和 ACID 纯属站在使用者的角度去思想，Redis 设计更多的是追求简单与高性能，不会受制于传统 ACID 的束缚。
Redis 的乐观锁 Watch 是怎么实现的
当我们一提到乐观锁就会想起 CAS(Compare And Set)，CAS 操作包含三个操作数：

内存位置的值(V)
预期原值(A)
新值(B)

如果内存位置的值与预期原值相匹配，那么处理器会自动将该位置更新为新值。否则，处理器不做任何操作。
在 Redis 的事务中使用 Watch 实现，Watch 会在事务开始之前盯住 1 个或多个关键变量。
当事务执行时，也就是服务器收到了 exec 指令要顺序执行缓存的事务队列时，Redis 会检查关键变量自 Watch 之后，是否被修改了。

文章插图

①JAVA 的 AtomicXXX 的乐观锁机制
在 Java 中我们也经常的使用到一些乐观锁的参数，例如 AtomicXXX，这些机制的背后是怎么去实现的，是否 Redis 也跟 Java 的 CAS 实现机制一样?
先来看看 Java 的 Atomic 类，我们追一下源码，可以看到它的背后其实是
Unsafe_CompareAndSwapObject：