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