Kakfa揭秘 Day4
Kafka中分区深度解析
今天主要谈Kafka中的分区数和consumer中的并行度。从使用Kafka的角度说，这些都是至关重要的。
分区原则
Partition代表一个topic的分区，可以看到在构造时注册了zookeeper，也就是说kafka在分区时，是被zk管理的。
在实际存储数据时，怎么确定分区。
咱们从kafka的设计开始，为了完成高吞吐性，关键有两点设计：
- 使用了磁盘操作系统级的页page的访问，据说在顺序读写时比使用内存速度更快。
- 使用Topic进行分布化，可以突破一台机器的限制。consumer和producer都是基于Topic的多线程操作，其中每个线程都会操作一个分区。
也就是分区是高吞吐的一个关键。从具体实现看，每次来请求的时候，都会用一条新的线程来处理，每次consumer或者producer，背后都有一个socketServer，提供NIO操作。
那是不是说Kafka只要topic越多，上面的partition越多，吞吐就越大么？凡事都有利弊，这里有几点考虑。
- 当分区变多时，服务器需要开辟更多的线程，有更多的内存消耗和CPU的使用，太多的时候，会产生太多的句柄，那么管理方面消耗就会过大。
- kafka本身在运行时，每个producer在写数据时，都有一个cache，达到量之后，会把具体的消息发送给kafka集群，分区越多的情况下，从producer角度，cache就越大，内存消耗越多。
- kafka cluster有很多的组件，在分区数较多时会进行大量的管理，会产生大量的句柄。
- ReplicaManager 都要管理每个parition，需要保存相关的句柄，并进行leader、follower与zk交互，在选举过程中会有短暂的不可用，当分区过多时，让zk选举的工作也会特别庞大。
所以，从工作角度，是需要设定一个合适的分区数，这个是需要根据实际数据情况进行训练的。
分区过程
下面让我们具体跟踪一下分区的过程。
Producer
首先从发送数据开始：
数据本身一般有key，则直接获取指定，否则是使用partitioner进行随机选取。
随机计算时会根据Hash值进行计算。
Consumer
默认会用一条线程来消费数据，默认是一个分区一个线程，一个线程可以消费很多分区的数据。
在实现时，会有一个queue阻塞队列，如果没有消息的话，会阻塞的一直等消息过来。读取数据时会有一个策略，决定了每个consumer中的线程读取哪些分区。
欲知后事如何，且听下回分解!
DT大数据每天晚上20：00YY频道现场授课频道68917580