redis事务基本实现
Redis 可以通过 MULTI，EXEC，DISCARD 和 WATCH 等命令来实现事务(transaction)功能。
> MULTI OK > SET USER "Guide哥" QUEUED > GET USER QUEUED > EXEC 1) OK 2) "Guide哥"
使用 MULTI命令后可以输入多个命令。Redis 不会立即执行这些命令，而是将它们放到队列，当调用了EXEC命令将执行所有命令。过程如下：
- 开始事务（MULTI）。
- 命令入队(批量操作 Redis 的命令，先进先出（FIFO）的顺序执行)。
- 执行事务(EXEC)。
你也可以通过 DISCARD 命令取消一个事务，它会清空事务队列中保存的所有命令。
> MULTI OK > SET USER "Guide哥" QUEUED > GET USER QUEUED > DISCARD OK
WATCH 命令用于监听指定的键，当调用 EXEC 命令执行事务时，如果一个被 WATCH 命令监视的键被修改的话，整个事务都不会执行，直接返回失败。
> WATCH USER OK > MULTI > SET USER "Guide哥" OK > GET USER Guide哥 > EXEC ERR EXEC without MULTI
Redis 官网相关介绍 https://redis.io/topics/transactions 如下：
但是，Redis 的事务和我们平时理解的关系型数据库的事务不同。我们知道事务具有四大特性： 1. 原子性，2. 隔离性，3. 持久性，4. 一致性。
- 原子性（Atomicity）： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
- 隔离性（Isolation）： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；
- 持久性（Durability）： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。
- 一致性（Consistency）： 执行事务前后，数据保持一致，多个事务对同一个数据读取的结果是相同的；
首先原子性的定义：事务中的命令要么全部被执行，要么全部都不执行。
然后再看官方文档关键段：
Redis commands can fail during a transaction, but still Redis will execute the rest of the transaction instead of rolling back Redis 在事务失败时不进行回滚，而是继续执行余下的命令
我根据Redis文档理解，认为事务过程中失败有两种可能：
- Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令中用在了错误类型的键上面，所以如果在生产环境中你使用的正常命令，那么在 Redis 事务中，是不会出现错误而导致回滚的。
来自文档：Redis commands can fail only if called with a wrong syntax...
- 事务执行一半，Redis宕机。如果 Redis 服务器因为某些原因被管理员杀死，或者遇上某种硬件故障，那么可能只有部分事务命令会被成功写入到磁盘中。如果 Redis 在重新启动时发现 AOF 文件出了这样的问题，那么它会退出，并汇报一个错误。使用redis-check-aof程序可以修复这一问题：它会移除 AOF 文件中不完整事务的信息，确保服务器可以顺利启动
注意：
- 若在事务队列中存在命令性错误（类似于java编译性错误），则执行EXEC命令时，所有命令都不会执行
- 若在事务队列中存在语法性错误（类似于java的1/0的运行时异常），则执行EXEC命令时，其他正确命令会被执行，错误命令抛出异常。
Redis 官网也解释了自己为啥不支持回滚。简单来说就是 Redis 开发者们觉得没必要支持回滚，这样更简单便捷并且性能更好（回滚还需要解决回滚事务覆盖的问题）。Redis 开发者觉得即使命令执行错误也应该在开发过程中就被发现而不是生产过程中。
你可以将 Redis 中的事务就理解为 ：Redis 事务提供了一种将多个命令请求打包的功能。然后，再按顺序执行打包的所有命令，并且不会被中途打断。
分布式事务锁
基础知识：
- 分布式：简单来说就是将业务进行拆分，部署到不同的机器来协调处理，保证高性能。比如用户在网上买东西，大致分为：订单系统、库存系统、支付系统、、、、这些系统共同来完成用户买东西这个业务操作。
- 集群：同一个业务，通过部署多个实例来完成，保证应用的高可用。如果其中某个实例挂了，业务仍然可以正常进行，通常集群和分布式配合使用。来保证系统的高可用、高性能。
- 分布式事务：按照传统的系统架构，下单、扣库存等等，都是在单机系统中, 这一系列的操作都是一个数据库中完成的，也就是说保证了事务的ACID特性。如果在分布式应用中就会涉及到跨应用、跨库。这样就涉及到了分布式事务，就要考虑怎么保证这一系列的操作要么都成功要么都失败。保证数据的一致性。
- 分布式锁：因为资源有限，要通过互斥来保持一致性，比如下订单的数据库操作和支付的数据库操作就是一个保证互斥性, 不能同时去执行, 不然那就会出现一旦支付出现失败, 那么下订单也得重新下订单, 这就不合理了, 所以引入分布式事务锁。
分布式事务锁：
- 分布式锁是控制分布式系统之间同步访问共享资源的一种方式。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下，便需要使用到分布式锁。
- 简单来说就是好几个节点访问一个资源, 那我就是使用额外的锁机制互斥的只让其中一个能进行访问
核心思想：
- 在被保护的redis节点加一把锁, 让这把锁和被保护的redis节建立直接映射
- 在访问这个redis之前都去看看这把锁在不在
- 如果不存在锁，说明没有客户端使用，可以执行任务，执行完毕，解锁，删除锁 (并且要保证判断有无锁和加锁是原子操作)
- 如果存在锁，则认为有其他客户端在使用，等待锁消失
基本操作：
- Redis中可以使用SETNX命令实现分布式锁，SETNX——SET if Not exists（如果不存在，则设置）
setnx key value
- 如果需要解锁，使用 del key 命令就能释放锁
分布式锁存在的问题，解决方案
Q1:当一个客户端上锁之后服务宕机，由于锁是他上的只有他可以进行redis访问的,别人无法访问，所以导致锁无法被删除.
A1:给锁设置一个过期时间，可以通过两种方法实现：通过命令 “setnx 键名 过期时间 “；或者通过设置锁的expire(失效)时间，让Redis去删除锁。
Q2:当一个客户端设置了锁的失效时间, 但是这个客户端并没有宕机, 只是真的需要那么多时间来进行操作，也就是任务执行过长，超过过期时间。
A2:实际是通过客户端的一个守护线程，大概时间快到的时间给线程续命。
Q3:任务执行造成死循环，会造成无限续命
A3:设置最大续命时间, 或者设置最大续命次数
