Redis4 事务

Transaction

概念上和之前在Mysql中讲过的事务没有什么太大的区别： 将一系列的操作原子化，使他们串行化的执行。
相关命令：

Discard  #取消
exec # 执行事务
multl # 标记开启一个事务，返回OK 表示redis 接收到了这个事务开启的通知
watch key (key...) : 监控某个或者某些key 
unwatch : 取消watch 的监控

事务执行的几种情况：

1. 开启事务之后每写一条指令，就会提示你该指令已经入队（事务相当于是一个指令队列），在exec 指令执行之后执行事务指令队列中的指令。

2. 果一个事务在加入事务队列的时候就出现错误，那么在执行exec后该事务中所有的命令都无法执行

3. 如果一条指令正确的加入了事务队列但是无法正确的执行，那么执行exec 之后该条语句将无法执行报错，但是这并不影响其他事务的执行。

   从2，3 两个例子可以看出来，redis 不是绝对支持事务的，他没有SQL 那么严格，对于3 这种情况，他是冤有头债有主的执行。

4. watch 监控 ： 在事务开启之前可以对key 进行监控，如果在当前事务执行的时候检测到有其他的事务修改了监控的key 值，那么当前的事务提交会失败。

5. unwatch : 已知被监控的数据已经被其他的事务线程修改了，那么就要放弃本次的监控。从新开启事务watch multl exec

6. 一旦执行unwatch / exec 之后之前加的所有监控都会被取消。

watch 的执行原则类似乐观锁

Redist 在事务上和Mysql中的不同：
有单独的隔离操作，事务中的指令都会序列化的执行
没有类似Mysql中的隔离级别的问题，所以也就不存在那些“事务中可以查询到事务中的数据更新，但是其他事务查询看不见” 这一些列令人头大的问题
不能保证原子性，Redis 的事务不是绝对的支持事务，没有Mysql 里面那么严格（具有"那错找那"的特性）,没有回滚。

---

Redis 消息订阅发布简介

redis 可以完成消息的发布和订阅，可以作为消息中间件，但是一般在实际应用中不会将redis 作为消息中间件
知道redis 可以做这个工作就好

publish : 消息源的发布： publish key value
subscribe: 订阅源订阅 ：subscribe key1,key2...