Redis笔记2-发布订阅

发布/订阅”(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的发布订阅机制就能满足需求。

posted @ 2018-03-01 01:43  妮蔻  阅读(...)  评论(...编辑  收藏