Redis的Pub/Sub机制存在的问题以及解决方案

　　Redis的Pub/Sub机制使用非常简单的方式实现了观察者模式，但是在使用过程中我们发现，它仅仅是实现了发布订阅机制，但是很多的场景没有考虑到。例如一下的几种场景：

　　1.数据可靠性无法保证

　　一个redis_cli发送消息的时候，消息是无状态的，也就是说负责发送消息的redis_cli只管发送消息，并不会理会消息是否被订阅者接收到，也不会理会是否在传输过程中丢失，即对于发布者来说，消息是”即发即失”的。

　　2.扩展性差

　　不能通过增加消费者来加快消耗发布者的写入的数据，如果发布者发布的消息很多，则数据阻塞在通道中已等待被消费着来消耗。阻塞时间越久，数据丢失的风险越大(网络或者服务器的一个不稳定就会导致数据的丢失)

　　3.资源消耗高

　　在pub/sub中消息发布者不需要独占一个Redis的链接，而消费者则需要单独占用一个Redis的链接，在java中便不得独立出分出一个线程来处理消费者。这种场景一般对应这多个消费者，此时则有着过高的资源消耗。

　　对于如上的几种不足，如果在项目中需要考虑的话可以使用JMS来实现该功能。JMS提供了消息的持久化/耐久性等各种企业级的特性。如果依然想使用Redis来实现并做一些数据的持久化操作，则可以根据JMS的特性来通过Redis模拟出来.

　　模拟的步骤如下：
　　1.subscribe端首先向一个Set集合中增加“订阅者ID”，此Set集合保存了“活跃订阅”者，订阅者ID标记每个唯一的订阅者，例如：sub:email,sub:web。此SET称为“活跃订阅者集合”

　　2.subcribe端开启订阅操作，并基于Redis创建一个以“订阅者ID”为KEY的LIST数据结构，此LIST中存储了所有的尚未消费的消息。此LIST称为“订阅者消息队列”

　　3.publish端：每发布一条消息之后，publish端都需要遍历“活跃订阅者集合”，并依次向每个“订阅者消息队列”尾部追加此次发布的消息。到此为止，我们可以基本保证，发布的每一条消息，都会持久保存在每个“订阅者消息队列”中。

　　4.subscribe端，每收到一个订阅消息，在消费之后，必须删除自己的“订阅者消息队列”头部的一条记录。subscribe端启动时，如果发现自己的自己的“订阅者消息队列”有残存记录，那么将会首先消费这些记录，然后再去订阅。

　　实现如下：

public class PubSubListener extends JedisPubSub{

    private String clientId;
    private RedisHandler redisHandler;

    public PubSubListener(String clientId, Jedis jedis) {
        this.clientId = clientId;
        this.redisHandler = new RedisHandler(jedis);
    }

    @Override
    public void onMessage(String channel, String message) {
        if ("exit".equals(message)) {
            redisHandler.onUnsubscribe(channel);
        }

        redisHandler.hanlder(channel,message);
    }

    @Override
    public void onS