首先 我先引入一个大家熟知的观点：Reids可以作为消息队列来使用
redis提供了两种方式来做消息队列，一种是生产者消费者模式，一种是发布订阅模式。
本篇文章将从 异步，解耦，分布式，可靠四部分来探讨Redis中的消息队列以及应用场景
异步
异步的使用场景【符合我们的真实的世界，真实世界本来就是异步的】，生活中大部分的使用都是基于异步的，比如发送邮件与回复邮件的请求响应模型。
一个service与另外一个service有三种交互方式：命令（Commands）、事件（Events）以及查询（Queries）。一次请求可以理解为由主服务与触发服务和关联服务组成。
Commands 。命令是一个操作。希望在另一个服务中执行某些操作的一个请求。 会改变系统状态的东西。 命令期待有响应。
Events 。事件既是一个事实也是一个触发器。 发生了一些事情，表示为通知。
Queries 。查询是一个请求，是一个查找一些东西的请求（request）。重要的是，查询不会使得系统状态发生改变。
解耦
解耦的基础含义倡导一种是由上而下，分而治之的思想。
解耦又是消息队列最本质的目的。把消息的送达和处理分开，才真正实现消息系统的解耦。
基于消息的模型，关心的是通知，而非处理 。只关心核心流程，多个任务的情况下，发送通知就行了。
经典的生产者消费者模式的消息模型，通过Broker分离生产与消息，Broker简单来说就是消息服务器，负责消息的接受，存取。可以这样理解：
在服务型项目开发上，服务型项目的意思就是项目本质上不是单体应用，会为多个业务服务，上游对下游的调用，不直接通过触发方式完成即可，而是通过消息中心隔离上下游
可靠
001
可靠性简单来说就是程序把需要处理的任务进行编号，每个编号的任务在任务运行期间都是可以被跟踪的。每一个任务拥有自己的唯一标记。比如命名规则可以是：业务组件名称加时间戳的生成规则。
以下 我们看一个网络资料的公开案例
用户最近N条订单记录的Redis存储
对于这个需求需要满足几个条件
1 消息需要有序存储，来确定数据结构SortSet
2 全局跟踪每条记录，对数据进行唯一编码
【订单有序集合中的每个元素是将时间毫秒数+订单号最后3位作为分数进行排序的。为什么不只用毫秒数作为分数呢？因为我们的下单时间只精确到秒，如果不加订单号最后3位，若同一秒有两个或两个以上订单时，排序分数就会一样，从而导致根据分数从缓存查询订单时不能保证唯一性。而我们的订单号的生成规则可以保证同一秒内的订单号的最后3位肯定不一样】
002
每个阶段在处理任务时，都需要有任务回执，来表明这条任务的处理状态，是处理成功还是失败，还是别拒绝处理等。我们以SortSet集合为例，队列处理消费时，一定是按照一定顺序，从前往后或者从后往前依次N条的获取，获取之后，索取元素被消费程序处理，处理的结果如何就是前文提到的任务回执，如果这时因为网络抖动或者调用链下游原因导致消费失败，所取元素代表的业务元数据也会随之消失。这时候就需要根据回执来判断是否需要另外处理所取元素。
Redis下的发布订阅
使用redis的pubsub功能，订阅者订阅频道，发布者发布消息到频道了，频道就是一个消息队列。
我们可以认为发布订阅方式是一种实时的通讯模式。
001
redis 发布订阅使用场景明显是构建实时消息系统，依赖于redis服务端长连接的稳定性。php连接redis的长链接本身就是不靠谱的，而且pubsub也不能使用在可靠性要求比较高的系统中。【不靠谱】体现在订阅模式服务器端开启订阅后，过一段时间订阅会失效，需要不停的轮训开启订阅。
针对Redis的发布订阅功能，网上找到一种说明
一个生产者可以对应多个消费者，但是必须保证消息发布者和消息的订阅者同时在线，否则，否则一旦消息订阅者由于各种异常情况而被迫断开连接，在其重新连接后，其离线期间的消息是无法被重新通知的（即发即弃）。
对于这种理解，最重要的是在应用开发中如何保证双发都在线的长连接状态？
002
对【不靠谱】的一种解释如下：
因为Redis的监听其实是打开了一个长连接操作的。任何网络波动都会断开的。服务器内网络稳定的情况下是可以的。
分布式
涉及到消息队列的三个角色，发布者，Broker和消费者，都可以以集群的形式进行部署和发布。消费能力可以通过增加机器数进行扩展。
补充：根据参考文档来
Q1：分布式消息系统中，如何避免消息重复？
造成消息重复的根本原因是：网络不可靠。只要通过网络交换数据，就无法避免这个问题。所以解决这个问题的办法就是绕过这个问题。那么问题就变成了：如果消费端收到两条一样的消息，应该怎样处理？
a. 消费端处理消息的业务逻辑保持幂等性;
b. 保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现。
通过幂等性，不管来多少条重复消息，可以实现处理的结果都一样。再利用一张日志表来记录已经处理成功的消息的ID，如果新到的消息ID已经在日志表中，那么就可以不再处理这条消息，避免消息的重复处理。
参考文档
REST?RPC?是时候改变你对微服务的认知了！
https://segmentfault.com/p/1210000010216291/read
高可用 Redis 服务架构分析与搭建 https://mp.weixin.qq.com/s/1N4sMAFbfJozdvsEyOuuwA
