音讯队列つ退场
大家好，我是老三，是一个电商公司的程序员，负责订单零碎的开发。
掉了不少头发之后，我实现了用户订单领取的开发。
订单领取的业务是这样的。用户领取实现之后，我须要更新订单状态，这一部分是在本零碎实现的。接下来，我要调用库存零碎，减库存，好了，剩下的就是库存零碎的事件了。
开发、联调、测试、上线，我的小日子变得安闲起来，每天就是在群里吹牛打屁。
可是没过两天，产品妹子，找过去了，她说，她想加个性能，用户实现订单领取当前，要减少用户的积分。
没问题，so easy，噼里啪啦，我两天就做完了，无非是调用一下会员零碎。
这天，正和沙雕群友斗图的时候，产品妹子过去，他说要接入音讯零碎，好，搞！
又过两天，她说要增加营销零碎，行吧，干！
又过两天，她说要搞举荐零碎，嗯……，来吧！
又过两天……
于是零碎就变成了这个样子：
就这样，我过上了暗无天日的日子，我要保护和若干个零碎的对接，每次他们公布新版本，我都要跟着值班。
我要迭代，也要改和几个零碎的对接代码。
周一，营销零碎；
周二，库存零碎；
……
这天，眼圈发黑的我正在和上游服务撕巴的时候，忽然忍不住两腿战战，她来了，产品 妹（女）子（王）来了——她是我不能回绝的女人。
软弱的眼泪流了满面，我的猿生一片灰暗……
没想到，代救星呈现了，我的好敌人傲天过去了，拿鼻孔看着我。
“你个 Loser，竟不晓得用音讯队列，怪不得天天被人欺侮，哼！”
一语惊醒梦中人，为什么不必音讯队列啊？
于是我引入音讯队列，对系统进行了重构。
这下好了，我只管 更新订单状态，剩下的丢给音讯队列，你们这些上游本人去音讯队列生产音讯就好了，别来缠着我了。
……
引入音讯队列之后，又是一个安逸的下午。
我没有在群聊里扯扯，因为我退群了。
前几天，我受到了前所未有的挫伤——
我在群里讥嘲一个老哥，技术真菜，连音讯队列都不会！
老哥反手就收回他和女朋友的合照，“独身狗，技术好又怎么样，连个女朋友都没有！”
我霎时 san 值狂掉！
“程序员独身，不算独身……new 个对象的事，能算独身么？”接连着便是什么难懂的话，什么“没有妹子”，什么“哲学”之类，引得众人都哄笑起来，群里充斥了快活的空气。
于是，这个下午我盯着空洞无物的需要单发愣，公司真的没有妹子么？……
好了，简短的前奏完结了，接下来该进入注释了😂。
音讯队列つ用处
在下面的前言中，咱们曾经理解了音讯队列最重要的一个用处：
- 解耦
通过音讯队列，升高零碎间的耦合，防止过多的调用。
就如同公司的行政小姐姐要告诉一件事件，她通常会是在群里发一个布告，而后咱们扣 1 就行了。要是一个个告诉，她要告诉几十上百次。
- 异步
还是下面咱们提到的订单领取，领取之后，咱们要扣减库存、减少积分、发送音讯等等，这样一来这个链路就长了，链路一长，响应工夫就变长了。引入音讯队列，除了 更新订单状态 ，其它的都能够 异步 去做，这样一来就来，就能更快地响应咱们的上游。
为什么不必多线程之类的形式做异步呢？——
嗨，只用多线程做异步，不是还得写代码去调那一堆上游吗，所以这又回到理解耦这个问题上。
- 削峰
音讯队列同样能够用来削峰。
用一个比喻，一条河流，如果它的上游能包容的水量是无限的，为了避免洪水冲垮堤坝，咱们应该怎么办呢？
咱们能够在上游建筑一个水库，洪峰来的时候，咱们先把水给蓄起来，闸口里只放出上游能接受地住的水量。
放在咱们的零碎，也是一个情理。比方秒杀零碎，平时流量很低，然而要做秒杀流动，秒杀的时候流量疯狂怼进来，你的服务器，Redis，MySQL各自的承受能力都不一样，间接全副流量照单全收必定有问题啊，重大点可能间接打挂了。
所以一样，咱们能够把申请放到队列外面，只放出咱们上游服务能解决的流量，这样就能抗住短时间的大流量了。
除了这三大用处之外，还能够利用队列自身的程序性，来满足音讯必须按程序投递的场景；利用队列 + 定时工作来实现音讯的延时生产 ……
音讯队列つ实质
过气老北鼻马老师有三招——接 、 化、发。
音讯队列外围有三板斧：发 、 存、生产。
生产者先将音讯投递一个叫做「队列」的容器中，而后再从这个容器中取出音讯，最初再转发给消费者[1]。
下面这个图便是音讯队列最原始的模型，它蕴含了音讯队列中的一两个关键词 音讯 和队列 队列：
- 音讯：就是要传输的数据，能够是最简略的文本字符串，也能够是自定义的简单格局。
- 队列：大家应该再相熟不过了，是一种先进先出数据结构。它是寄存音讯的容器，音讯从队尾入队，从队头出队，入队即发消息的过程，出队即收音讯的过程。
所以音讯队列的实质就是 把要传输的数据放在队列中。
围绕着这个实质：
- 把数据放到音讯队列的角色就是
生产者 - 把数据从队列中取出的就是
消费者
音讯队列つ模型
[1]咱们下面曾经理解了音讯队列模型的实质，随着利用场景的变动，音讯队列的模型逐步产生了一些演进。
就如同咱们的文字通信，最开始单对单地发消息，起初能够群发，再起初，能够拉一个群聊。
- 队列模型
最后的音讯队列就是上一节讲的原始模型，它是一个严格意义上的队列（Queue）。音讯依照什么程序写进去，就依照什么程序读出来。不过，队列没有“读”这个操作，读就是出队，从队头中“删除”这个音讯。
如果有多个生产者往同一个队列外面发送音讯，这个队列中能够生产到的音讯，就是这些生产者生产的所有音讯的合集。音讯的程序就是这些生产者发送音讯的天然程序。
如果有多个消费者接管同一个队列的音讯，这些消费者之间实际上是竞争的关系，每个消费者只能收到队列中的一部分音讯，也就是说任何一条音讯只能被其中的一个消费者收到。
- 公布 – 订阅模型
如果须要将一份音讯数据分发给多个消费者，并且每个消费者都要求收到全量的音讯。很显然，队列模型无奈满足这个需要。
一个可行的计划是：为每个消费者创立一个独自的队列，让生产者发送多份。这种做法比拟笨，而且同一份数据会被复制多份，也很节约空间。
为了解决这个问题，就演化出了另外一种音讯模型：公布 - 订阅模型。
在公布 – 订阅模型中，音讯的发送方称为发布者（Publisher），音讯的接管方称为订阅者（Subscriber），服务端寄存音讯的容器称为主题（Topic）。发布者将音讯发送到主题中，订阅者在接管音讯之前须要先“订阅主题”。“订阅”在这里既是一个动作，同时还能够认为是主题在生产时的一个逻辑正本，每份订阅中，订阅者都能够接管到主题的所有音讯。
认真比照下它和“队列模式”的异同：生产者就是发布者，队列就是主题，消费者就是订阅者，无本质区别。惟一的不同点在于：一份音讯数据是否能够被屡次生产。
音讯队列つ代价
天下没有白吃的午餐——这句话放在零碎设计中同样实用。引入了音讯队列，解决了一些问题，但同时也减少了零碎的复杂性和保护老本。[5]
- 高可用
后面说，咱们引入了音讯队列，升高了零碎间的耦合，然而，咱们对音讯队列的依赖也变重了，想想，要是音讯队列挂了，那咱们上游就全凉了。
所以，咱们音讯队列的部署必须保障高可用，至多是 主 / 从 ，个别都得 集群 / 分布式。
- 音讯失落问题
咱们将数据写到音讯队列上，上游服务没来得及取音讯队列的数据，忽然挂了。如果没有做任何的措施，咱们的数据就丢了。
那可怎么办呢？
音讯队列中的数据得想方法存在别的中央，这样才尽可能减少数据的失落。
问题又来了，存在哪呢？
- 磁盘？
- 数据库？
- Redis？
- 分布式文件系统？
同步存储还是异步存储？
- 反复生产问题
要是咱们网络提早或者什么起因，导致上游反复生产怎么办？
咱们这个问题是在音讯队列解决？还是在上游服务解决？
还有其它的程序音讯等等问题。
这些问题都是选型时候须要充分考虑的。
音讯队列つ抉择
目前在市面上比拟支流的次要有四大消息中间件：Kafka、ActiveMQ、RabbitMQ、RocketMQ。
它们的比照我整顿了一张图：
音讯队列つ终焉
好了，到这咱们就理解了音讯队列的一些根底的常识。
门外汉，这个门，你入了吗？我反正是在外面打滚了。
“ 简略的事件反复做，反复的事件认真做，认真的事件有创造性地做！”——
我是三分恶，一个能文能武的全栈开发。
点赞、关注不迷路，咱们下期见！
<big>参考：</big>
[1].《吃透 MQ 系列》外围根底全在这里了
[2].《进大厂系列》系列 - 音讯队列根底
[3]. 知乎问答：音讯队列怎么能艰深点解释？
[4]. 零碎学习音讯队列分享（四）音讯模型：主题和队列有什么区别？
[5]. 什么是音讯队列？