有乙個topic：test，然後這個topic的partition和他們所在的broker的圖如下：
1. 其中 broker有兩個，也就是伺服器有兩台。
2. partition有6個，分布按照如圖所示，按照雜湊取模的演算法分配。
3. 消費者有8個，他們屬於同乙個消費組。
複製**
其實kafka的消費端有乙個均衡演算法，演算法如下：
1. a=(partition數量/同組內消費者總個數)
2. m=對上面所得到的a值小數點第一位向上取整
3. 計算出該消費者拉取資料的patition合集：ci = [p(m*i )~p((i + 1) * m -1)]
複製**
a=6/8=0.75
m=1c0=[p(1*0)~p((0+1)*1-1)]=[p0~p0]
同理：c1=[p(1*1)~p((1+1)*1-1)]=[p1~p1]
c2=[p(1*2)~p((2+1)*1-1)]=[p2~p2]
c3=[p(1*3)~p((3+1)*1-1)]=[p3~p3]
c4=[p(1*4)~p((4+1)*1-1)]=[p4~p4]
c5=[p(1*5)~p((5+1)*1-1)]=[p5~p5]
c6=[p(1*6)~p((6+1)*1-1)]=[p6~p6]
c7=[p(1*7)~p((7+1)*1-1)]=[p7~p7]
複製**
c0消費者消費p0的資料
c1消費者消費p1的資料
c2消費者消費p2的資料
c3消費者消費p3的資料
c4消費者消費p4的資料
c5消費者消費p5的資料
c6消費者消費p6的資料
c7消費者消費p7的資料
複製**
如下圖所示：
如果這個消費組裡面的消費者少於partition數量呢（比如5個）？那麼還是依葫蘆畫瓢，根據上面的演算法：
a=6/5=1.2
m=2c0=[p(2*0)~p((0+1)*2-1)]=[p0~p1]
c1=[p(2*1)~p((1+1)*2-1)]=[p2~p3]
c2=[p(2*2)~p((2+1)*2-1)]=[p4~p5]
c3=[p(2*3)~p((3+1)*2-1)]=[p6~p7]
c4=[p(2*4)~p((4+1)*2-1)]=[p8~p9]
複製**
如下所示：
1. 按照如上的演算法，所以如果kafka的消費組需要增加組員，最多增加到和partition數量一致，超過的組員只會占用資源，而不起作用。
2. kafka的partition的個數一定要大於消費組組員的個數，並且partition的個數對於消費組組員取模一定要為0，不然有些消費者會占用資源卻不起作用。
3.如果需要增加消費組的組員個數，那麼也需要根據上面的演算法，調整partition的個數。
參考**：blog.csdn.net/qq_20641565…
kafka動態修改 consumer
在新版本kafka中，consumer offsets這個topic是存放消費者偏移量的，但是該主題預設配置副本數量只有1，容易造成單點故障，我們可以動態修改 無需重啟服務 副本因子，提高kafka的可靠性 1.1動態地增加相關主題的副本數非常的簡單，同樣是使用kafka reassign part...
Kafka學習整理五 Consumer配置
property default description group.id 用來唯一標識consumer程序所在組的字串，如果設定同樣的group id，表示這些processes都是屬於同乙個consumer group zookeeper.connect 指定zookeeper的連線的字串，格式...
Kafka 從Consumer消費能力低下談起
近期在生產環境發下日誌入庫延遲，導致很多準實時的監控圖表獲取不到資訊，這問題以前沒有出現過，可能跟最近業務量上公升有關，畢竟日均小兩億的平台了。梳理系統架構發現，日誌是快取在kafka中，由乙個後台程序task從kafka中消費，存放到資料庫中的，日誌入庫延遲，跟task關係很大。由於之前對kafk...