前段時間通過網上查詢和自己測試仔細研究了partition和customer關係以及工作中遇到的storm並行度調整的問題，認真梳理了一下現總結如下：

一、先說kafka部分：

produce方面：

如果有多個分割槽，傳送的時候按照key值hashCode%partitionNum雜湊取模分割槽數來決定該條資訊發往哪個partition, 這裡可以自定義partition的分發策略，只要實現Partitioner介面就好，可以自定義成隨機分發或者fangwang發往指定分割槽；

customer方面：

對於topic中的partition來說，一個partition只允許一個customer來消費，同一個partition上不允許customer併發；

Partition數量>customer數量時:一個consumer會對應於多個partitions，這裡主要合理分配consumer數和partition數，否則會導致partition裡面的資料被取的不均勻 。最好partiton數目是consumer數目的整數倍，所以partition數目很重要，比如取24，就很容易設定consumer數目 。

Partition數量<customer數量時:   就會有剩餘的customer閒置，造成浪費；

如果一個consumer從多個partition讀到資料，不保證資料間的順序性，kafka只保證在一個partition上資料是有序的，但多個partition，根據你讀的順序會有不同 ；

增減consumer，broker，partition會導致rebalance，所以rebalance後consumer對應的partition會發生變化。

下面用圖片展示更容易理解（圖片是拷貝其他網友的，自己做了下陳述）

同一個topic的一個partition只能被同一個customerGroup的一個customer消費；group裡多於partition數量的customer會空閒；

同一個topic的partition數量多於同一個customerGroup的customer數量時，會有一個customer消費多個partition，這樣也就沒法保證customer接收到的訊息的順序性，

一個topic 的partitions被多個customerGroup消費時，可以並行重複消費；

1. 只有一個partition分割槽；同一個topic的同一個partition分割槽只允許同一個customerGroup的一個消費者消費資訊，一個partition上不允許同一個消費者組的多個消費者併發，但同一個partition上是可以多個消費者組的消費者併發消費的；
2. 多個partition分割槽，但是，訊息在生產時只發往到了一個partiton上；key的hashCode%partitionNum相同導致，或者自定義了分割槽策略；導致這種嚴重的資料傾斜；

二、storm部分

首先明確的一點是，storm的並行度都是executor即執行緒級別的並行；包括work(程序)，executor(執行緒)的設定，具體體現在works,spout,bolt設定上，同一個executor上設定多個task還是會序列化執行，並不能提高執行效率，這也是由於並行是執行緒並行，一個執行緒的多個task肯定是有先後執行順序的，有順序那就不是並行；關於node，work，executor，task關係和work，spout，bolt，並行度設定網上有很多資料，挺詳細；這裡記錄下我遇到的自己關係的另外兩個問題：一個是從kafka消費訊息是spout並行度設定，另一個ack響應開啟的是執行緒還是程序以及如何設定其數量；

第一個問題：其實理解了上面kafka customer和partition的關係第一個問題也就解決了，spout的併發度例項數量設定最好和partition數量一樣，這樣能保證一個spout消費者例項對應一個partition，即實現了一個partition中訊息消費的順序性（有時訊息的順序性要求並不是很高）也能很好地提高整個topology的執行效率，至少對拓撲執行效率來說，瓶頸不會卡在spout（資料來源）這裡；

第二個問題：通過Storm UI發現，work和spout,bolt並行度不變的情況下，多開幾個acker_executors，works的數量並沒有增加，反而是executors數量增加，這樣就確定了acker_executors如其名一樣只是執行緒，並不像有些網友說的ack的執行是會單獨開啟ack程序再在該程序裡執行ack響應執行緒。他其實就是一個普通的ack執行緒，執行在已有的work程序裡；

另外通過測試還發現一個問題，我設定了4個work，4個spout，4個bolt，沒有設定acker_executors， Storm UI上顯示Num workers是4，Num executors卻是12（4個spout，4個bolt 這裡一共是8個executors），所以感覺預設情況下可能一個work裡會有一個acker_executors。

預設情況下一個work會有一個executor，一個executor會有一個task，如果設定了他們的數量，就會按照設定的數量來生成對應例項；如開了4個work,2個spout,3個bolt,那spout和bolt的executors一共就會有5個（spout executors 2個，bolt executors 3個，），相當於有2個work裡是1個spout executor和1個bolt executor，有1個work裡只有1個boltexecutor，還有一個work裡啥也沒有；其實這種配置會導致多開一個啥活也不幹的work程序，有些浪費；