江苏龙网

  1. 首页 > 人文 > >

『软件』讲真，应该选择RabbitMQ还是Kafka？( 二 )


『软件』讲真，应该选择RabbitMQ还是Kafka？
本文插图
RabbitMQ 消息交换器
需要重点注意的是 RabbitMQ 支持临时和持久两种订阅类型 。 消费者可以调用 RabbitMQ 的 API 来选择他们想要的订阅类型 。
根据 RabbitMQ 的架构设计 ， 我们也可以创建一种混合方法——订阅者以组队的方式然后在组内以竞争关系作为消费者去处理某个具体队列上的消息 ， 这种由订阅者构成的组我们称为消费者组 。
按照这种方式 ， 我们实现了发布/订阅模式 ， 同时也能够很好的伸缩(scale-up)订阅者去处理收到的消息 。
『软件』讲真，应该选择RabbitMQ还是Kafka？
本文插图
发布/订阅与队列的联合使用
Apache Kafka
Apache Kafka 不是消息中间件的一种实现 。 相反 ， 它只是一种分布式流式系统 。
不同于基于队列和交换器的 RabbitMQ ， Kafka 的存储层是使用分区事务日志来实现的 。
Kafka 也提供流式 API 用于实时的流处理以及连接器 API 用来更容易的和各种数据源集成;当然 ， 这些已经超出了本篇文章的讨论范围 。
云厂商为 Kafka 存储层提供了可选的方案 ， 比如 Azure Event Hubsy 以及 AWS Kinesis Data Streams 等 。
对于 Kafka 流式处理能力 ， 还有一些特定的云方案和开源方案 ， 不过 ， 话说回来 ， 它们也超出了本篇的范围 。
主题
Kafka 没有实现队列这种东西 。 相应的 ， Kafka 按照类别存储记录集 ， 并且把这种类别称为主题 。
Kafka 为每个主题维护一个消息分区日志 。 每个分区都是由有序的不可变的记录序列组成 ， 并且消息都是连续的被追加在尾部 。
当消息到达时 ， Kafka 就会把他们追加到分区尾部 。 默认情况下 ， Kafka 使用轮询分区器(partitioner)把消息一致的分配到多个分区上 。
Kafka 可以改变创建消息逻辑流的行为 。 例如 ， 在一个多租户的应用中 ， 我们可以根据每个消息中的租户 ID 创建消息流 。
IoT 场景中 ， 我们可以在常数级别下根据生产者的身份信息(identity)将其映射到一个具体的分区上 。
确保来自相同逻辑流上的消息映射到相同分区上 ， 这就保证了消息能够按照顺序提供给消费者 。

『软件』讲真，应该选择RabbitMQ还是Kafka？
本文插图
Kafka 生产者
消费者通过维护分区的偏移(或者说索引)来顺序的读出消息 ， 然后消费消息 。
单个消费者可以消费多个不同的主题 ， 并且消费者的数量可以伸缩到可获取的最大分区数量 。
所以在创建主题的时候 ， 我们要认真的考虑一下在创建的主题上预期的消息吞吐量 。 消费同一个主题的多个消费者构成的组称为消费者组 。
通过 Kafka 提供的 API 可以处理同一消费者组中多个消费者之间的分区平衡以及消费者当前分区偏移的存储 。
『软件』讲真，应该选择RabbitMQ还是Kafka？
本文插图
Kafka 消费者
Kafka 实现的消息模式
Kafka 的实现很好地契合发布/订阅模式 。 生产者可以向一个具体的主题发送消息 ， 然后多个消费者组可以消费相同的消息 。 每一个消费者组都可以独立的伸缩去处理相应的负载 。
由于消费者维护自己的分区偏移 ， 所以他们可以选择持久订阅或者临时订阅 ， 持久订阅在重启之后不会丢失偏移而临时订阅在重启之后会丢失偏移并且每次重启之后都会从分区中最新的记录开始读取 。
但是这种实现方案不能完全等价的当做典型的消息队列模式看待 。 当然 ， 我们可以创建一个主题 ， 这个主题和拥有一个消费者的消费组进行关联 。


推荐阅读


上一篇：『音箱』智能音箱成新兴爆款 头部厂商市场份额占比超9成

下一篇：『』哪家通信运营商的5G网络会最强？