redis: transactions（事务）

redis:transactions的保证

Atomic ： 事务commands队列原子执行

不支持 roll backs： 不支持错误回滚

redis:事务， 不能用 关系型数据库的 事务acid的特性来要求 redis事务

redis仅仅保证事务的Atomic：原子性。

redis是单线程的， 多个clients的请求，都存放在一个请求队列中， 同一时间
redis 仅仅 执行其中一个 Atomic operations

因此 redis在执行 事务的时候， 保证了 隔离性。

当事务执行中 error发生：

It's important to note that even when a command fails, all the other commands in the queue are processed – Redis will not stop the processing of commands.

当发生错误时， 依然会继续往下执行， 直到整个事务被执行完成。

redis事务： 场景一：在一个事务中， 当后一个或后多个 commands 依赖于 前一个或前几个commands

因为redis事务作为原子操作是在Redis中执行的， 并不会和clients有交互，
当出现上述情况的时候， 怎么保证数据的正确性呢？

引入 watch
利用 optimistic locks来解决，
代码示例

使用 redis: optimistic locks： watch 的不足呢？

watch 监视的整个key的数据， 对于 key的值类型是 lists, sets, zsets, hashes 的类型的值，
watch的锁粒度太大， 会导致 collision的概率比较大， 最终导致代码的执行效率很低：
因为如果被监视key对应的value的值被修改， 即 collision发生， 那么clients就会在一定时间内（5s）反复尝试， 这样浪费了性能， 降低了程序的执行效率。

如何解决降低 collision的概率，以实现提高程序的执行效率呢？
方案一： 降低锁粒度：分布式锁

将redis的乐观锁和小粒度锁 与 关系型数据库做类比：
从锁粒度，而不是 共享和独占锁的角度考虑：

“表级锁”
关系型数据库的“表级锁”(独占锁) ：redis的乐观锁（watch）

“行级锁”
关系型数据库中的“行级锁” ： 利用redis实现小粒度的 分布式锁

分布式锁：粒度可控（可以是“表级锁”，也可以是“行级锁”）

具体是“表级锁”还是“行级锁”，并没有代码上的区分， 有的只有业务逻辑上的区分：
举例：
根据锁 key 的不同， 就可以实现 “表级锁” 和“行级锁”

如何借助 redis 实现 分布式锁呢？
分布式锁的要求有哪些呢？
分布式锁可用出现的问题呢？

当分布式锁的粒度小， 可能会产生死锁的情况

分布式锁，要先获取锁， 执行操作， 再释放锁， 如果获取锁的clients挂了呢？或者长时间占有锁呢？ 锁超时的问题

当clients在超时时间内还未完成操作， 锁被超时释放， 也会导致问题

当多个clients同时在竞争锁， 如何移除race conditions?