1
- >
2
- >
3
1
> 本文由 JavaGuide 读者推荐,JavaGuide 对文章进行了整理排版!原文地址:https://www.wmyskxz.com/2019/07/17/kafka-ru-men-jiu-zhe-yi-pian/ , 作者:我没有三颗心脏。
4
2
5
3
# 一、Kafka 简介
16
14
17
15
## Kafka 简介
18
16
19
- Kafka 是一种分布式的,基于发布 / 订阅的消息系统。主要设计目标如下:
17
+ ** Kafka 是一种分布式的,基于发布 / 订阅的消息系统。**
18
+
19
+ 主要设计目标如下:
20
20
21
21
- 以时间复杂度为 O(1) 的方式提供消息持久化能力,即使对 TB 级以上数据也能保证常数时间复杂度的访问性能。
22
22
- 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒 100K 条以上消息的传输。
@@ -30,26 +30,31 @@ Kafka 是一种分布式的,基于发布 / 订阅的消息系统。主要设
30
30
31
31
![ 生产者与消费者] ( ./../../../media/pictures/kafaka/生产者和消费者.png )
32
32
33
- 对于 Kafka 来说客户端有两种基本类型:** 生产者(Producer)** 和** 消费者(Consumer)** 。除此之外,还有用来做数据集成的 Kafka Connect API 和流式处理的 Kafka Streams 等高阶客户端,但这些高阶客户端底层仍然是生产者和消费者API,它们只不过是在上层做了封装。
33
+ 对于 Kafka 来说客户端有两种基本类型:
34
+
35
+ 1 . ** 生产者(Producer)**
36
+ 2 . ** 消费者(Consumer)** 。
37
+
38
+ 除此之外,还有用来做数据集成的 Kafka Connect API 和流式处理的 Kafka Streams 等高阶客户端,但这些高阶客户端底层仍然是生产者和消费者API,它们只不过是在上层做了封装。
34
39
35
40
这很容易理解,生产者(也称为发布者)创建消息,而消费者(也称为订阅者)负责消费or读取消息。
36
41
37
42
### 概念二:主题(Topic)与分区(Partition)
38
43
39
44
![ 主题(Topic)与分区(Partition)] ( ./../../../media/pictures/kafaka/主题与分区.png )
40
45
41
- 在 Kafka 中,消息以** 主题(Topic)** 来分类,每一个主题都对应一个「消息队列」,这有点儿类似于数据库中的表。但是如果我们把所有同类的消息都塞入到一个“中心”队列中,势必缺少可伸缩性,无论是生产者/消费者数目的增加,还是消息数量的增加,都可能耗尽系统的性能或存储。
46
+ 在 Kafka 中,消息以** 主题(Topic)** 来分类,每一个主题都对应一个 ** 「消息队列」** ,这有点儿类似于数据库中的表。但是如果我们把所有同类的消息都塞入到一个“中心”队列中,势必缺少可伸缩性,无论是生产者/消费者数目的增加,还是消息数量的增加,都可能耗尽系统的性能或存储。
42
47
43
48
我们使用一个生活中的例子来说明:现在 A 城市生产的某商品需要运输到 B 城市,走的是公路,那么单通道的高速公路不论是在「A 城市商品增多」还是「现在 C 城市也要往 B 城市运输东西」这样的情况下都会出现「吞吐量不足」的问题。所以我们现在引入** 分区(Partition)** 的概念,类似“允许多修几条道”的方式对我们的主题完成了水平扩展。
44
49
45
50
### 概念三:Broker 和集群(Cluster)
46
51
47
- ![ 主题(Topic)与分区(Partition)] ( ./../../../media/pictures/kafaka/Broker和集群.png )
48
-
49
- 一个 Kafka 服务器也称为 Broker,它接受生产者发送的消息并存入磁盘;Broker 同时服务消费者拉取分区消息的请求,返回目前已经提交的消息。使用特定的机器硬件,一个 Broker 每秒可以处理成千上万的分区和百万量级的消息。(现在动不动就百万量级..我特地去查了一把,好像确实集群的情况下吞吐量挺高的..摁..)
52
+ 一个 Kafka 服务器也称为 Broker,它接受生产者发送的消息并存入磁盘;Broker 同时服务消费者拉取分区消息的请求,返回目前已经提交的消息。使用特定的机器硬件,一个 Broker 每秒可以处理成千上万的分区和百万量级的消息。(现在动不动就百万量级..我特地去查了一把,好像确实集群的情况下吞吐量挺高的..嗯..)
50
53
51
54
若干个 Broker 组成一个集群(Cluster),其中集群内某个 Broker 会成为集群控制器(Cluster Controller),它负责管理集群,包括分配分区到 Broker、监控 Broker 故障等。在集群内,一个分区由一个 Broker 负责,这个 Broker 也称为这个分区的 Leader;当然一个分区可以被复制到多个 Broker 上来实现冗余,这样当存在 Broker 故障时可以将其分区重新分配到其他 Broker 来负责。下图是一个样例:
52
55
56
+ ![ Broker和集群] ( ./../../../media/pictures/kafaka/Broker和集群.png )
57
+
53
58
Kafka 的一个关键性质是日志保留(retention),我们可以配置主题的消息保留策略,譬如只保留一段时间的日志或者只保留特定大小的日志。当超过这些限制时,老的消息会被删除。我们也可以针对某个主题单独设置消息过期策略,这样对于不同应用可以实现个性化。
54
59
55
60
### 概念四:多集群
@@ -239,8 +244,7 @@ Kafka 中的可靠性保证有如下四点:
239
244
240
245
> 想了解更多戳这里:http://www.dengshenyu.com/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/2017/11/21/kafka-data-delivery.html
241
246
242
-
243
- 三、动手搭一个 Kafka
247
+ # 三、动手搭一个 Kafka
244
248
245
249
通过上面的描述,我们已经大致了解到了「Kafka」是何方神圣了,现在我们开始尝试自己动手本地搭一个来实际体验一把。
246
250
0 commit comments