kafka基本架构与文件存储机制-Zookeeper在Kafka中的作用

架构图 

Producer ：消息生产者，就是向kafka broker发消息的客户端

Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic

Topic ：可以理解为一个队列，生产者和消费者面向的都是一个topic

Consumer ：消息消费者，向kafka broker取消息的客户端

Consumer Group （CG）：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。避免重复消费

文件存储机制

1. 存储结构

1. log文件名是以文件中第一条message的offset来命名的，实际offset长度是64位，但是这里只使用了20位，应付生产是足够的
2. 一组index+log+timeindex文件的名字是一样的，并且log文件默认写满1G后，会进行logrolling形成一个新的组合来记录消息，这个是通过broker端log.segment.bytes =1073741824指定的
3. index和timeindex在刚使用时会分配10M的大小，当进行 log rolling 后，它会修剪为实际的大小

2. 日志读操作

1. 首先需要在存储的数据中找出segment文件
2. 然后通过全局offseti计算出segmentr中的offset
3. 通过index中的offset寻找具体数据内容

3. 日志写操作

日志允许串行的追加消息到文件最后

当日志文件达到阈值则滚动到新文件上

4. 清理

og.cleanup.policy

delete

按照一定的删除策略，将不满足条件的数据进行数据删除

compact

针对每个消息的 Key 进行整合，对于有相同 Key 的不同 Value 值，只保留最后一个版

Zookeeper在Kafka中的作用

Kafka集群中有一个broker会被选举为Controller，负责管理集群broker的上下线，所有topic的分区副本分配和leader选举等工作