Apache Kafka笔记（二）：Topics,Partitions and Brokers

Kafka Topic

　　上篇笔记提到，Topic是消息的目录，用于分类消息的逻辑上的概念，在物理上，它的存储表现为日志(log)形式。
　　
　　Producer指定消息发布到指定Topic，一个Topic可能由多个Broker维持，并且同一个Broker可能维持多个Topic，Consumer根据订阅的Topic到对应的Broker上去读取数据。这里可能会有疑问，Topic和具体的Broker之间的对应关系怎么维护？读写请求如何转发到具体Broker上去？下文关于Partitions会描述整个订阅发布过程。
　　
　　Producer每发送一个消息都会追加到Topic队列的最后，按照时间排序，不能插队，也不能修改之前的消息，一个Topic可以同时被多个Consumer同时消费，并且可以重复消费。
　　　
　　每一个消息(Message)中包含的内容有：时间戳、消息的唯一ID以及二进制的消息数据内容。
无论消息是否被消费，消息都会留存一段时间，这个时间默认为168小时(7天)。

Kafka Partition

　　前一篇文章已经做了简单介绍，每个Topic拥有一个或者多个Partition，Partition是Kafka扩展、容错、更高级别的吞吐量的基础。
　　两个小栗子之一：创建拥有单个partition的Topic
　　　
　　　
　　Partition是Topic被细分的最小逻辑单元，不能够再进行拆分存放到多个Broker上，一台机器可以启动多个Broker，所以我认为上图的英文注解有歧义，应该是Each partition must fit entirely on one Broker.
　　再来说说图中文件目录部分是什么意思，在上一篇笔记中提到了关于kafka的基本命令，其中启动kafka服务，bin/kafka-server-start.sh config/server.properties，在config/server.properties中通过log.dirs=/tmp/kafka-logs默认配置log要存储的位置，kafka-logs目录下，server对应每一个Topic的每一个Partition都建立文件夹，文件名的对应关系为{topic}-{partition}。在log文件中记录了对应Topic对应Partition消息commit log的二进制内容，大多数数据库的数据存储方式都采用commit log形式，保存每一次操作而不是单纯的数据，便于数据恢复，只要commit log在，可以通过执行commit log将数据恢复到任意一个时间点。
　　下图是名为test的Topic第一个partition的消息在windows上的存储形式。
　　
　　两个小栗子之二：创建拥有多个Partition的Topic
　　
　　
　　阶段一：创建Topic
　　　　1. Zookeeper获取所有存活的broker，根据需要进行分片的数量(这里为3)，选取leader，因为replication-factor数量为1，所以leader并没有follower。
　　　　2. Zookeeper分配并发送任务给leader(leader本身也是broker，概念上的区别在于leader是负责数据的读写操作的“工头”，当broker没有被赋予“工头”角色而被赋予followers“搬砖工”角色时，只负责复制“工头”的操作–commit log)，broker创建{topic}-{partition}的log文件，并且掌管一份metadata，其中记录topic的每个分片由哪个broker管理，这是整个Topic分片情况的子集。
　　　　3. 每个leader将自己的metadata信息送回Zookeeper，Zookeeper拥有分片情况的全集。

　　阶段二：producer发布消息
　　　　1. 当producer在创建并指定topic时，向Zookeeper询问自己所指定的topic所对应的broker。
　　　　2. producer直接向持有partition的leader发送消息
　　　　注意：–broker-list这个参数并不需要指定集群内所有的broker，只要指定一个即可，它是用来找到整个集群的入口，但是在程序中，最好指定多个，防止指定的broker宕掉。
　　　　　
　　阶段三：consumer订阅消息
　　　　 1. consumer向Zookeeper询问broker和partition的对应关系，还有所有consumer的消费情况，消费负载。
　　　　2. 当consumer知道了组成消息的broker是那些，就可以从这些broker中拉取信息
是不是partition越多越好？
　　　　partition越多，Zookeeper的角色就越重要，容量要求也越高，有可能会变成性能瓶颈。同时，消息的排序会变慢。partition越多，leader的故障转移时间也就越长。

Replication Factor

　　为什么要做复制？没有复制时，当管理的partition的一个leader宕了，Zookeeper会让另外一个leader接管之前leader的工作，接受producer的消息供consumer消费，但是宕机的leader所存储的消息都丢失了。
　　　
　　每个“工头”配了两个“搬砖工”，当每个分片都有3个复制时，集群的状态是健康的，当有一个“搬砖工”挂掉时，集群状态会变成警告，但是不会立即找broker来替代这个复制，如果“工头”挂掉了，会有一个“搬砖工”顶替他成为“工头”。
　　Replication Factor对消息进行冗余，保证了集群的容错率和弹性，但是也不易过多，会占用太多的磁盘空间。