个人对Redis pub/sub机制在实际运用场景的理解

Redis 的pub/sub机制与23种设计模式中的观察者设计模式极为类似。但Redis对于这个机制的实现更为轻便和简结，没有观察者模式的那么复杂的逻辑考虑而仅仅需要通过两个Redis客户端配置channel即可实现，因此它也仅仅做了消息的"发布"和"订阅"的实现，而在实际处理这类场景时遇到的情况根本没有考虑到。

数据可靠性无法保证
一个redis-cli发布消息n个redis-cli接受消息。消息的发布是无状态的，即发布完消息后该redis-cli便在理会该消息是否被接受到，是否在传输过程中丢失，即对于发布者来说，消息是"即发即失"的.

扩展性太差

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

资源消耗较高

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

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

• subscribe端首先向一个Set集合中增加“订阅者ID”，此Set集合保存了“活跃订阅”者，订阅者ID标记每个唯一的订阅者，例如：sub:email,sub:web。此SET称为“活跃订阅者集合”
• subcribe端开启订阅操作，并基于Redis创建一个以“订阅者ID”为KEY的LIST数据结构，此LIST中存储了所有的尚未消费的消息。此LIST称为“订阅者消息队列”
• publish端：每发布一条消息之后，publish端都需要遍历“活跃订阅者集合”，并依次向每个“订阅者消息队列”尾部追加此次发布的消息。
• 到此为止，我们可以基本保证，发布的每一条消息，都会持久保存在每个“订阅者消息队列”中。
• subscribe端，每收到一个订阅消息，在消费之后，必须删除自己的“订阅者消息队列”头部的一条记录。
• subscribe端启动时，如果发现自己的自己的“订阅者消息队列”有残存记录，那么将会首先消费这些记录，然后再去订阅。