Kafka架构

Kafka架构

1.Kafka消息系统一般包括三个部分：Producer（发布者）、Broker（Kafka Server）、Consumer（消费者/订阅者），并辅以Zookeeper来协调。

2.Consumer通过pull来想Broker拉去数据，这样的好处就是Broker设计简单，不需要感知Consumer的存在，也避免了峰值流量导致Consumer被压垮

3.在Kafka0.8版本（包括）之前，Producer需要通过Zookeeper来获取Broker信息，而0.8版本之后，Producer通过集群中少量的Broker来获取当前正常工作的Broker的信息（比如每个topic包含多少个Patiton，每个patiton分别在哪个Broker上）。 consumer通过Zookeeper来获取集群中Broker信息。

 

Topic

 

 

 

 

 

如何在linux上查看文件夹

（先创建一个topic）

1.在配置里查看log.dir

 

2.       

 

我们在这个文件夹中可以看到

 

 

  

 

详解offset

Offset： 一个连续的用于定位被追加到分区的每一个消息的序列号，最大值为64位的long大小，19位数字字符长度。

 

segment由index和data文件组成，两个文件成对出现，分别存储索引和数据。

segment文件命名规则：对于所有的partition来说，segment名称从0开始，之后的每一个segment名称为上一个segment文件最后一条消息的offset值。

 

那么对于分区中的一个offset例如等于345552怎么去查找相应的message呢？

先找到该message所在的segment文件，通过二分查找的方式寻找小于等于345552的offset，假如叫S的segment符合要求，如果S等于345552则S上一个segment的最后一个message即为所求；如果S小于345552则依次遍历当前segment即可找到。

实际上offset的存储采用了稀疏索引，这样对于稠密索引来说节省了存储空间，但代价是查找费点时间。

 

一个集群中Broker可能会有很多，Producer如何去选择Broker去push消息呢？

Kafka提供Partitoner这么一个接口，我们只要定义一个类去实现这个接口

方法一：让相同的key被分配到同一个patition

 

 

方法二：不管key是什么样子的，依次将消息push到patiton中（第一条消息—>第0个patition，第二条消息—>第一个patition ...）

 

 

 

同步发送和异步发送

Sync Producer（只能等前一条消息发送成功，才发送下一跳，不然不停的retry）

1.低延迟

2.低吞吐率

3.无数据丢失

 

Aync Producer（将数据临时放在队列中，后台会有线程去将数据发送给Broker）

1.高延迟

2.高吞吐率

3.可能会有数据丢失