Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
点击事件
JavaGuide
提交
8ac6241d
J
JavaGuide
项目概览
点击事件
/
JavaGuide
与 Fork 源项目一致
从无法访问的项目Fork
通知
1
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
1
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
J
JavaGuide
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
1
Issue
1
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
未验证
提交
8ac6241d
编写于
9月 16, 2021
作者:
iDeputy
提交者:
GitHub
9月 16, 2021
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Update Kafka常见面试题总结.md
typo PS: KafkaTopicPartitioning.png 配图中 Partition 错了
上级
e4a4e1c3
变更
1
显示空白变更内容
内联
并排
Showing
1 changed file
with
6 addition
and
6 deletion
+6
-6
docs/system-design/distributed-system/message-queue/Kafka常见面试题总结.md
...m-design/distributed-system/message-queue/Kafka常见面试题总结.md
+6
-6
未找到文件。
docs/system-design/distributed-system/message-queue/Kafka常见面试题总结.md
浏览文件 @
8ac6241d
...
...
@@ -11,7 +11,7 @@ Kafka 是一个分布式流式处理平台。这到底是什么意思呢?
流平台具有三个关键功能:
1.
**消息队列**
:发布和订阅消息流,这个功能类似于消息队列,这也是 Kafka 也被归类为消息队列的原因。
2.
**容错的持久方式存储记录消息流**
: Kafka 会把消息持久化到磁盘,有效避免了消息丢失的风险
·
。
2.
**容错的持久方式存储记录消息流**
: Kafka 会把消息持久化到磁盘,有效避免了消息丢失的风险。
3.
**流式处理平台:**
在消息发布的时候进行处理,Kafka 提供了一个完整的流式处理类库。
Kafka 主要有两大应用场景:
...
...
@@ -21,7 +21,7 @@ Kafka 主要有两大应用场景:
### 和其他消息队列相比,Kafka的优势在哪里?
我们现在经常提到 Kafka 的时候就已经默认它是一个非常优秀的消息队列了,我们也会经常拿它
给
RocketMQ、RabbitMQ 对比。我觉得 Kafka 相比其他消息队列主要的优势如下:
我们现在经常提到 Kafka 的时候就已经默认它是一个非常优秀的消息队列了,我们也会经常拿它
跟
RocketMQ、RabbitMQ 对比。我觉得 Kafka 相比其他消息队列主要的优势如下:
1.
**极致的性能**
:基于 Scala 和 Java 语言开发,设计中大量使用了批量处理和异步的思想,最高可以每秒处理千万级别的消息。
2.
**生态系统兼容性无可匹敌**
:Kafka 与周边生态系统的兼容性是最好的没有之一,尤其在大数据和流计算领域。
...
...
@@ -42,7 +42,7 @@ Kafka 主要有两大应用场景:
**队列模型存在的问题:**
假如我们存在这样一种情况:我们需要将生产者产生的消息分发给多个消费者,并且每个消费者都能接收到完
成
的消息内容。
假如我们存在这样一种情况:我们需要将生产者产生的消息分发给多个消费者,并且每个消费者都能接收到完
整
的消息内容。
这种情况,队列模型就不好解决了。很多比较杠精的人就说:我们可以为每个消费者创建一个单独的队列,让生产者发送多份。这是一种非常愚蠢的做法,浪费资源不说,还违背了使用消息队列的目的。
...
...
@@ -104,7 +104,7 @@ ZooKeeper 主要为 Kafka 提供元数据的管理的功能。
从图中我们可以看出,Zookeeper 主要为 Kafka 做了下面这些事情:
1.
**Broker 注册**
:在 Zookeeper 上会有一个专门
**用来进行 Broker 服务器列表记录**
的节点。每个 Broker 在启动时,都会到 Zookeeper 上进行注册,即到
/brokers/ids
下创建属于自己的节点。每个 Broker 就会将自己的 IP 地址和端口等信息记录到该节点中去
1.
**Broker 注册**
:在 Zookeeper 上会有一个专门
**用来进行 Broker 服务器列表记录**
的节点。每个 Broker 在启动时,都会到 Zookeeper 上进行注册,即到
`/brokers/ids`
下创建属于自己的节点。每个 Broker 就会将自己的 IP 地址和端口等信息记录到该节点中去
2.
**Topic 注册**
: 在 Kafka 中,同一个
**Topic 的消息会被分成多个分区**
并将其分布在多个 Broker 上,
**这些分区信息及与 Broker 的对应关系**
也都是由 Zookeeper 在维护。比如我创建了一个名字为 my-topic 的主题并且它有两个分区,对应到 zookeeper 中会创建这些文件夹:
`/brokers/topics/my-topic/Partitions/0`
、
`/brokers/topics/my-topic/Partitions/1`
3.
**负载均衡**
:上面也说过了 Kafka 通过给特定 Topic 指定多个 Partition, 而各个 Partition 可以分布在不同的 Broker 上, 这样便能提供比较好的并发能力。 对于同一个 Topic 的不同 Partition,Kafka 会尽力将这些 Partition 分布到不同的 Broker 服务器上。当生产者产生消息后也会尽量投递到不同 Broker 的 Partition 里面。当 Consumer 消费的时候,Zookeeper 可以根据当前的 Partition 数量以及 Consumer 数量来实现动态负载均衡。
4.
......
...
...
@@ -138,7 +138,7 @@ Kafka 中发送 1 条消息的时候,可以指定 topic, partition, key,data
生产者(Producer) 调用
`send`
方法发送消息之后,消息可能因为网络问题并没有发送过去。
所以,我们不能默认在调用
`send`
方法发送消息之后消息
消息
发送成功了。为了确定消息是发送成功,我们要判断消息发送的结果。但是要注意的是 Kafka 生产者(Producer) 使用
`send`
方法发送消息实际上是异步的操作,我们可以通过
`get()`
方法获取调用结果,但是这样也让它变为了同步操作,示例代码如下:
所以,我们不能默认在调用
`send`
方法发送消息之后消息发送成功了。为了确定消息是发送成功,我们要判断消息发送的结果。但是要注意的是 Kafka 生产者(Producer) 使用
`send`
方法发送消息实际上是异步的操作,我们可以通过
`get()`
方法获取调用结果,但是这样也让它变为了同步操作,示例代码如下:
> **详细代码见我的这篇文章:[Kafka系列第三篇!10 分钟学会如何在 Spring Boot 程序中使用 Kafka 作为消息队列?](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247486269&idx=2&sn=ec00417ad641dd8c3d145d74cafa09ce&chksm=cea244f6f9d5cde0c8eb233fcc4cf82e11acd06446719a7af55230649863a3ddd95f78d111de&token=1633957262&lang=zh_CN#rd)**
...
...
@@ -170,7 +170,7 @@ if (sendResult.getRecordMetadata() != null) {
当消费者拉取到了分区的某个消息之后,消费者会自动提交了 offset。自动提交的话会有一个问题,试想一下,当消费者刚拿到这个消息准备进行真正消费的时候,突然挂掉了,消息实际上并没有被消费,但是 offset 却被自动提交了。
**解决办法也比较粗暴,我们手动关闭自动提交 offset,每次在真正消费完消息之后
之后
再自己手动提交 offset 。**
但是,细心的朋友一定会发现,这样会带来消息被重新消费的问题。比如你刚刚消费完消息之后,还没提交 offset,结果自己挂掉了,那么这个消息理论上就会被消费两次。
**解决办法也比较粗暴,我们手动关闭自动提交 offset,每次在真正消费完消息之后再自己手动提交 offset 。**
但是,细心的朋友一定会发现,这样会带来消息被重新消费的问题。比如你刚刚消费完消息之后,还没提交 offset,结果自己挂掉了,那么这个消息理论上就会被消费两次。
#### Kafka 弄丢了消息
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录