一、Redis的发布和订阅
- Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息
- Redis 客户端可以订阅任意数量的频道
- Redis的发布订阅机制包括三个部分，发布者，订阅者和Channel
发布者和订阅者都是Redis客户端，Channel则为Redis服务器端，发布者将消息发送到某个的频道，订阅了这个频道的订阅者就能接收到这条消息。Redis的这种发布订阅机制与基于主题的发布订阅类似，Channel相当于主题。
示例
以下实例演示了发布订阅是如何工作的。在我们实例中我们创建了订阅频道名为 redisChat:
127.0.0.1:6379> subscribe redisChat
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redisChat"
3) (integer) 1
重新开启个 redis 客户端，然后在同一个频道 redisChat 发布两次消息
127.0.0.1:6379> publish redisChat "redis is a caching teching"
(integer) 1
127.0.0.1:6379> publish redisChat "hello"
(integer) 1
订阅者就能接收到消息
127.0.0.1:6379> subscribe redisChat
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redisChat"
3) (integer) 1
1) "message"
2) "redisChat"
3) "redis is a caching teching"
1) "message"
2) "redisChat"
3) "hello"
命令
下面列出了Redis 发布订阅的常用命令：
| 序号 | 命令 | 描述 |
|---|---|---|
| 1 | PSUBSCRIBE pattern [pattern ...] | 订阅一个或多个符合给定模式的频道 |
| 2 | PUBSUB subcommand [argument [argument ...]] | 查看订阅与发布系统状态 |
| 3 | PUBLISH channel message | 将信息发送到指定的频道 |
| 4 | PUNSUBSCRIBE [pattern [pattern ...]] | 退订所有给定模式的频道 |
| 5 | SUBSCRIBE channel [channel ...] | 订阅给定的一个或多个频道的信息 |
| 6 | UNSUBSCRIBE [channel [channel ...]] | 指退订给定的频道 |
Redis发布订阅与ActiveMQ的比较
- ActiveMQ支持多种消息协议，包括AMQP，MQTT，Stomp等，并且支持JMS规范，但Redis没有提供对这些协议的支持；
- ActiveMQ提供持久化功能，但Redis无法对消息持久化存储，一旦消息被发送，如果没有订阅者接收，那么消息就会丢失；
- ActiveMQ提供了消息传输保障，当客户端连接超时或事务回滚等情况发生时，消息会被重新发送给客户端，Redis没有提供消息传输保障。
总之，ActiveMQ所提供的功能远比Redis发布订阅要复杂，毕竟Redis不是专门做发布订阅的，但是如果系统中已经有了Redis，并且需要基本的发布订阅功能，就没有必要再安装ActiveMQ了，因为可能ActiveMQ提供的功能大部分都用不到，而Redis的发布订阅机制就能满足需求。
二、Redis 事务
Redis 通过 MULTI 、 DISCARD 、 EXEC 和 WATCH 四个命令来实现事务功能。事务提供了一种 将多个命令打包， 然后一次性、按顺序地执行 的机制， 并且事务在执行的期间不会主动中断 —— 服务器在执行完事务中的所有命令之后， 才会继续处理其他客户端的其他命令。
一个事务从开始到执行会经历以下三个阶段：
- 开始事务。
- 命令入队。
- 执行事务。
示例
以下是一个事务的例子， 它先以 MULTI 开始一个事务， 然后将多个命令入队到事务中， 最后由 EXEC 命令触发事务， 一并执行事务中的所有命令：
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set book "c++"
QUEUED
127.0.0.1:6379> get book
QUEUED
127.0.0.1:6379> exec
1) OK
2) "c++"
注意
- 单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的
- 事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做
命令
下表列出了 redis 事务的相关命令：
| 序号 | 命令 | 描述 |
|---|---|---|
| 1 | DISCARD | 取消事务，放弃执行事务块内的所有命令 |
| 2 | EXEC | 执行所有事务块内的命令 |
| 3 | MULTI | 标记一个事务块的开始 |
| 4 | UNWATCH | 取消 WATCH 命令对所有 key 的监视 |
| 5 | WATCH key [key ...] | 监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断 |
为什么redis事务不支持回滚
以下是这种做法的优点：
- Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中
- 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速
有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。 举个例子， 如果你本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这些情况的。
鉴于没有任何机制能避免程序员自己造成的错误， 并且这类错误通常不会在生产环境中出现， 所以 Redis 选择了更简单、更快速的无回滚方式来处理事务。
