发布/订阅”（publish/subscribe）模式可以实现进程间通信，订阅者可以订阅一个或多个频道（channel），而发布者可以向指定的频道发送消息，所有订阅次频道的订阅者都会收到次消息。
比如说，可是实现系统之间的解耦，比如说注册发送短信消息，发短信和我注册的逻辑是没有关系的，它并不是特别的重要，而且它可能是一种比较繁琐的工作，因为它要、
调用第三方短信接口，它有失败的风险，总之它和我们的系统没有什么关系，我们要的是专注于我们的业务逻辑，对于发短信成不成功，我不管，如果发短信失败了，让用户重试就可以了，
短信的失败并不会影响我们系统的正常运行。跟我们业务逻辑没关系的，我们就把它独立出去，交给一个短信系统去做，一个专注与业务逻辑，一个专门发短信去，这样就算失败了，也不影响我们的业务逻辑。这样
可以达到异步解耦。这是分布式一个重要的概念。想想如果我们不解耦会发生什么后果？如果将来有一天我们要维护短信模块，那么我们岂不是要关闭发短信的服务器，去修改其代码，如果没有异步解耦，那么我们的
业务逻辑那块也不能正常运行下去了。
2.1 命令实践
PUBLISH：
将信息 message 发送到指定的频道 channel。返回收到消息的客户端数量。
-
- SUBSCRIBE：
-
-
-
- 一旦客户端进入订阅状态，客户端就只可接受订阅相关的命令SUBSCRIBE、PSUBSCRIBE、UNSUBSCRIBE和PUNSUBSCRIBE除了这些命令，其他命令一律失效。
- UNSUBSCRIBE：
- 取消订阅指定的频道，如果不指定，则取消订阅所有的频道。
-
-
127.0.0.1:6379> PUBLISH channel1.1 test (integer) 0 //有0个客户端收到消息 127.0.0.1:6379> SUBSCRIBE channel1.1 Reading messages... (press Ctrl-C to quit) 1) "subscribe" //"subscribe"表示订阅成功的信息 2) "channel1.1" //表示订阅成功的频道 3) (integer) 1 //表示当前订阅客户端的数量 //当发布者发布消息时，订阅者会收到如下消息 1) "message" //表示接收到消息 2) "channel1.1" //表示产生消息的频道 3) "test" //表示消息的内容 //当订阅者取消订阅时会显示如下： 127.0.0.1:6379> UNSUBSCRIBE channel1.1 1) "unsubscribe" //表示成功取消订阅 2) "channel1.1" //表示取消订阅的频道 3) (integer) 0 //表示当前订阅客户端的数量 //注：在redis-cli中无法测试UNSUBSCRIBE命令
-
-
- 首先，开启3个redis-client，2个订阅一个相同的频道，一个发布消息如下图：
-
然后现在我们回车，可以看到所有订阅者都收到了频道发来的消息，如下图：
在java代码中的实现：
1.首先实现一个JedisPubSub抽象类的如下图：
2.连接redis，并且订阅频道如下图：
3.再建立一个新的工程，作为发布消息端，如下图：
4.先启动订阅端的工程，线程会阻塞在哪里，等待消息到来，如下图：
5.再启动发布消息端如下图：
可以看到订阅者收到消息了。
Redis发布订阅与ActiveMQ的比较
（1）ActiveMQ支持多种消息协议，包括AMQP，MQTT，Stomp等，并且支持JMS规范，但Redis没有提供对这些协议的支持；
（2）ActiveMQ提供持久化功能，但Redis无法对消息持久化存储，一旦消息被发送，如果没有订阅者接收，那么消息就会丢失；
（3）ActiveMQ提供了消息传输保障，当客户端连接超时或事务回滚等情况发生时，消息会被重新发送给客户端，Redis没有提供消息传输保障。
总之，ActiveMQ所提供的功能远比Redis发布订阅要复杂，毕竟Redis不是专门做发布订阅的，但是如果系统中已经有了Redis，并且需要基本的发布订阅功能，就没有必要再安装ActiveMQ了，因为可能ActiveMQ提供的功能大部分都用不到，而Redis的发布订阅机制就能满足需求。
