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.可能会有数据丢失