2020 Redis实战【4】管道 Pipelining， 发布与订阅 Pub/Sub， 事物 Transactions

管道 Pipelining

redis官网说了管道Pipelining的意思，但是在我理解来看Pipelining这个功能通过批量提交完成对应的功能并返回；之所以这么做是可以减少通信之间的消耗以及等待的时间。就好比数据库批量执行sql一样。
redis的client也是可以通过socket来完成批量的提交。对于redis批量请求的处理是根据换行符来判定的。一个换行符就是一个命令。一次的数据流提交里面只要包含了多次换行，那么在redis中就认为这次请求有批量的命令来请求。这样对于单线程的redis则会顺序的执行完成，中间也不会发生切换等其他问题。这里也要说明一下windows下的换行符合Linux的换行符是不一样的。

发布与订阅 Pub/Sub

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。
Redis 客户端可以订阅任意数量的频道。

定义

订阅，取消订阅和发布实现了发布/订阅消息范式(引自wikipedia)，发送者（发布者）不是计划发送消息给特定的接收者（订阅者）。而是发布的消息分到不同的频道，不需要知道什么样的订阅者订阅。订阅者对一个或多个频道感兴趣，只需接收感兴趣的消息，不需要知道什么样的发布者发布的。这种发布者和订阅者的解耦合可以带来更大的扩展性和更加动态的网络拓扑。

命令及描述

• PSUBSCRIBE pattern [pattern …]
  订阅一个或多个符合给定模式的频道。
• PUBSUB subcommand [argument [argument …]]
  查看订阅与发布系统状态。
• PUBLISH channel message
  将信息发送到指定的频道。
• PUNSUBSCRIBE [pattern [pattern …]]
  退订所有给定模式的频道。
• SUBSCRIBE channel [channel …]
  订阅给定的一个或多个频道的信息。
• UNSUBSCRIBE [channel [channel …]]
  指退订给定的频道。

事物Transactions

redis 作为缓存数据库也是有事物存在的。事务可以一次执行多个命令， 并且带有以下两个重要的保证：

• 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

事物的开启

MULTI 开启一个事物 ，默认都是返回OK。一般正常情况下的失败都是多次开启事物会出现 (error) ERR MULTI calls can not be nested 的错误

事物提交

EXEC 提交事物中的命令。类似于数据库的commit功能。当事物开启后批量执行若，反之没有开启事物执行会报错 (error) ERR EXEC without MULTI

事物的取消

DISCARD 事物取消命令。开启事物以后，输入多条命令以后，不愿意执行时执行discard 命令。终止事物，而输入的多条命令也不会执行

注意项

当开启多个事物时，批量执行的命令会被放入到个子client链接的一个queue中，只有当执行exec的时候才会被redis批量运行。具体那个client优先执行是根据redis优先收到那个client的exec为基准，而与MULTI的先后顺序没有任何关系；所以当多个事物同时操作一个key时，具体那个事物先执行批量操作对key执行是根据exec的先后顺序的；假如，client1 开启事物先输入了get k1的命令【即放入自己的queue 】，client2 后开启事物后输入了del k1的命令，但是client2优先于client1执行了exec或者说client2的exec优先被redis执行那么后执行exec的client1的get k1会报错。