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