共计 2149 个字符，预计需要花费 6 分钟才能阅读完成。
1 什么是音讯队列
队列是一个根底的“先进先出”的数据结构，音讯队列，就是一个用来寄存音讯的队列。
一个根本的音讯队列的模型如下图，生产者负责往音讯队列里写入音讯，消费者通过订阅生产者公布的音讯就能够生产音讯。
2 为什么要音讯队列
次要的性能有利用解藕，流量消峰，音讯散发，除此之前还有放弃一致性和不便动静扩容等性能。
1. 利用解耦
比方电商零碎，用户创立订单，会波及到，“订单零碎”，”库存零碎“，“物流零碎”和“领取零碎”，如果这些是耦合的，则任何一个零碎的故障都会导致订单创立失败。
可是如果应用音讯队列进行利用解耦，则如下图，比方“物流零碎”产生故障，则物流零碎须要解决的内容被缓存在音讯队列里，用户的下单操作仍然能够实现，等到几分钟后物流零碎复原，这时再补充解决缓存在音讯队列里的订单音讯即可，终端用户是感知不到这几分钟的系统故障的。
2. 流量消峰
当高并发的时候，利用零碎的压力增大，此时通过音讯队列把大量的申请暂存起来，而后扩散到绝对长的一段时间内解决，大大缓解利用零碎的压力。
仍然以电商零碎为例，比方双 11 秒杀流动，假如“订单零碎”每秒能解决 10000 次申请，可是此时流入的是 20000 次申请。要解决这样的状况，要么：
- 减少服务器性能，让他能反对 20000 次申请，可是这种形式不够经济，因为大多数状况下 10000 次申请的解决能力曾经入不敷出。
- 订单超过 10000 次后就不容许用户下单，这个想也不太可能
- 应用音讯队列，把 1 秒内下单订单扩散成一段时间来解决。这时尽管有些用户能在下单后几十秒能力收到下单胜利的状态。可是总比不能下单的体验好。
3. 音讯散发
数据产生方只须要把数据放到音讯队列，数据生产方依据本人的须要订阅感兴趣的数据，不同数据生产方能够反复也能够不反复，互不烦扰，也不须要和数据产生方关联。
如下图各个子系统将日志数据不停的写入音讯队列，数据生产方比方“日志解决 1”还能够把本人解决后的数据从新放入音讯队列供其余数据生产方应用，能够防止反复计算。
应用场景，比方对于用户数据进行用户画像，精准推送等。
4. 异步
A 零碎接管一个申请后，须要：
- 在本人本地写入数据 3ms
- 在 B 零碎写入数据 300ms
- 在 C 零碎写入数据 450ms
- 在 D 零碎写入数据 200ms
则总共须要 3+300+450+200=980ms
可是如果应用 MQ，A 零碎间断发送 3 条申请到 MQ 5ms，则此时 A 零碎从承受一个申请到返回响应给客户，总共 3+5=8ms，比之前的 980ms 快了很多。
3 音讯队列的两种模式
点对点与公布式订阅.
3.1 PTP 点对点
音讯从一个生产者（producer/sender）通过一个队列传给另一个消费者（consumer/receiver）。
能够有多个消费者监听一个队列，然而如果有一个消费者生产了音讯，则其余消费者则获取不到音讯了。所以叫做点到点模式。
发送者和接收者之间在工夫上没有依赖性, 队列保留着音讯，能够放在内存 中也能够长久化，直到他们被生产或超时。
3.2 公布订阅 Publish/Subscribe
发布者把音讯公布到一个 topic，多个订阅者能够订阅同一个 topic，公布的音讯能够被所有的订阅者生产。所以叫做公布订阅模式。
发布者和订阅者之间有工夫上的依赖性。如果发布者公布音讯的时候，订阅者处于某种原因没有接管到，这个音讯就失落了。
4 音讯队列的毛病
零碎可用性升高:
零碎引入的内部依赖越多则越容易挂掉，以下面的电商为例子，原本订单零碎，调用领取零碎，库存零碎，物流零碎的接口就好了，当初引入 MQ 进入，万一 MQ 挂了，整套零碎就奔溃了，所以升高零碎可用性。
零碎复杂性减少:
退出 MQ 后，须要思考，如何保障一致性，如何保障音讯不被反复生产，如何报纸额音讯的传递程序，如何保障音讯牢靠传输等等。
- 一致性问题：
比方下面的电商零碎，订单零碎解决完，间接返回胜利，人都认为你胜利了，然而问题是，物流零碎，领取零碎和库存零碎，只有其中一个挂了，那就会呈现数据不统一的问题。
- 音讯反复生产的问题：
比方 kafka 里，kafka 会给每条数据调配一个 offset，消费者依照 offset 的编号程序去生产，生产后提交 offset。消费者不是一生产好一条数据就立即去提交 offset，是定期提交一次 offset，如果在消费者还没提交的时候，消费者的过程重启了，那么此时曾经生产过的音讯的 offset 就没有提交，这次 kafka 会认为你没有生产这条数据，而后从新给你发送。导致反复生产。
- 数据失落：
生产者在写音讯的时候，在网络传输过程就失落了
生产者把音讯存到 MQ，可是 MQ 本人出错了，没有保留胜利
MQ 收到音讯，并且暂存在内存里，可是在消费者还没来得及生产之前 MQ 挂了，导致暂存在内存的数据失落
消费者生产到这个音讯，可是还没来得及解决本人就坏了，导致 MQ 认为他曾经解决完了，不再给他发消息。
5 常见的音讯队列
此外还有 Amazon SQS/SNS 和 Aliyun MQTT.
下一章节会着重介绍下 Aliyun MQTT 和 RocketMQ 的区别和应用场景。
参考：
《RocketMQ 实战与原理解析》
https://my.oschina.net/u/4383…
https://www.jianshu.com/p/fdd…
https://www.erlang-solutions….
