Partitions與Replication Factor調整准則
Partition 數目與Replication Factor是在創建一個topic時非常重要的兩個參數，這兩個參數的取值會直接影響到系統的性能與穩定性。
盡量在第一次創建一個topic時就指定這兩個參數，因為
- 如果Partition 數目在之后再次做調整，則會打亂key的順序保證（同樣的key會分布到不同的partition上）
- 如果Replication Factor在之后再次增加，則會給集群帶來更大的壓力，可能會導致性能下降
1. Partition 數目
一般來說，每個partition 能處理的吞吐為幾MB/s（仍需要基於根據本地環境測試后獲取准確指標），增加更多的partitions意味着：
- 更高的並行度與吞吐
- 可以擴展更多的（同一個consumer group中的）consumers
- 若是集群中有較多的brokers，則可更大程度上利用閑置的brokers
- 但是會造成Zookeeper的更多選舉
- 也會在Kafka中打開更多的文件
調整准則：
- 一般來說，若是集群較小（小於6個brokers），則配置2 x broker數的partition數。在這里主要考慮的是之后的擴展。若是集群擴展了一倍（例如12個），則不用擔心會有partition不足的現象發生
- 一般來說，若是集群較大（大於12個），則配置1 x broker 數的partition數。因為這里不需要再考慮集群的擴展情況，與broker數相同的partition數已經足夠應付常規場景。若有必要，則再手動調整
- 考慮最高峰吞吐需要的並行consumer數，調整partition的數目。若是應用場景需要有20個（同一個consumer group中的）consumer並行消費，則據此設置為20個partition
- 考慮producer所需的吞吐，調整partition數目（如果producer的吞吐非常高，或是在接下來兩年內都比較高，則增加partition的數目）
以上僅是幾個基本准則，最重要的是：在本地集群做測試，以獲取一個更合適的partition數目，不同的集群會有不同的性能。
2. Replication factor
此參數決定的是records復制的數目，建議至少 設置為2，一般是3，最高設置為4。更高的replication factor（假設數目為N）意味着：
- 系統更穩定（允許N-1個broker宕機）
- 更多的副本（如果acks=all，則會造成較高的延時）
- 系統磁盤的使用率會更高（一般若是RF為3，則相對於RF為2時，會占據更多50% 的磁盤空間）
調整准則：
- 以3為起始（當然至少需要有3個brokers，同時也不建議一個Kafka 集群中節點數少於3個節點）
- 如果replication 性能成為了瓶頸或是一個issue，則建議使用一個性能更好的broker，而不是降低RF的數目
- 永遠不要在生產環境中設置RF為1
3. 集群調整建議
一個已被業界接受的准則是：
- 一個broker不應該承載超過2000 到 4000 個partitions（考慮此broker上所有來自不同topics的partitions）。同時，一個Kafka集群上brokers中所有的partitions總數最多不應超過20,000個。
此准則基於的原理是：在有broker宕機后，zookeeper需要重新做選舉。若是partitions數目過多，則需要執行大量的leader elections。
另外幾個常規原則有：
- 如果集群中需要更多的partitions，則優先考慮增加brokers
- 如果集群中需要20,000 個以上的partitions，則可以參考Netflix的模型，創建更多的Kafka 集群
最后需要注意的是：不要為一個topic創建超過1000個的partitions。我們也並不需要1000個partitions才能達到很高的吞吐。在開始的時候，選擇一個更合理的partition數目，然后測試性能，根據測試結果再調整partitions 數目。