Kafka实战
01、Kafka:为什么要使用消息队列
02、Kafka:消息队列的流派
03、Kafka:安装Kafka服务器
04、Kafka:实现生产者和消费者
05、Kafka:消息的偏移量和顺序消费原理
06、Kafka:单播和多播消息的实现
07、Kafka:主题和分区的概念
08、Kafka:搭建Kafka集群
09、Kafka:副本的概念
10、Kafka:集群消费问题
11、Kafka:Java中Kafka生产者的基本实现
12、Kafka:生产者端的同步发送和异步发送
13、Kafka:生产者中的ack配置
14、Kafka:发送消息的缓冲区机制
15、Kafka:消费者消费消息的基本实现
16、Kafka:Offset的自动提交和手动提交
17、Kafka:消费者poll消息的细节与消费者心跳配置
18、Kafka:指定分区和偏移量,时间消费
19、Kafka:新消费组的消费offset规则
20、Kafka:SpringBoot中使用Kafka的基本实现
21、Kafka:消费者的配置细节
22、Kafka:Kafka中Controller,Rebalance,HW,LEO的概念
23、Kafka:Kafka优化之防止消息丢失和重复消费
24、Kafka:Kafka优化之顺序消费的实现
25、Kafka:Kafka优化之解决消息积压问题
26、Kafka:Kafka优化之实现延时队列
27、Kafka:Kafka-eagle监控平台
28、Kafka:Linux部署Kafka集群
29、Kafka:Docker-compose部署Kafka集群
本文档使用 MrDoc 发布
-
+
首页
02、Kafka:消息队列的流派
### **消息队列的流派** ⽬前消息队列的中间件选型有很多种: - rabbitMQ:内部的可玩性(功能性)是⾮常强的 - rocketMQ: 阿⾥内部⼀个⼤神,根据kafka的内部执⾏原理,⼿写的⼀个消息队列中间 件。性能是与Kafka相⽐肩,除此之外,在功能上封装了更多的功能。 - kafka:全球消息处理性能最快的⼀款MQ - zeroMQ 这些消息队列中间件有什么区别? ### **什么是消息队列** Message Queue(MQ),消息队列中间件。很多⼈都说:MQ 通过将消息的发送和接收分 离来实现应⽤程序的异步和解偶,这个给⼈的直觉是——MQ 是异步的,⽤来解耦的,但是 这个只是 MQ 的效果⽽不是⽬的。MQ 真正的⽬的是为了通讯,屏蔽底层复杂的通讯协议, 定义了⼀套应⽤层的、更加简单的通讯协议。⼀个分布式系统中两个模块之间通讯要么是 HTTP,要么是⾃⼰开发的(rpc) TCP,但是这两种协议其实都是原始的协议。HTTP 协议很 难实现两端通讯——模块 A 可以调⽤ B,B 也可以主动调⽤ A,如果要做到这个两端都要背上 WebServer,⽽且还不⽀持⻓连接(HTTP 2.0 的库根本找不到)。TCP 就更加原始了,粘 包、⼼跳、私有的协议,想⼀想头⽪就发麻。MQ 所要做的就是在这些协议之上构建⼀个简 单的“协议”——⽣产者/消费者模型。MQ 带给我的“协议”不是具体的通讯协议,⽽是更⾼层次 通讯模型。它定义了两个对象——发送数据的叫⽣产者;接收数据的叫消费者, 提供⼀个 SDK让我们可以定义⾃⼰的⽣产者和消费者实现消息通讯⽽⽆视底层通讯协议 ### **有 Broker 的 MQ** 这个流派通常有⼀台服务器作为 Broker,所有的消息都通过它中转。⽣产者把消息发送给它 就结束⾃⼰的任务了,Broker 则把消息主动推送给消费者(或者消费者主动轮询) **重 Topic** kafka、JMS(ActiveMQ)就属于这个流派,⽣产者会发送 key 和数据到 Broker,由 Broker ⽐较key 之后决定给哪个消费者。这种模式是我们最常⻅的模式,是我们对 MQ 最多的印 象。在这种模式下⼀个 topic 往往是⼀个⽐较⼤的概念,甚⾄⼀个系统中就可能只有⼀个 topic,topic 某种意义上就是 queue,⽣产者发送 key 相当于说:“hi,把数据放到 key 的队 列中” 如上图所示,Broker 定义了三个队列,key1,key2,key3,⽣产者发送数据的时候会发送 key1 和 data,Broker 在推送数据的时候则推送 data(也可能把 key 带上)。 虽然架构⼀样但是 kafka 的性能要⽐ jms 的性能不知道⾼到多少倍,所以基本这种类型的 MQ只有 kafka ⼀种备选⽅案。如果你需要⼀条暴⼒的数据流(在乎性能⽽⾮灵活性)那么 kafka 是最好的选择 **轻 Topic** 这种的代表是 RabbitMQ(或者说是 AMQP)。⽣产者发送 key 和数据,消费者定义订阅的 队列,Broker 收到数据之后会通过⼀定的逻辑计算出 key 对应的队列,然后把数据交给队列 这种模式下解耦了 key 和 queue,在这种架构中 queue 是⾮常轻量级的(在 RabbitMQ 中 它的上限取决于你的内存),消费者关⼼的只是⾃⼰的 queue;⽣产者不必关⼼数据最终给 谁只要指定 key 就⾏了,中间的那层映射在 AMQP 中叫 exchange(交换机)。 AMQP 中有四种 exchange - Direct exchange:key 就等于 queue - Fanout exchange:⽆视 key,给所有的 queue 都来⼀份 - Topic exchange:key 可以⽤“宽字符”模糊匹配 queue - Headers exchange:⽆视 key,通过查看消息的头部元数据来决定发给那个 queue(AMQP 头部元数据⾮常丰富⽽且可以⾃定义) 这种结构的架构给通讯带来了很⼤的灵活性,我们能想到的通讯⽅式都可以⽤这四种 exchange 表达出来。如果你需要⼀个企业数据总线(在乎灵活性)那么 RabbitMQ 绝对的值 得⼀⽤ **⽆ Broker 的 MQ** ⽆Broker 的 MQ 的代表是 ZeroMQ。该作者⾮常睿智,他⾮常敏锐的意识到——MQ 是更⾼ 级的Socket,它是解决通讯问题的。所以 ZeroMQ 被设计成了⼀个“库”⽽不是⼀个中间件, 这种实现也可以达到——没有 Broker 的⽬的 节点之间通讯的消息都是发送到彼此的队列中,每个节点都既是⽣产者⼜是消费者。ZeroMQ 做的事情就是封装出⼀套类似于 Socket 的 API 可以完成发送数据,读取数据 ZeroMQ 其实就是⼀个跨语⾔的、重量级的 Actor 模型邮箱库。你可以把⾃⼰的程序想象成 ⼀个Actor,ZeroMQ 就是提供邮箱功能的库;ZeroMQ 可以实现同⼀台机器的 RPC 通讯也 可以实现不同机器的 TCP、UDP 通讯,如果你需要⼀个强⼤的、灵活、野蛮的通讯能⼒,别 犹豫ZeroMQ
李智
2025年3月17日 13:29
转发文档
收藏文档
上一篇
下一篇
手机扫码
复制链接
手机扫一扫转发分享
复制链接
Markdown文件
分享
链接
类型
密码
更新密码