什么是消息队列（mq）？

我想通过一次新采访回答您的问题.

一个英俊的中年男子，身穿格子衬衫，拿着一副划痕的巨人向你走来，看着郑亮的头，以为他一定是尼玛的顶级建筑师！但是我们看过《暖南敖冰》系列.

Po，这也叫问题吗？如果其他人可以使用它，我可以使用它吗？我在其他人使用它时使用它，我只是将其使用.

你只是在心里耳语，不说，不得​​到要约，那个时候不说，敖冰的败类教给我了！

面试官，您好: 我们公司的业务量很小，因此我们可以直接在一台机器上获得所有信息，但是使用微服务的设计理念，分布式部署，其背后的业务量正在不断扩大. 许多服务已被拆分. 随着数量的增加和业务场景变得越来越复杂，在许多场景中单台计算机的技术堆栈和中间件还不够，并且系统的友好性也下降了. 经过大量的技术选择工作，我们决定引入消息队列中间件.

好，让我从三个方面谈谈我使用的场景.

提示: 这三个场景也是消息队列的经典场景. 每个人都应该熟悉这种思想. 对于消息队列，您必须考虑异步，峰值削波，去耦和条件反射.

在我们先前的场景中，有很多步骤需要在流程中完成，例如我的订单系统. 最初，我们的业务很简单，只需支付订单费用即可. 完成.

但是，产品经理稍后出现并建立了优惠券系统. 可以的问题不大. 该过程需要100毫秒来扣除优惠券.

后来，产品经理说我们可以建立一个积分系统. 好的，增加或减少点的过程还需要200毫秒.

稍后，隔壁的产品稍后说: 下订单后，我们将向用户发送一条短信，并且将在100毫秒内发送一条短信.

后来. . . （敖冰，你拥有一切！！）

无论如何，过程有点像这样↓

您可以看到只有三个. 我可以肯定地告诉您，实际订购过程中涉及的系统肯定超过10个（主流电子商务），越大越多.

此链接一直这样，需要很长时间，用户发现我需要花几十秒钟来购买东西. 我不会向您购买垃圾电子商务，但如果它像七夕便宜，那真是太香了！

但是我们公司没有西溪的经济实力，所以我们只能优化系统.

提示: 当时我是一位老电子商务老板，要求所有接口的Rt（ResponseTime响应时间）应在200ms之内，并且超出了所有优化范围. 我目前负责的系统的QPS也是9W +. 可以油炸网络群集. 这样，RT基本上需要50ms之内.

让每个人都感受到这个QPS.

链接很慢，但是我们发现实际上可以同时完成上述过程. 成功付款后，我可以检查优惠券，并且可以同时增加或减少积分. 短信.

我们无法实现正常流程，该怎么做，异步.

如果您发现用户仅知道订单最多100毫秒成功，则进行比较. 至于几秒钟后您发送给他的短信，他不在乎.

哦，别担心，面试官，我待会儿再说，骚，等等.

既然面试官问了这个问题，我将谈论为什么我们不能用线程来做，因为你用线程来做，你想写代码吗？

您有一个订购流程，您要扣除积分，扣除优惠券，发送短信，扣除库存. . . 等待如此多的企业调用这么多的接口，每次添加一个接口时，都需要调用一个接口，然后重新释放系统. 写一次或两次是可以的. 如果您写更多，您会说: 老子！

如果所有内容都写在一起，那么不仅仅是耦合问题. 您也很难进行故障排除. 如果您在此过程中的某个地方出错，则会影响其他方面. 尝试捕获此过程还不够，我相信我不这样做，这段代码就像定时，您不知道何时爆炸，通常不爆炸，但是当您进行活动时，将得到P0故障进行清理. 书包过年回家很早.

提示: P0-PN是互联网公司通常用来确定事故级别的机制，而P0是最高级别.

但是，如果您使用消息队列，则可以解决耦合问题.

听我说:

下订单时，您将告诉其他系统您的付款成功. 他们收到并处理了它. 您只需要完成自己的过程并发送消息即可. 进入系统很简单，直接订阅您发送的付款成功消息. 如果您的付款成功，我会听.

这个问题是一个很好的问题，但无需考虑. 业务系统本身由其自己的开发人员维护. 您未能扣分的原因是什么？只需照顾好您的订单系统即可.

提示: 我就是这么说的，但这实际上是使用消息队列的缺点. 它涉及分布式事务的知识，我将在下面提到.

以我在上一期中写的峰值（这意味着我的新同学在上一期中看着我），您的访问量通常很低，但是当您想在00:00进行峰值活动时，流量就来了疯狂的是，您的服务器，Redis和MySQL具有不同的承载能力. 直接挂断电话，您必须在直接接收所有流量方面遇到问题.

简单，将请求放入队列消息队列服务器，关于每秒消耗多少请求，这取决于服务器的处理能力. 您可以处理5000QPS并消耗大量资源，这可能比正常情况下要慢，但不会使服务器挂机并等待流量高峰下降，并且您的服务将没有压力.

您看到在Ali的Double 11th上12:00大量的流量涌入，有时他会放慢一点，但是人们并没有挂断电话，也没有降级给您一个友好的提醒页面，请稍等让山峰超越另一个好人.

嘿，任何阅读过我之前写的文章的人都知道，我经常说的是技术是一把双刃剑！

是的，面试官，我之所以使用他，是因为他给我们带来了很多好处，但是使用它之后，随之而来的问题也随之而来.

同一个温暖的人，我也从三个方面介绍他的主要缺点:

这是一个非常简单的系统. 我可以编写任何代码. 现在您可以凭空访问中间件了，我是否必须考虑对其进行维护，并且在使用过程中是否必须考虑各种问题？例如重复使用消息，丢失消息，连续使用消息等. 无论如何，使用它后，它就是小偷.

不！我说敖冰在下一章写了什么？

我实际上不是一个温暖的人. 我不想在这里写. 我考虑这三个问题. 所有这些都是MQ的关键问题. 单独取出一个是一篇文章. 长度太长. 我将是下一个. 本章将一一介绍.

这实际上是分布式服务本身存在的一个问题，不仅是消息队列的问题，而且在这里说是因为使用消息队列的问题将更加严重.

正如我在开始时所说的，您下订单的服务保证了您的逻辑已被成功处理，并且您已经成功发送了消息，但是有很多系统，例如优惠券系统，积分系统等. ，无论它们成功还是失败，您都不在乎. 还有吗？

我谈到了确保我的业务数据正确无误. 实际上，这仍然是一个相对不负责任的声明. 这就像一个卑鄙的人. 没有模式，因此您的路径会越来越窄.

这次订购所有服务都可以认为是成功的. 如何保证数据的一致性？

分布式交易: 下订单，优惠券，积分. . . 它们都放在同一事务中. 如果您想成功，那么您将一起成功. 如果您想失败，您将一起失败.

提示: 分布式事务在Internet公司中非常普遍. 我不会在这里介绍它们，我稍后再讨论.

构建系统没问题. 您突然连接到中间件并将其放在那里. 如果挂了怎么办？我的下一个MQ被挂断了，优惠券没有被扣除，积分没有减少，这不是杀死程序员可以做的事情，感觉就像是杀死了.

关于如何确保高可用性，我这里不再讨论. 稍后，我将像Redis一样编写它.

放松Ao Bing，我不是一个卑鄙的人，我确定我会为您负责. 喜欢！

目前，市场上主要的主流消息队列中间件是Kafka，ActiveMQ，RabbitMQ，RocketMQ等.

但是，我想说的是，由于吞吐量和GitHub社区活动，ActiveMQ和RabbitMQ在主要的互联网公司中基本上已经消失了. 具有平均业务量的公司将会使用它，但是越来越多的公司更喜欢RocketMQ这样的消息中间件.

Kafka和RocketMQ一直在各自的领域大放异彩，但是当我写这篇文章时，我问了Ant Financial，ByteDance和Meituan的朋友. 似乎每个人的用法都有所不同. 各自的中间件可以修改或自行开发，而且大多数不是开源的.

就像我们公司是基于Kafka和RocketMQ的优势自行开发的消息队列中间件一样，其吞吐量，可靠性，及时性等方面都给人留下了深刻的印象.

我们回到主题，我将使用查找的比较表向您显示差距在哪里:

就吞吐量而言，每个人都可以立即看到差距，ActiveMQ和RabbitMQ在早期是相对活跃的，基本上不是后两者的对手. 在大数据时代，吞吐量是真实的. 非常重要.

例如，一个超级热门新闻突然爆发，您有数亿个APP的注册用户，您必须找到一种方法在第一时间将所有突发事件推向所有人，而您却没有大吞吐量消息队列中间件要推送什么？

此外，这些用户大量涌入以查看您的新闻并产生了一系列偶然的流量. 您如何处理这些数据？许多情况下，离开消息队列基本上是不可持续的.

就部署方法而言，前两种也比后两种自然分布式体系结构的兄弟逊色得多. 两者都是高度可用的分布式体系结构，并且多个数据副本的数据也可能会丢失.

让我们谈谈RabbitMQ，中间件实际上是可以的，但是这个小工具的开发语言实际上是erlang. 我敢说大多数工程师绝对不会故意为中间件学习语言. 我想不到的开发和维护成本. 如果有问题，我会检查半天.

对于RocketMQ（阿里巴巴开源），git活动正常. 基本上，您已推送了错误并确认存在问题. 阿里（Ali）已尝试与您联系并进行修复. 我个人也建议这样做. 他的架构设计部分也适用于RPC框架，该框架也是从Ali开源的. 很像（Dubbo），可能是因为老师不在同一个房间里.

提示: Dubbo等我写有关RPC的内容，我将对其进行详细介绍.

最后我要说卡夫卡，你也应该知道，这是老大哥，大数据领域，公司的日志收集，实时计算等场景与他的身影密不可分，他基本上被视为世界一流的消息队列是一个基准.

这些只是我个人的一些见解. 真正的选择仍然有待深入研究，否则您公司的紫外线将为每天1000. 您告诉我您将使用Kafka. 我只能说你吃饱了.

请记住，没有最好的技术，只有最合适的技术，请勿将其用于目的.

好，一个好的面试官，但是我不确定我能否一口气完成它. 毕竟消息队列服务器，敖冰还没有开始写作，读者可能仍然徒劳，动机可能还不够.

我也这么认为.

该文章每周都会不断更新，您可以首次阅读和阅读《三太子敖冰》（提醒您，比博客早一两篇）. ，我也整理了很多文件，欢迎Star和Perfect的加入，每个人都可以参考测试站点进行审查，希望我们一起来.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-215542-1.html