今天老哥让我用redis的pub/sub搞个消息队列，之前就用过但发现用redisCommand执行subscribe时它不阻塞！那这还玩个冒险啊 然后我就各种查资料和开动我的猪脑筋哈哈，先说结论： pub/sub不适合做消息队列。 subscribe channel 一定要在publish channel之前。
原因：在每次publish的时候都需要带上消息，如果这个时候没有用户subscribe，那么这条消息就打水漂了，（为什么会打水漂这得问问redis了）不会说给你放在这等有人subscribe了然后接收到这条消息，它这个消息是不会存储的，这点就已经不适合了，因为消息不能持久。
想法：在publisher那边，我们每次推送消息成功后都会返回一个integer，这个值代表了有几个subscriber ,我们可以这样做，当这个integer返回是0时，这说明publish早了，我们干脆先把这个消息拿个东西装起来。此时有人就会提问啦，这消息装起来了，后面又来消息了怎么办，还装起来吗？这样感觉越来越麻烦了，因为确确实实有时候会下发一堆消息。发快了会不会收不到了，而且这些消息如果顺序出现了错误就有可能出现问题。
那么怎么办呢？是都存起来呢？还是在系统启动时，咱们就先随便发个消息看看有没有人subscribe，直到有人sub了，我才允许你们发消息。反正你也不知道我系统要起多久[doge]
如果上述这个想法可行，那我们还要考虑redis服务的稳定性这个问题了，为什么呢？你看看下面
没有实现持久化机制的Pub/Sub，无法做到消息的不丢失，在客户端宕机或者Redis服务宕机的情况下，都会导致消息丢失。这也是sub要在pub之前的一个原因吧。
- 客户端宕机，客户端无法接收消息
- Redis服务宕机，没有客户端能连接上，肯定也无法接收到消息
综上，这或许就是没人用redis pub/sub的原因吧
这只是我的一个小随笔，随便记录记录蹭点豆子，写得很潦草，欢迎小伙伴们讨论或者给我传授经验，先谢谢大家了哈哈。
