互联网网站建设情况统计表,设计工作室的经营范围,情人节网页 wordpress,浙江省建设局城市平台网站前言 消息队列中间件重要吗#xff1f;面试必问问题之一#xff0c;你说重不重要。我有时会问同事#xff0c;为啥你用 RabbitMQ#xff0c;不用 Kafka#xff0c;或者 RocketMQ 呢#xff1f;
他给我的回答#xff1a;“因为公司用的就是这个#xff0c;大家都这么用…前言 消息队列中间件重要吗面试必问问题之一你说重不重要。我有时会问同事为啥你用 RabbitMQ不用 Kafka或者 RocketMQ 呢
他给我的回答“因为公司用的就是这个大家都这么用”如果你去面试直接就被 Pass今天这篇文章告诉你如何回答。
这篇文章我重点突出消息队列选型弱化每种队列内部的实现细节精华提炼可读性更强
常用的消息队列主要这 4 种分别为 Kafka、RabbitMQ、RocketMQ 和 ActiveMQ主要介绍前三不 BB上思维导图 消息队列基础 | 什么是消息队列
消息队列是在消息的传输过程中保存消息的容器用于接收消息并以文件的方式存储。 一个消息队列可以被一个也可以被多个消费者消费包含以下 3 元素 Producer消息生产者负责产生和发送消息到 Broker。 Broker消息处理中心负责消息存储、确认、重试等一般其中会包含多个 Queue。 Consumer消息消费者负责从 Broker 中获取消息并进行相应处理。 | 消息队列模式
点对点模式多个生产者可以向同一个消息队列发送消息一个具体的消息只能由一个消费者消费。 发布/订阅模式单个消息可以被多个订阅者并发的获取和处理。 | 消息队列应用场景
如下 应用解耦消息队列减少了服务之间的耦合性不同的服务可以通过消息队列进行通信而不用关心彼此的实现细节。 异步处理消息队列本身是异步的它允许接收者在消息发送很长时间后再取回消息。 流量削锋当上下游系统处理能力存在差距的时候利用消息队列做一个通用的”载体”在下游有能力处理的时候再进行分发与处理。 日志处理日志处理是指将消息队列用在日志处理中比如 Kafka 的应用解决大量日志传输的问题。 消息通讯消息队列一般都内置了高效的通信机制因此也可以用在纯的消息通讯比如实现点对点消息队列或者聊天室等。 消息广播如果没有消息队列每当一个新的业务方接入我们都要接入一次新接口。有了消息队列我们只需要关心消息是否送达了队列至于谁希望订阅是下游的事情无疑极大地减少了开发和联调的工作量。 常用消息队列 由于官方社区现在对 ActiveMQ 5.x 维护越来越少较少在大规模吞吐的场景中使用所以我们主要讲解 Kafka、RabbitMQ 和 RocketMQ。 | Kafka
Apache Kafka 最初由 LinkedIn 公司基于独特的设计实现为一个分布式的提交日志系统之后成为 Apache 项目的一部分号称大数据的杀手锏在数据采集、传输、存储的过程中发挥着举足轻重的作用。
它是一个分布式的支持多分区、多副本基于 Zookeeper 的分布式消息流平台它同时也是一款开源的基于发布订阅模式的消息引擎系统。 ①重要概念 如下 主题Topic消息的种类称为主题可以说一个主题代表了一类消息相当于是对消息进行分类主题就像是数据库中的表。 分区partition主题可以被分为若干个分区同一个主题中的分区可以不在一个机器上有可能会部署在多个机器上由此来实现 Kafka 的伸缩性。 批次为了提高效率 消息会分批次写入 Kafka批次就代指的是一组消息。 消费者群组Consumer Group消费者群组指的就是由一个或多个消费者组成的群体。 Broker一个独立的 Kafka 服务器就被称为 brokerbroker 接收来自生产者的消息为消息设置偏移量并提交消息到磁盘保存。 Broker 集群broker 集群由一个或多个 broker 组成。 重平衡Rebalance消费者组内某个消费者实例挂掉后其他消费者实例自动重新分配订阅主题分区的过程。 ②Kafka 架构 一个典型的 Kafka 集群中包含 Producer、broker、Consumer Group、Zookeeper 集群。
Kafka 通过 Zookeeper 管理集群配置选举 leader以及在 Consumer Group 发生变化时进行 rebalance。
Producer 使用 push 模式将消息发布到 brokerConsumer 使用 pull 模式从 broker 订阅并消费消息。 ③Kafka 工作原理 消息经过序列化后通过不同的分区策略找到对应的分区。
相同主题和分区的消息会被存放在同一个批次里然后由一个独立的线程负责把它们发到 Kafka Broker 上。 分区的策略包括顺序轮询、随机轮询和 key hash 这 3 种方式那什么是分区呢
分区是 Kafka 读写数据的最小粒度比如主题 A 有 15 条消息有 5 个分区如果采用顺序轮询的方式15 条消息会顺序分配给这 5 个分区后续消费的时候也是按照分区粒度消费。 由于分区可以部署在多个不同的机器上所以可以通过分区实现 Kafka 的伸缩性比如主题 A 的 5 个分区分别部署在 5 台机器上如果下线一台分区就变为 4。
Kafka 消费是通过消费群组完成同一个消费者群组一个消费者可以消费多个分区但是一个分区只能被一个消费者消费。 如果消费者增加会触发 Rebalance也就是分区和消费者需要重新配对。
不同的消费群组互不干涉比如下图的 2 个消费群组可以分别消费这 4 个分区的消息互不影响。 | RocketMQ
RocketMQ 是阿里开源的消息中间件它是纯 Java 开发具有高性能、高可靠、高实时、适合大规模分布式系统应用的特点。
RocketMQ 思路起源于 Kafka但并不是 Kafka 的一个 Copy它对消息的可靠传输及事务性做了优化目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binlog 分发等场景。 ①重要概念 如下 Name 服务器NameServer充当注册中心类似 Kafka 中的 Zookeeper。 Broker一个独立的 RocketMQ 服务器就被称为 brokerbroker 接收来自生产者的消息为消息设置偏移量。 主题Topic消息的第一级类型一条消息必须有一个 Topic。 子主题Tag消息的第二级类型同一业务模块不同目的的消息就可以用相同 Topic 和不同的 Tag 来标识。 分组Group一个组可以订阅多个 Topic包括生产者组Producer Group和消费者组Consumer Group。 队列Queue可以类比 Kafka 的分区 Partition。 ②RocketMQ 工作原理 RockerMQ 中的消息模型就是按照主题模型所实现的包括 Producer Group、Topic、Consumer Group 三个角色。
为了提高并发能力一个 Topic 包含多个 Queue生产者组根据主题将消息放入对应的 Topic下图是采用轮询的方式找到里面的 Queue。
RockerMQ 中的消费群组和 Queue可以类比 Kafka 中的消费群组和 Partition不同的消费者组互不干扰一个 Queue 只能被一个消费者消费一个消费者可以消费多个 Queue。
消费 Queue 的过程中通过偏移量记录消费的位置。 ③RocketMQ 架构 RocketMQ 技术架构中有四大角色 NameServer、Broker、Producer 和 Consumer下面主要介绍 Broker。
Broker 用于存放 Queue一个 Broker 可以配置多个 Topic一个 Topic 中存在多个 Queue。
如果某个 Topic 消息量很大应该给它多配置几个 Queue并且尽量多分布在不同 broker 上以减轻某个 broker 的压力。
Topic 消息量都比较均匀的情况下如果某个 broker 上的队列越多则该 broker 压力越大。 简单提一下Broker 通过集群部署并且提供了 master/slave 的结构slave 定时从 master 同步数据同步刷盘或者异步刷盘如果 master 宕机则 slave 提供消费服务但是不能写入消息。
看到这里大家应该可以发现RocketMQ 的设计和 Kafka 真的很像 | RabbitMQ
RabbitMQ 2007 年发布是使用 Erlang 语言开发的开源消息队列系统基于 AMQP 协议来实现。
AMQP 的主要特征是面向消息、队列、路由、可靠性、安全。AMQP 协议更多用在企业系统内对数据一致性、稳定性和可靠性要求很高的场景对性能和吞吐量的要求还在其次。 ①重要概念 如下 信道Channel消息读写等操作在信道中进行客户端可以建立多个信道每个信道代表一个会话任务。 交换器Exchange接收消息按照路由规则将消息路由到一个或者多个队列如果路由不到或者返回给生产者或者直接丢弃。 路由键RoutingKey生产者将消息发送给交换器的时候会发送一个 RoutingKey用来指定路由规则这样交换器就知道把消息发送到哪个队列。 绑定Binding交换器和消息队列之间的虚拟连接绑定中可以包含一个或者多个 RoutingKey。 ②RabbitMQ 工作原理 AMQP 协议模型由三部分组成生产者、消费者和服务端。 执行流程如下 生产者是连接到 Server建立一个连接开启一个信道。 生产者声明交换器和队列设置相关属性并通过路由键将交换器和队列进行绑定。 消费者也需要进行建立连接开启信道等操作便于接收消息。 生产者发送消息发送到服务端中的虚拟主机。 虚拟主机中的交换器根据路由键选择路由规则发送到不同的消息队列中。 订阅了消息队列的消费者就可以获取到消息进行消费。 ③常用交换器 RabbitMQ 常用的交换器类型有 direct、topic、fanout、headers 四种。具体的使用方法可以参考官网RabbitMQ Tutorials — RabbitMQ
https://www.rabbitmq.com/getstarted.html消息队列对比选型 | 消息队列对比 ①Kafka 优点如下 高吞吐、低延迟Kafka 最大的特点就是收发消息非常快Kafka 每秒可以处理几十万条消息它的最低延迟只有几毫秒。 高伸缩性每个主题topic包含多个分区partition主题中的分区可以分布在不同的主机broker中。 高稳定性Kafka 是分布式的一个数据多个副本某个节点宕机Kafka 集群能够正常工作。 持久性、可靠性、可回溯Kafka 能够允许数据的持久化存储消息被持久化到磁盘并支持数据备份防止数据丢失支持消息回溯。 消息有序通过控制能够保证所有消息被消费且仅被消费一次。 有优秀的第三方 Kafka Web 管理界面 Kafka-Manager在日志领域比较成熟被多家公司和多个开源项目使用。 缺点如下 Kafka 单机超过 64 个队列/分区Load 会发生明显的飙高现象队列越多load 越高发送消息响应时间变长。 不支持消息路由不支持延迟发送不支持消息重试。 社区更新较慢。 ②RocketMQ 优点如下 高吞吐借鉴 Kafka 的设计单一队列百万消息的堆积能力。 高伸缩性灵活的分布式横向扩展部署架构整体架构其实和 Kafka 很像。 高容错性通过 ACK 机制保证消息一定能正常消费。 持久化、可回溯消息可以持久化到磁盘中支持消息回溯。 消息有序在一个队列中可靠的先进先出FIFO和严格的顺序传递。 支持发布/订阅和点对点消息模型支持拉、推两种消息模式。 提供 docker 镜像用于隔离测试和云集群部署提供配置、指标和监控等功能丰富的 Dashboard。 缺点如下 不支持消息路由支持的客户端语言不多目前是 java 及 c其中 c 不成熟。 部分支持消息有序需要将同一类的消息 hash 到同一个队列 Queue 中才能支持消息的顺序如果同一类消息散落到不同的 Queue中就不能支持消息的顺序。 社区活跃度一般。 ③RabbitMQ 优点如下 支持几乎所有最受欢迎的编程语言JavaCC CRubyPerlPythonPHP 等等。 支持消息路由RabbitMQ 可以通过不同的交换器支持不同种类的消息路由。 消息时序通过延时队列可以指定消息的延时时间过期时间 TTL 等。 支持容错处理通过交付重试和死信交换器DLX来处理消息处理故障。 提供了一个易用的用户界面使得用户可以监控和管理消息 Broker。 社区活跃度高。 缺点如下 Erlang 开发很难去看懂源码不利于做二次开发和维护基本只能依赖于开源社区的快速维护和修复 bug。 RabbitMQ 吞吐量会低一些这是因为他做的实现机制比较重。 不支持消息有序、持久化不好、不支持消息回溯、伸缩性一般。 | 消息队列选型 Kafka追求高吞吐量一开始的目的就是用于日志收集和传输适合产生大量数据的互联网服务的数据收集业务大型公司建议可以选用如果有日志采集功能肯定是首选 Kafka。 RocketMQ天生为金融互联网领域而生对于可靠性要求很高的场景尤其是电商里面的订单扣款以及业务削峰在大量交易涌入时后端可能无法及时处理的情况。
RocketMQ 在稳定性上可能更值得信赖这些业务场景在阿里双 11 已经经历了多次考验如果你的业务有上述并发场景建议可以选择 RocketMQ。 RabbitMQ结合 erlang 语言本身的并发优势性能较好社区活跃度也比较高但是不利于做二次开发和维护不过 RabbitMQ 的社区十分活跃可以解决开发过程中遇到的 bug。如果你的数据量没有那么大小公司优先选择功能比较完备的 RabbitMQ。 ActiveMQ官方社区现在对 ActiveMQ 5.x 维护越来越少较少在大规模吞吐的场景中使用。 综合上面的材料得出以下两点: (1)中小型软件公司 建议选RabbitMQ 一方面erlang语言天生具备高并发的特性而且他的管理界面用起来十分方便。正所谓成也萧何败也萧何他的弊端也在这里虽然RabbitMQ是开源的然而国内有几个能定制化开发erlang的程序员呢所幸RabbitMQ的社区十分活跃可以解决开发过程中遇到的bug这点对于中小型公司来说十分重要。不考虑rocketmq和kafka的原因是一方面中小型软件公司不如互联网公司数据量没那么大选消息中间件应首选功能比较完备的所以kafka排除。不考虑rocketmq的原因是rocketmq是阿里出品如果阿里放弃维护rocketmq中小型公司一般抽不出人来进行rocketmq的定制化开发因此不推荐。 (2)大型软件公司 根据具体使用在RocketMq和Kafka之间二选一 大型软件公司具备足够的资金搭建分布式环境也具备足够大的数据量。针对rocketMQ大型软件公司也可以抽出人手对rocketMQ进行定制化开发毕竟国内有能力改JAVA源码的人还是相当多的。至于kafka根据业务场景选择如果有日志采集功能肯定是首选kafka了。具体该选哪个看使用场景。
