你的需求更适合用redis中list数据结构吧。入队列时用lpush，拿数据时用brpop。
pub/sub适合用来做实时的事件广播，比如
说，主业务流程完成了一次操作，把日志publish到redis的一个channel中。其他有多少个地方需要关注、处理这个日志，主业务流程完全不需
要关心。需要用这个日志的进程只需要subscribe这个channel就好了
JMS规范目前支持两种消息模型：点对点（point to point， queue）和发布/订阅（publish/subscribe，topic）。
点对点：
消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。这里要注意：
消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。
Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
生产者发送一条消息到queue，只有一个消费者能收到。
发布/订阅
消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。
发布者发送到topic的消息，只有订阅了topic的订阅者才会收到消息。
queue实现了负载均衡，一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有 一个可用的消费者，一个queue可以有很多消费者，他们之间实现了负载均衡，
所以Queue实现了一个可靠的负载均衡。
topic实现了发布和订阅，当你发布一个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到一个消息的拷贝，
只有在消息代理收到消息时有一个有效订阅时的订阅者才能得到这个消息的拷贝。
发布订阅模式下，能否实现订阅者负载均衡消费呢？当发布者消息量很大时，显然单个订阅者的处理能力是不足的。实际上现实场景中是多个订阅者节点组成一个订阅组负载均衡消费topic消息即分组订阅，
这样订阅者很容易实现消费能力线性扩展。
参考：https://blog.csdn.net/lizhitao/article/details/47723105
区别一、前者通过key队列方式实现，取出就删掉了，其他进程也取不到，阻塞进程。订阅发布可以支持多客户端获取同一个频道发布的消息。
区别二、前者消息不处理会缓存在列表，后者不处理的话消息就丢失了。
BRPOP和BLPOP实现阻塞时消息队列时，当获取到数据后会自动断开，如果你想要持续获取就需要自己在程序设计时添加监听，而subscribe和publish则不会出现这样的情况，订阅端自己本身就会时刻监听发送端。