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