1. Producer(生產部卷王)
職責:往 Kafka 里瘋狂輸出數據,KPI 是「日拋式消息海嘯」
職場人設:
- 白天開會畫餅,深夜寫周報的奮斗逼,口頭禪是「這個需求今晚必須上線!」
- 代碼里的「福報」:異步發送、批量打包、壓縮數據(把 100 條消息壓成 1 條發),美其名曰「降本增效」
設計原理:
- 不要等待確認:默認異步發送,像極了「工作群里@老板后立刻假裝下線」
- 數據分片甩鍋術:通過 Key 把數據哈希到不同 Partition(相當于把需求拆成 N 個子任務甩給不同同事)
- 重試狂魔:如果某個 Broker(服務器)掛了,自動切換路線,像極了「微信找 A 同事不回復,秒切 B 同事」
必殺技:
acks=all
:要求所有副本確認后才算成功(相當于逼所有相關同事回復「收到」)- 自帶緩沖區:消息先堆在內存,攢夠一波再發(像極了一次性把一周的周報全發了)
2. Broker(運維部背鍋俠)
職責:存數據、傳數據、24小時待命,還要被甩鍋
職場人設:
- 每天背黑鍋的運維小哥,工位貼著「硬盤在人在,硬盤崩了提頭來見」
- 信仰是「順序寫日志,隨機寫提桶跑路」
設計原理:
- 硬盤就是護城河:所有數據按順序追加到日志文件(像極了把需求文檔按日期堆在桌面)
- 零拷貝(Zero-Copy):直接從硬盤把數據扔給網卡,跳過內存(像極了跨部門協作不找中間人傳話)
- 分區存儲:一個 Topic 的數據分散在不同 Broker(相當于把項目拆成模塊分給不同小組)
騷操作:
- 水位控制:如果 Consumer 消費太慢,直接拒收 Producer 的數據(像極了「需求池爆炸時對產品經理關門放狗」)
- 副本同步:Leader 把數據同步給 Follower,還要定期檢查「你跟得上嗎?」(像極了組長每天晨會靈魂拷問)
3. Topic(產品經理的分類癖)
職責:給數據打標簽,搞「精細化運營」
職場人設:
- 每天把「用戶畫像」「行為日志」掛嘴邊的產品經理,實際只會畫腦圖
- 口頭禪是:「這個需求要分三個版本迭代!」
設計原理:
- 邏輯概念物理隔離:Topic 在物理上被拆成多個 Partition(相當于把「年度OKR」拆成季度 KPI)
- 生命周期管理:可以配置數據保留時間(比如7天),像極了「過期的需求文檔直接扔回收站」
必殺技:
- Compact Topic:只保留每個 Key 的最新值(專治「需求反復橫跳」的老板)
- 分區數決定并發度:3 個 Partition 最多 3 個 Consumer 并行消費(像極了「一個項目組最多 3 人摸魚」)
4. Partition(技術組自閉程序員)
職責:把 Topic 拆成多個有序隊列,內部嚴格排隊,外部各自為戰
職場人設:
- 坐在角落戴降噪耳機寫代碼的程序員,絕不參與跨部門會議
- 工位貼著「有序隊列,禁止插隊,違者刪庫跑路」
設計原理:
- Offset 編號系統:每條消息有唯一編號,像極了程序員給代碼提交打 Tag
- Leader 選舉:如果 Leader 掛了,從 ISR(同步副本列表)選新 Leader(像極了組長請假時組員搶話語權)
職場潛規則:
- 一個 Partition 只能被一個 Consumer 消費(同一 Group 內),像極了「一個需求只能有一個接盤俠」
- 不同 Partition 之間可以亂序,但內部必須有序(像極了「組內代碼規范嚴格,但隔壁組隨便寫屎山」)
5. Consumer(測試部摸魚黨)
職責:從 Kafka 里讀數據,還要假裝自己很忙
職場人設:
- 每天掛著「測試環境」網頁實際在刷淘寶的摸魚達人
- 口頭禪是:「這需求有 Bug,打回重做!」
設計原理:
- Pull 模式:自己控制消費速度,像極了「每天只處理 10 個 Bug,多一個就裝死」
- 消費者組(Consumer Group):組內成員瓜分 Partition(像極了測試組內部推諉:「這個 Bug 歸你測!」)
騷操作:
- Rebalance 風暴:當有 Consumer 加入或退出,全組停擺重新分活(像極了「新同事入職時全組開一下午歡迎會」)
- Offset 提交:可以手動提交(像極了「每天下班前才提交代碼」),自動提交可能丟數據(像極了「忘記保存文檔直接關電腦」)
6. ZooKeeper(HR 部監控狂)
職責:管理 Broker 元數據、Consumer Offset(早期版本)、協調選舉
職場人設:
- 每天用監控攝像頭對著員工的 HR,小本本記滿「誰遲到誰早退」
- 口頭禪是:「你的心跳呢?再不回復算你離職!」
設計原理:
- 臨時節點(Ephemeral Node):Broker 和 Consumer 注冊的節點是臨時的,失聯就刪除(像極了「連續三天不交周報就踢出群聊」)
- ZAB 協議:用分布式一致性算法保證數據安全,但速度慢得像「HR 走報銷流程」
職場黑話:
- Watch 機制:監聽節點變化,像極了 HR 在茶水間偷聽八卦
- 未來被取代:Kafka 正在用 KRaft 模式取代 ZooKeeper(像極了「公司空降新 HR 總監,舊派系瑟瑟發抖」)
7. 副本與 ISR(實習生備胎聯盟)
職責:保證數據不丟,服務高可用
職場人設:
- 每天幫 Leader 干臟活的實習生,轉正機會渺茫
- 口頭禪是:「Leader 的文件我備份了,隨時能頂上!」
設計原理:
- ISR(In-Sync Replicas):只保留能跟上 Leader 節奏的副本(像極了「只給按時交周報的實習生轉正機會」)
- Unclean Leader 選舉:ISR 全掛時,允許用非同步副本當 Leader(像極了「正式員工全陽了,讓實習生頂班」)
職場潛規則:
- Follower 定期從 Leader 拉數據(像極了實習生偷看正式員工代碼)
- Leader 掛后,ISR 里的 Follower 開啟「奪權模式」(像極了組長請假時實習生搶電腦改代碼)
協作大戲:一場互聯網需求流水線
-
需求誕生(Producer 發消息):
產品經理(Producer)拍腦袋想出新需求 → 按 Key 哈希到某個 Partition → 扔給對應技術組(Broker) -
需求落地(Broker 存數據):
技術組把需求文檔(消息)存到硬盤 → Leader 程序員(Partition Leader)同步給實習生(Follower) -
需求驗收(Consumer 消費):
測試組(Consumer Group)從不同 Partition 領任務 → 摸魚黨 A 測 Partition 0,摸魚黨 B 測 Partition 1 -
容災演習(Leader 掛了):
Leader 程序員突然猝死 → HR(ZooKeeper)發起緊急選舉 → 手速最快的實習生(ISR Follower)上位 -
數據安全(副本同步):
新 Leader 瘋狂同步需求文檔 → 跟不上節奏的實習生被踢出 ISR(「周報寫不完?明天不用來了!」)
Kafka の 職場生存哲學
- 卷王法則:吞吐量至上!批量發送、順序寫盤、零拷貝,把 CPU 和硬盤往死里榨
- 摸魚奧義:消費者自己控制節奏,拒絕被 PUSH 需求壓垮
- 甩鍋寶典:數據分片(Partition)+ 多副本(Replica),誰崩了都能找人背鍋
- 宮斗指南:ISR 動態調整 + Leader 選舉,隨時準備搶活上位