redis的Pub/Sub机制类似于广播架构，Subscriber相当于收音机，可以收听多个channel(频道)，Publisher（电台）可以在channel中发布信息。
架构
redis-pub-sub 架构
示例
redis-pub-sub
优缺点
数据可靠性无法保证(无msg id 无法实现发现幂等性，无法重试)
一个redis-cli发布消息n个redis-cli接受消息。消息的发布是无状态的，即发布完消息后该redis-cli不在理会该消息是否被接受到，是否在传输过程中丢失，即对于发布者来说，消息是"即发即失"的.扩展性太差
不能通过增加消费者来加快消耗发布者的写入的数据,吐吞较低，如果发布者发布的消息很多，则数据阻塞在通道中已等待被消费着来消耗。阻塞时间越久，数据丢失的风险越大(网络或者服务器的一个不稳定就会导致数据的丢失)
- 资源消耗较高
在pub/sub中消息发布者不需要独占一个Redis的链接，而消费者则需要单独占用一个Redis的链接，在java中便不得独立出分出一个线程来处理消费者。这种场景一般对应这多个消费者，此时则有着过高的资源消耗。
roket mq
rocket mq 架构
