江苏龙网

  1. 首页 > 人文 > >

「极速聊科技」RabbitMQ 还是 Kafka？，讲真，应该选择( 二 )


IoT场景中 ， 我们可以在常数级别下根据生产者的身份信息将其映射到一个具体的分区上 。
确保来自相同逻辑流上的消息映射到相同分区上 ， 这就保证了消息能够按照顺序提供给消费者 。
「极速聊科技」RabbitMQ 还是 Kafka？，讲真，应该选择
文章图片
Kafka生产者
消费者通过维护分区的偏移来顺序的读出消息 ， 然后消费消息 。
单个消费者可以消费多个不同的主题 ， 并且消费者的数量可以伸缩到可获取的最大分区数量 。
所以在创建主题的时候 ， 我们要认真的考虑一下在创建的主题上预期的消息吞吐量 。 消费同一个主题的多个消费者构成的组称为消费者组 。
通过Kafka提供的API可以处理同一消费者组中多个消费者之间的分区平衡以及消费者当前分区偏移的存储 。
「极速聊科技」RabbitMQ 还是 Kafka？，讲真，应该选择
文章图片
Kafka消费者
Kafka实现的消息模式
Kafka的实现很好地契合发布/订阅模式 。 生产者可以向一个具体的主题发送消息 ， 然后多个消费者组可以消费相同的消息 。 每一个消费者组都可以独立的伸缩去处理相应的负载 。
由于消费者维护自己的分区偏移 ， 所以他们可以选择持久订阅或者临时订阅 ， 持久订阅在重启之后不会丢失偏移而临时订阅在重启之后会丢失偏移并且每次重启之后都会从分区中最新的记录开始读取 。
但是这种实现方案不能完全等价的当做典型的消息队列模式看待 。 当然 ， 我们可以创建一个主题 ， 这个主题和拥有一个消费者的消费组进行关联 。
这样我们就模拟出了一个典型的消息队列 。 不过这会有许多缺点 ， 我们会在第二部分详细讨论 。
值得特别注意的是 ， Kafka是按照预先配置好的时间保留分区中的消息 ， 而不是根据消费者是否消费了这些消息 。
这种保留机制可以让消费者自由的重读之前的消息 。 另外 ， 开发者也可以利用Kafka的存储层来实现诸如事件溯源和日志审计功能 。
结束语
尽管有时候RabbitMQ和Kafka可以当做等价来看 ， 但是他们的实现是非常不同的 。
所以我们不能把他们当做同种类的工具来看待；一个是消息中间件 ， 另一个是分布式流式系统 。
作为解决方案架构师 ， 我们要能够认识到它们之间的差异并且尽可能的考虑在给定场景中使用哪种类型的解决方案 。
第二部分会指出这些差异并且提供什么时候使用哪种方案的指导建议 ， 后面会为大家更新 。
END


推荐阅读


上一篇：『凤权天下』电长猜想——电动车厂家你们为什么没有自己的设计？

下一篇：「雷科技」英特尔全新移动处理器显卡参数曝光：不及UHD630