Redis的事务-->部分支持
Redis通过MULTI、EXEC、WATCH等命令来实现事务功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求
DISCARD 取消事务，销毁队列，过程中
事务操作的注意事项：
输错命令：如果命令语法错误，事务中所有命令都不执行
语法没问题，但执行操作有问题，则事务中正确的命令可以执行-->手动进行事务回滚
手动进行事务回滚：
记录操作过程中被影响的数据之前的状态：
设置指令恢复所有的被修改的项
在传统的关系式数据库中，常常用ACID性质来检验事务功能的可靠性和安全性。在Redis中，事务总是具有原子性、一致性、隔离性，并且当Redis运行在某种特定的持久化模式下时，事务也具有持久性。
是什么：可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其他命令插入，不许加塞。
能干什么：一个队列中，一次性、顺序性、排他性的执行一系列命令
怎么玩：开启/进入一个事务 MULTI EXEC执行所有 Discard不执行
常用命令：DISCARD、EXEC、MULTI、UNWATCH、WATCH key [key...]
Case1：正常执行 MULTI EXEC
Case2：放弃事务 MULTI DISCARD
Case3：全体连坐 事务中有一条语句错误（执行过程中报错），则EXEC后全部失败
Case4：冤头债主 事务中有一条语句有错误，但返回QUEUED，则EXEC后只有这一条语句失败
锁！-->Case5：watch监控 检测到有人改了，事务失败；没有其他人修改，事务执行成功；监视一个（或多个）key，如果在事务执行之前这个（或这些）key被其他命令所改动，那么事务将被打断 必须在事务开启之前watch
unwatch 取消对所有key的监视
悲观锁/乐观锁/CAS（Check And Set）：悲观锁，认为别人一定会改，加锁；乐观锁每次取数据都认为别人不会修改，所以不会上锁，但在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。乐观锁策略：提交版本必须大于记录当前版本才能执行更新
初始化信用卡可用余额和欠额
无加塞篡改，先监控再开启multi，保证两笔金额变动在同一个事务内：
有加塞篡改
unwatch
一旦执行了exec之前加的监控锁都会被取消掉了
小结：
Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行
通过WATCH命令在事务执行之前监控了多个keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败
分布式锁：使用setnx设置一个公共锁，锁一个对应的key；效果：原来有值，不让改，如果没值，可以改
所有人都可以使用，并且当前有人使用时，其他人不能使用 setnx lock-key value
利用setnx命令的返回值特征，有值则返回设置失败，无值则返回设置成功
对于返回设置成功的，拥有控制权，进行下一步的具体业务操作
对于返回设置失败的，不具有控制权，排队或等待
操作完毕通过del操作释放锁
死锁解决方案：获取锁的机器宕机了？忘记解锁了?
解决方案：设置过期时间 expire lock-key second pexpire lock-key milliseconds
事务的三阶段
开启：以MULTI开始一个事务
入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
执行：由EXEC命令触发事务
三特性：
Redis的发布订阅
是什么：进程间的一种消息通信模式，发送者pub发送消息，订阅者sub接收消息；订阅/发布消息图
命令 PUBLISH发布 SUBSCRIBE订阅
案例 先订阅后发布后才能收到消息
可以一次性订阅多个，SUBSCRIBE c1 c2 c3
消息发布， PUBLISH c2 hello-redis
订阅多个，通配符*，PSUBSCRIBE new*
收取消息，PUBLISH new1 redis2015