Redis教程（十）事务功能与发布订阅
一、Redis事务功能
Redis对于事务的处理比较简单，只能保证一个客户端发起的事务中的命令的连续执行，中间不会插入其他客户端的命令，但不能保持数据的强一致性。比如执行的10个命令中有1个失败，另外9条是依然能成功执行的，并不会像MySQL一样被回滚
· 开启事务方法
客户端执行multi命令可以开启事务，后续执行的命令都会提交到一个队列中，当客户端发起exec命令才会正式去执行队列中的命令。如果在事务正式执行前需要取消，使用discard命令可以取消队列中的所有命令
127.0.0.1:6379>multi #开启事务，后续命令会进入QUEUED队列，直到提交 127.0.0.1:6379>set key1 val1 QUEUED 127.0.0.1:6379>set key2 val2 QUEUED 127.0.0.1:6379>exec 1) ok 2) ok
· mysql和redis事务命令对比
| 开启事务 | start transaction\begin | multi |
| 事务失败回滚 | rollback | discard |
| 提交事务 | commit | exec |
在Redis的事务操作中也有锁机制，用来监视指定的key，如果被监视的key发生过修改，那么事务就不会执行。所使用到的客户端命令是watch。在发起muliti事务前先执行watch命令，指定需要监视的key，然后再开启事务进行一系列的数据操作，最后执行exec命令。这个时候watch就会进行一次判断
watch student #监视student这个key multi set student 10 exec #如果监视期间这个key发生了变化，此时exec将返回nil，代表事务失败
注意：Redis对事务的支持是比较简单的，相比MySQL只要事务中有一处地方产生错误，那么整个事务就不会执行，而会进行回滚。Redis没有回滚机制，事务中的操作会按顺序依次执行下去。比如我们的事务队列中第5条操作是对一个字符串进行incr自增（字符串不是数字，无法自增，所以是错误操作），最后执行exec结果会怎么样？会发现其他正确的操作是执行成功了，只有这个错误的自增操作失败了，而这个错误操作之后的数据依然在依次执行。这个是会产生严重后果的，比如账户金额的增减问题，所以一定要注意。
二、Redis发布与订阅
发布订阅是一种消息通信模式，由发送者发送消息，订阅者来接收消息，可以订阅任意数量的频道。工作流程大概就是：当有新消息发送给某频道时，这个消息就会被立即发送给订阅它的客户端们。在Redis 5以前，发布订阅模式存在无法持久化保存消息的缺点，如果 Redis宕机或重启，消息将会丢失。如果订阅者断开重连，也不能消费之前的历史消息。通过LIST或者ZSET类型也可以实现消息队列的功能，但是各自也都存在一些问题，直到Redis 5以后Stream数据类型的出现实现了解决。
Redie发布订阅的命令格式如下
subscribe channel1 [channel2...] #订阅一个或多个频道 psubscribe pattern1 [pattern2...] #通过通配符形式来订阅多个名称相似的频道 publish channel1 message #给某频道发布消息
示例：
需要执行订阅的客户端连上Redis服务后，执行订阅命令
subscribe channelname #这里的channelname就是需要订阅的频道名
需要执行发布的客户端连上Redis服务后，执行发布命令，返回的数值是已订阅者的数量
publish channelname message #channelname就是发布到的频道，message就是需要发布的内容
这个时候查看所有订阅过该频道的客户端，都会收到对应的消息了，如图：
评论