共计 1402 个字符，预计需要花费 4 分钟才能阅读完成。
1. 音讯队列在你我的项目中起到什么作用？
从以前的单体架构到当初的微服务架构，成千盈百的服务之间互相调用和依赖。从互联网初期一个服务器上有 100 个在线用户曾经很了不得，到当初坐拥 10 亿日活的微信。咱们须要有一个「货色」来解耦服务之间的关系、管制资源正当合时的应用以及缓冲流量洪峰等等。它罕用来实现：异步解决、服务解耦、流量管制。
异步解决
随着公司的倒退你可能会发现你我的项目的 申请链路越来越长 ，例如刚开始的电商我的项目，能够就是粗犷的扣库存、下单。缓缓地又加上积分服务、短信服务等。这一路同步调用下来客户可能等急了，这时候就是音讯队列退场的好时机。
调用链路长、响应就慢了，并且绝对于扣库存和下单，积分和短信没必要这么的 “ 及时 ”。因而只须要在下单完结那个流程，扔个音讯到音讯队列中就能够间接返回响应了。而且积分服务和短信服务能够并行的生产这条音讯。能够看出音讯队列能够 缩小申请的期待，还能让服务异步并发解决，晋升零碎总体性能。
服务解耦
除了加积分服务和短信服务，这时候可能又要来个营销服务，或者要丢掉某些服务。为了投合这些上游零碎订单服务须要常常地批改，任何一个上游零碎接口的变更可能都会影响到订单服务。这样的话订单零碎的 保护老本就⾮常的⾼，要时时刻刻思考其余关联系统如果呈现故障 该怎么办？A 零碎是发还是先把音讯保存起来呢？选用音讯队列来解决零碎之间耦合的问题，订单服务把订单相干音讯塞到音讯队列中，只负责⽣产数据，不须要思考音讯被哪个零碎来生产。
流量管制
A 零碎调⽤ B 零碎解决数据，每天 0 点到 12 点，A 零碎⻛平浪静，每秒并发申请数量就 100 个。后果每次⼀到 12 点 ~ 13 点，每秒并发申请数量忽然会暴增到 1 万条。然而 B 零碎最⼤的解决能⼒就只能是每秒钟解决 1000 个申请，这样零碎很容易就会崩掉。这种状况能够引⼊音讯队列，把申请数据先存⼊音讯队列中，生产零碎再依据⾃⼰的生产能⼒拉取生产。
2. 常见音讯队列的模式？
RabbitMQ 采纳 队列模型 ，RocketMQ 和 Kafka 采纳 公布 / 订阅模型。
1. 队列模型
生产者往某个队列外面发送音讯，一个队列能够存储多个生产者的音讯，一个队列也能够有多个消费者，然而消费者之间是竞争关系，即每条音讯只能被一个消费者生产。
2. 公布 / 订阅模型
公布 / 订阅模型是为了解决 一条音讯能被多个消费者生产 的问题。该模型是将音讯发往一个 Topic 即主题中，所有订阅了这个 Topic 的订阅者都能生产这条音讯。
其实能够这么了解，公布 / 订阅模型等于咱们都退出了一个群聊中，我发一条音讯，退出了这个群聊的人都能收到这条音讯。那么队列模型就是一对一聊天，我发给你的音讯，只能在你的聊天窗口弹出，是不可能弹出到他人的聊天窗口中的。
讲到这有人说，那我一对一聊天对每个人都发同样的音讯不就也实现了一条音讯被多个人消费了嘛。
是的，通过多队列全量存储雷同的音讯，即数据的冗余能够实现一条音讯被多个消费者生产。RabbitMQ 就是采纳队列模型，通过 Exchange 模块来将音讯发送至多个队列，解决一条音讯须要被多个消费者生产问题。这里还能看到假如群聊里除我之外只有一个人，那么此时的公布 / 订阅模型和队列模型其实就一样了。
小结一下
队列模型每条音讯只能被一个消费者生产，而公布 / 订阅模型就是为让一条音讯能够被多个消费者生产而生的，当然队列模型也能够通过音讯全量存储至多个队列来解决一条音讯被多个消费者生产问题，然而会有数据的冗余。
