前语

面试时面试官一问到MQ你了解吗？能讲下你们项目中MQ用来干什么吗？大多数人的榜首回答是：”异步音讯处理,削峰填谷”,今日教你们一招能瞬间让面试官打起精神的回答，下次面试时你们能够这样说：MQ就像是一个奇特的邮递员，它能够将音讯快速、牢靠地传递到各个体系中，它的作用就像是一个桥梁，衔接了不同的体系，使得它们能够顺畅地沟通和协作。 顿时格式就上来了，这时面试官的心理活动：这小子理解总结得蛮透彻的，今日我得在MQ上多盘他几下….

业务场景

MQ运用场景介绍

  1. 直播间内送礼、特效、公屏、弹幕等需求用到MQ异步处理
  2. 散布式环境下本地缓存的改写需求用到MQ告诉刷缓存
  3. 耗时长/并发高的业务需求用到MQ做削峰填谷
  4. 不同微服务中需求用到MQ做体系解耦
  5. 散布式微服务环境下需求播送、集群、推迟消费，有时乃至需求运用业务消费处理散布式业务问题

MQ选型要求

  1. 需求一个可大规划集群布置(高可用性)的MQ
  2. 需求一个吞吐量高、推迟低的MQ
  3. 需求一个支撑多种消费形式的MQ
  4. 需求一个好落地、社区较完善、易扩展的MQ

业内常用MQ

1. ActiveMQ

特色：

  • 支撑多种音讯传输协议：ActiveMQ 支撑多种音讯传输协议，如 JMS、AMQP、STOMP 等。
  • 支撑多种音讯模型：ActiveMQ 支撑多种音讯模型，如点对点模型、发布订阅模型等。
  • 支撑多种音讯类型：ActiveMQ 支撑多种音讯类型，如文本音讯、目标音讯、字节音讯等。

长处：

  • 支撑多种音讯传输协议、模型和类型，灵敏性较高；
  • 能够方便地与 Spring 等结构进行集成。

缺陷：

  • ActiveMQ 的功用相对较低，不能满意高并发、高吞吐量的音讯传输需求；
  • 布置和装备相对杂乱，需求投入大量的时间和精力。

运用场景：

  • 需求与其他JMS标准的体系集成；
  • 需求支撑多种协议的通讯；
  • 对功用要求不高的中小型体系。

运用上或许存在的坑：

  • JMS API 的运用问题：ActiveMQ 是依据 JMS API 的音讯中间件，需求开发人员熟练掌握 JMS API 的运用方法。
  • 内存走漏问题：ActiveMQ 的功用受限于内存，假如存在内存走漏等问题，或许会导致体系崩溃。
  • 音讯堆积问题：假如消费者处理音讯的速度跟不上生产者的速度，或许会导致音讯堆积。需求依据实践情况来调整消费者的数量和速度。

ActiveMQ合适用于散布式体系之间的音讯通讯、异步使命处理等运用场景。

2. RabbitMQ

特色：

  • 高度牢靠性：RabbitMQ 供给了多种牢靠性确保机制，如音讯承认机制、耐久化等。
  • 良好的功用：RabbitMQ 的功用优异，能够支撑高并发、高吞吐量的音讯传输。
  • 灵敏的路由：RabbitMQ 支撑灵敏的路由战略，能够满意不同场景下的需求。

长处：

  • 供给了多种牢靠性确保机制，音讯不易丢掉；
  • 功用优异，支撑高并发、高吞吐量的音讯传输；
  • 灵敏的路由战略，满意不同场景下的需求。

缺陷：

  • 布置和装备比较杂乱；
  • RabbitMQ 仅支撑单个节点的横向扩展，不支撑集群的纵向扩展。

运用场景：

  • 对功用要求较高的大规划体系；
  • 需求支撑多种协议的通讯；
  • 对音讯传输的安稳性和牢靠性要求较高的体系。

运用上或许存在的坑：

  • 装备文件问题：在 RabbitMQ 的装备文件中，或许存在一些常见的坑点，如装备文件缺失、装备不妥等。
  • 内存问题：RabbitMQ 的功用受限于内存，因而需求依据实践需求来分配内存。
  • 音讯丢掉问题：假如 RabbitMQ 节点宕机或者网络故障，或许会导致音讯丢掉。需求运用牢靠的音讯投递机制（如音讯承认机制）来确保音讯的牢靠性。

RabbitMQ 合适用于使命分发、音讯告诉、日志处理、大数据处理、在线聊天等运用场景。

3. Kafka

特色：

  • 支撑高吞吐量的音讯传输；
  • 支撑音讯的批量处理和紧缩；
  • 支撑散布式布置；
  • 具有较好的功用和牢靠性。

长处：

  • 功用极佳，支撑高并发和大规划的音讯传输；
  • 支撑多种特性，如音讯紧缩、批量处理等；
  • 具有良好的可扩展性和牢靠性。

缺陷：

  • 功用较为简略，不支撑杂乱的音讯处理场景；
  • 社区支撑相对较少。

运用场景：

  • 对功用要求极高的大规划体系；
  • 对音讯传输的牢靠性和安稳性要求较高的体系。

运用上或许存在的坑：

  • 装备问题：Kafka 的装备十分灵敏，但也容易犯错。需求依据实践需求来装备 Kafka 的参数。
  • 磁盘空间问题：Kafka 存储一切的音讯数据，因而需求足够的磁盘空间来存储数据。
  • 服务反常问题：Kafka 的服务或许因为各种原因反常，需求监控服务状况并及时处理。

Kafka合适用于日志处理、实时数据处理、流式处理等运用场景。

4. RocketMQ

特色：

  • 支撑主从架构和Broker集群；
  • 支撑音讯的有序传输和有序消费；
  • 支撑高可用和音讯业务等特性；
  • 具有较好的功用和牢靠性。

长处：

  • 高可用性，支撑主从架构和Broker集群；
  • 对音讯的有序传输和有序消费支撑较好；
  • 支撑业务音讯，确保音讯传输的牢靠性；
  • 功用较为优异，支撑高并发和大规划的音讯传输。

缺陷：

  • 社区相对较小，文档资料相对较少；
  • 布置和装备相对较为杂乱。

运用场景：

  • 对可用性和音讯传输的牢靠性要求较高的大规划体系；
  • 需求支撑有序音讯传输和消费的体系；
  • 对音讯业务有较高要求的体系；
  • 需求支撑大规划数据传输和高并发的体系。

运用上或许存在的坑：

  • 服务端装备问题：RocketMQ 的功用受限于服务端的装备，需求依据实践需求来装备服务端参数。
  • 客户端运用问题：RocketMQ 的客户端运用比较杂乱，需求开发人员熟练掌握客户端的运用方法。
  • 音讯消费问题：RocketMQ 的音讯消费或许存在重复消费、音讯丢掉等问题，需求运用牢靠的音讯消费机制来确保音讯的正确性。

RocketMQ合适用于高并发、大数据量、有序音讯传输、散布式业务等运用场景。

5. Redis

不要笑，真的能够用来做MQ，你要知道并不是一切的业务都需求音讯高可用的，乃至有些业务允许你丢音讯，所以它也是适用于某些场景的。

特色：

  • 依据内存存储，读写速度快；
  • 支撑多种数据结构，如List、Set、Hash等；
  • 支撑多种音讯形式，如发布/订阅、点对点等；
  • 支撑音讯耐久化。

长处：

  • 高功用，读写速度快；
  • 能够运用多种数据结构存储数据，比传统MQ更加灵敏；
  • 支撑多种音讯形式，能够习惯不同的业务需求；
  • 能够运用AOF和RDB两种方法进行数据耐久化，确保音讯不丢掉。

缺陷：

  • 不支撑音讯的业务处理；
  • 不支撑音讯的回溯和消费承认；
  • 单机功用受限，不适用于大规划集群。

运用场景：

  • 合适对功用要求较高的业务场景，如实时性要求高的在线游戏、实时音讯推送等；
  • 合适对数据结构存储需求较多的场景，如散布式缓存、统计数据聚合等；
  • 合适对音讯发布/订阅需求较多的场景，如音讯告诉、实时播送等；
  • 合适对轻量级MQ体系的需求，如小型项目、中小企业等。

运用上或许存在的坑：

  • 耐久化装备问题：Redis 支撑多种耐久化方法，需求依据实践需求来装备耐久化方法和参数。
  • 内存问题：Redis 的功用受限于内存，需求依据实践需求来分配内存。
  • 客户端衔接问题：Redis 的客户端衔接或许存在超时、重试等问题，需求运用牢靠的衔接机制来确保客户端的安稳性。

Redis做MQ体系，能够为一些小型或中小型的运用供给简略、高功用、灵敏的音讯传输服务，但是对于大规划集群或高并发的业务场景来说，显然不适用。

选型剖析

音讯行列 (MQ) 可用性 吞吐量 推迟 落地成本 适用场景 业内运用案例
RabbitMQ 高 中 低 低 企业级运用，大规划数据处理，传输牢靠性要求高的场景 微软、VMware、华为
Kafka 高 高 低 中 流式处理，大数据量场景，高吞吐低推迟的实时音讯处理 Netflix、LinkedIn、Uber
ActiveMQ 中 中 中 低 适用于较小规划的运用，音讯传输牢靠性要求一般的场景 Apache、Adobe、Red Hat
RocketMQ 高 高 低 中 高并发、高吞吐量，低推迟的互联网运用场景 阿里巴巴、美团、京东
Redis 中 高 极低 中 缓存和计算场景，数据量较小，对推迟要求极高的实时运用 Twitter、GitHub、滴滴

业务场景可行性剖析

  1. RabbitMQ：RabbitMQ适用于传输牢靠性要求较高的企业级运用，但在高并发、高吞吐量和低推迟的交际直播场景中或许存在功用瓶颈。

  2. Kafka：Kafka具有高吞吐量和低推迟的特色，适用于处理海量数据和实时流式处理的场景，但在交际直播场景中或许存在实时性不足的问题。

  3. ActiveMQ：ActiveMQ适用于传输一般性质的音讯，但在高并发、高吞吐量和低推迟的交际直播场景中或许存在功用瓶颈。

  4. RocketMQ：RocketMQ适用于高并发、高吞吐量和低推迟的互联网运用场景，支撑多言语客户端和散布式业务，具有高可用性和功用体现。在交际直播场景中，RocketMQ能够满意高并发、高吞吐量和低推迟的音讯交互和推送需求。

  5. Redis：Redis主要用于缓存和计算场景，对推迟要求极高的实时运用，但在交际直播场景中或许存在音讯不牢靠
    、数据量过大的问题。

最终计划承认

归纳考虑以上因素，咱们挑选RocketMQ作为交际直播运用中的音讯行列。RocketMQ具有高并发、高吞吐量和低推迟的特色，能够满意实时音讯交互和推送的需求。此外，RocketMQ还支撑散布式业务和多言语客户端，能够确保数据传输的牢靠性和灵敏性

为什么是RocketMQ而不是Kafka？

再次回答一下来自标题的魂灵发问，我知道其实许多大厂都在用着Kafka，它在高吞吐量、低推迟、可扩展性、活跃的开源社区等方面体现出色，这些因素都是其受大厂欢迎的主要原因之一，也是许多大型企业挑选运用Kafka的原因。

为什么挑选RocketMQ，不是因为它比Kafka多优异，主要有以下几个原因：

  1. 实时性要求更高：交际直播运用需求实时的音讯交互和推送，因而音讯行列需求具备低推迟的特色。尽管Kafka也具有低推迟的特色，但是相较于RocketMQ，其规划和完成更倾向于数据流处理，而不是面向实时音讯的传输，或许不太合适交际直播场景的实时性要求。

  2. 开发功率更高：RocketMQ具有简略易用的API和广泛的客户端支撑，能够在交际直播场景中进步开发功率。而Kafka的客户端相对较少，需求运用者自行编写定制化代码，这或许会增加开发难度和杂乱度。

  3. 更好的容错性和牢靠性：在交际直播场景中，音讯丢掉或传输失利或许会对用户体验发生负面影响。RocketMQ在容错性和牢靠性方面规划得更为严厉和安稳，具有更好的音讯牢靠性和数据一致性。Kafka在这方面的体现也十分优异，但相比之下，RocketMQ在此方面的体现或许更为安稳。

所以总归一句话便是，RocketMQ会被咱们优先挑选，而Kafka或许不太合适在交际直播场景中运用。

RocketMQ在云原生上的体现

  1. 容器化支撑：RocketMQ已经容器化，能够方便地在云原生环境中布置和办理，如Kubernetes。

  2. 弹性弹性：RocketMQ支撑按需弹性，能够依据业务负载自动弹性，进步了音讯体系的可用性和可扩展性。

  3. 高可用性：RocketMQ供给了主从复制和多活布置等机制，能够确保音讯体系的高可用性，避免了单点故障。

  4. 可观测性：RocketMQ供给了完善的监控和告警体系，能够方便地观测音讯体系的运行状况，及时发现并处理问题。

  5. 开放性：RocketMQ是一款开源的音讯中间件，支撑多种编程言语和平台，能够方便地集成到各种散布式体系中。

RocketMQ在云原生时代的支撑与优势十分明显，能够协助用户更好地构建牢靠、高效、高可用的散布式音讯体系。