Kakfa揭秘 Day4 Kafka中分区深度解析

Kakfa揭秘 Day4

Kafka中分区深度解析

今天主要谈Kafka中的分区数和consumer中的并行度。从使用Kafka的角度说，这些都是至关重要的。

分区原则

Partition代表一个topic的分区，可以看到在构造时注册了zookeeper，也就是说kafka在分区时，是被zk管理的。

在实际存储数据时，怎么确定分区。
咱们从kafka的设计开始，为了完成高吞吐性，关键有两点设计：

1. 使用了磁盘操作系统级的页page的访问，据说在顺序读写时比使用内存速度更快。
2. 使用Topic进行分布化，可以突破一台机器的限制。consumer和producer都是基于Topic的多线程操作，其中每个线程都会操作一个分区。

也就是分区是高吞吐的一个关键。从具体实现看，每次来请求的时候，都会用一条新的线程来处理，每次consumer或者producer，背后都有一个socketServer，提供NIO操作。

那是不是说Kafka只要topic越多，上面的partition越多，吞吐就越大么？凡事都有利弊，这里有几点考虑。

1. 当分区变多时，服务器需要开辟更多的线程，有更多的内存消耗和CPU的使用，太多的时候，会产生太多的句柄，那么管理方面消耗就会过大。
2. kafka本身在运行时，每个producer在写数据时，都有一个cache，达到量之后，会把具体的消息发送给kafka集群，分区越多的情况下，从producer角度，cache就越大，内存消耗越多。
3. kafka cluster有很多的组件，在分区数较多时会进行大量的管理，会产生大量的句柄。
4. ReplicaManager 都要管理每个parition，需要保存相关的句柄，并进行leader、follower与zk交互，在选举过程中会有短暂的不可用，当分区过多时，让zk选举的工作也会特别庞大。

所以，从工作角度，是需要设定一个合适的分区数，这个是需要根据实际数据情况进行训练的。

分区过程

下面让我们具体跟踪一下分区的过程。

Producer

首先从发送数据开始：

数据本身一般有key，则直接获取指定，否则是使用partitioner进行随机选取。

随机计算时会根据Hash值进行计算。

Consumer

默认会用一条线程来消费数据，默认是一个分区一个线程，一个线程可以消费很多分区的数据。
在实现时，会有一个queue阻塞队列，如果没有消息的话，会阻塞的一直等消息过来。读取数据时会有一个策略，决定了每个consumer中的线程读取哪些分区。

欲知后事如何，且听下回分解!

DT大数据每天晚上20：00YY频道现场授课频道68917580