四种消息队列，如何选型？( 二 ) _消息队列

Kafka 架构一个典型的 Kafka 集群中包含 Producer、broker、Consumer Group、Zookeeper 集群。
Kafka 通过 Zookeeper 管理集群配置，选举 leader，以及在 Consumer Group 发生变化时进行 rebalance 。Producer 使用 push 模式将消息发布到 broker ， Consumer 使用 pull 模式从 broker 订阅并消费消息。

文章插图
图片
Kafka 工作原理消息经过序列化后，通过不同的分区策略，找到对应的分区。
相同主题和分区的消息，会被存放在同一个批次里，然后由一个独立的线程负责把它们发到 Kafka Broker 上。

文章插图
图片
分区的策略包括顺序轮询、随机轮询和 key hash 这 3 种方式，那什么是分区呢？
分区是 Kafka 读写数据的最小粒度，比如主题 A 有 15 条消息，有 5 个分区，如果采用顺序轮询的方式，15 条消息会顺序分配给这 5 个分区，后续消费的时候，也是按照分区粒度消费。

文章插图
图片
由于分区可以部署在多个不同的机器上，所以可以通过分区实现 Kafka 的伸缩性，比如主题 A 的 5 个分区，分别部署在 5 台机器上，如果下线一台，分区就变为 4 。
Kafka 消费是通过消费群组完成，同一个消费者群组，一个消费者可以消费多个分区，但是一个分区，只能被一个消费者消费。

文章插图
图片
如果消费者增加，会触发 Rebalance，也就是分区和消费者需要重新配对。
不同的消费群组互不干涉，比如下图的 2 个消费群组，可以分别消费这 4 个分区的消息，互不影响。

文章插图
图片
2.2 RocketMQRocketMQ 是阿里开源的消息中间件，它是纯 JAVA 开发，具有高性能、高可靠、高实时、适合大规模分布式系统应用的特点。
RocketMQ 思路起源于 Kafka，但并不是 Kafka 的一个 Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog 分发等场景。
重要概念

Name 服务器（NameServer）：充当注册中心，类似 Kafka 中的 Zookeeper 。
Broker: 一个独立的 RocketMQ 服务器就被称为 broker，broker 接收来自生产者的消息，为消息设置偏移量。
主题（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 压力越大。