廉價磁碟為何撐得住高吞吐：把訊息做成可定址的分散式日誌，用順序寫與作業系統快取換吞吐量。

訊息佇列基礎篇把訊息骨幹拆成 Queue 與 Log 兩種模型。Kafka 選的是後者，並且把它做成可水平擴的產品：一則紀錄的地址不是「佇列裡的下一筆」，而是 topic + partition + offset。本篇不再重述 at-least-once 與 exactly-once 的定義——那些是交付語意；這裡只講 Kafka 用哪些旋鈕去逼近它們。

面試裡最常被低估的一句是：Kafka 的吞吐不是靠「記憶體資料庫」撐起來的。它把資料追加寫進磁碟上的區段檔，讓作業系統的 Page Cache 當讀取緩衝，再用 zero-copy 把頁面直接送上 socket。順序寫讓 HDD／普通 SSD 看起來像高速裝置；堆疊上的 JVM heap 刻意不扛 payload。先承認這件事，後面的 Partition、acks 與 ISR 才有座標。

本篇停在 Kafka 自己的機制。通用複寫與一致性理論見 資料複寫基礎 與進階複寫篇；key 到分片的通用理論見 資料分片基礎——這裡只談 Kafka 的 partition 映射與擴容後的重新指派。事件該帶多少欄位、Transactional Outbox 怎麼讓訊息跟交易同生共死，留給 Event-Driven Architecture。Windowing 與 Watermark 留給 Stream Processing。

定址模型決定你能承諾的順序、並行度，以及擴容時哪些紀錄會「搬家」。

Topic 是命名空間。真正的實體是 Partition：一條只追加、不可改寫的有序序列。Offset 是這條序列上的單調位址——從 0 起跳的整數，不是時間戳，也不在跨 partition 之間可比。

Topic 只是名字，有序的是每一條 partition：offset 在同一條內單調遞增、只在尾端追加（綠色格是目前的尾巴），跨條之間不可比——所以「全域順序」在這張圖上根本沒有位置可畫。

Key 怎麼落到 partition

帶 key 的預設行為是 hash(key) % n：同一個 key 穩定進同一個 partition，於是「同一訂單的事件有序」這句話才成立。沒有 key 時，現代客戶端用 sticky partitioning——先黏在一個 partition 上把批次填滿，再換下一個——為的是批次效率，不是公平輪詢。

這裡不要滑去通用分片理論（一致性雜湊、虛擬節點、hot shard 治理）。Kafka 這一層只承諾兩件事：映射函式穩定時，同 key 同 partition；以及 單一 partition 內 offset 單調、紀錄有序。

因此 partition 數要在流量規劃時一次給夠，而不是當成可隨意加減的旋鈕。真要重切，得做離線重寫或接受窗口內亂序。

吞吐來自順序寫與把讀路徑交給作業系統，不是來自把 payload 塞進 JVM heap。

每個 partition 在磁碟上是一組 Segment：到達大小或時間上限就關閉舊檔、開新的 active segment。Active segment 只在尾巴追加；較舊的 segment 變成不可變，才能被 Retention 整段刪除，或被 Compaction 重寫。旁邊還有稀疏的 offset index 與時間索引，讓「從 offset 12345 開始讀」不必掃完整條 log。

箭頭方向就是 base offset 遞增：只有最右邊的 active segment 在被追加，左邊已關閉且不可變，Retention 才能整檔刪除、Compaction 才能整檔重寫。index 依附在同一個 segment 上，不是另一個並列元件。

為什麼廉價磁碟夠用

隨機寫會把磁碟變成延遲抖動器；Kafka 把熱路徑收成一條順序追加。寫入先進入 OS Page Cache，由作業系統決定何時刷盤（broker 的 flush 與 replication 是另一條耐久軸，見後文 acks／ISR）。讀取端更關鍵：broker 不把訊息本體緩存在 JVM heap。熱資料本來就在 Page Cache 裡，sendfile 這類 zero-copy 路徑把頁面從快取直接搬到 NIC，少一次使用者態拷貝，也少一次 GC 壓力。

寫入端三顆旋鈕：誰點頭、一次塞多少、重試會不會變成兩筆。

Producer 不是「送出一則 RPC」。它把紀錄累成 batch（linger.ms、batch.size），可選壓縮（lz4／zstd／snappy），再依 acks 等待不同範圍的確認。壓縮在批次內最划算：小批次加壓縮只是在燒 CPU。

acks=all 等的是 ISR，不是「複製因子 RF 張副本都活著」。ISR 若被縮到只剩 Leader，all 等價於 1——除非 min.insync.replicas 把寫入擋下來。這條等價關係可以在「ISR、min.insync.replicas 與 unclean election」那一節的決策器裡，把 min.insync.replicas 拖到 1 直接看出來。

冪等 Producer：消掉重試造成的重複

網路超時後客戶端重試，Leader 其實已經寫入——這會在同一 partition 留下兩筆內容相同、offset 不同的紀錄。Idempotent Producer 給每個 Producer 一個 PID，並對每個 partition 維護單調的 sequence。Broker 記住「這個 PID 在這個 partition 上見過的最大序號」，重複序號直接丟棄並回成功。這條路徑要求 acks=all 與有上限的 in-flight batches；它修的是寫入端重試，不是消費端的效果一次，也不是跨 topic 的事務。

一個群組裡，每個 partition 同一時間只有一個主人；換主人的那段空窗叫 Rebalance。

同一個 group.id 的消費者合力消費一個 topic：Group Coordinator 把 partition 指派出去，每個 partition 最多一個主人。這不是 Queue 的 competing consumers——訊息不會因為被其中一人讀走而消失；另一個 group 可以從自己的 offset 再讀一遍。Group 提交的 offset 存在內部 topic __consumer_offsets，重啟後從提交點接續。

一人一區：同一個 group 內每條 partition 只有一個主人，所以消費並行度的上限就是 partition 數。可重放：換到 group H，同一批紀錄從 H 自己的 offset 再讀一遍——這才是 Kafka 與 Queue competing consumers 的分界。

什麼會觸發 Rebalance

成員加入、離開、被判定死亡（session.timeout.ms 內沒有 heartbeat）、以及 partition 數變更。Rebalance 期間，舊指派被收回、新指派尚未生效——這段時間該 partition 沒有人消費。面試要能講出這個停頓，而不是只背「自動負載均衡」。

關鍵在左右兩欄砍的不是同一個數字：Eager Range 搬得多也停得久；Sticky 搬得少、卻因為仍走 eager 協定而停得一樣久；只有 Cooperative Sticky 兩個都少。Sticky 也不是「永不停頓」——該換手的區仍會暫停。Static membership 換到的是部署友好：滾動重啟不再震盪整個 group，但實例 ID 衝突或僵屍成員會佔住指派，要把 session timeout 與撤銷流程想清楚。

先看成本表為什麼中間那一列只砍了一半：預設 6 條 partition、2 名成員、第 3 名加入時，Eager Range 換手 3 條、停頓 6 條；換成 Sticky，換手掉到 2 條，停頓還是 6 條——因為 sticky 只是換了 assignor，協定仍是 eager，全組照樣先 revoke；換成 Cooperative Sticky，指派結果與 Sticky 完全相同（換手仍是 2 條），但停頓掉到 2 條、佔比 33%，代價是要跑 2 輪 JoinGroup。所以 StickyAssignor 與 CooperativeStickyAssignor 的換手數本來就一樣，差的是協定。另外兩組值得比對：把成員變動改成「離開一名」（3 名減為 2 名），Range 換手 3 條、Sticky 與 Cooperative 都是 2 條；把 partition 拖到 2、consumer 留 3、成員變動選「無變動」，並行度上限變成 min(2, 3) = 2，第 3 名 consumer 拿不到任何 partition、負載橫條是空的——加工人加不過 partition 數這道天花板。

Kafka 自己的複寫觀測：誰跟得上 Leader、寫入要幾張嘴點頭、落後者能不能接班。

每個 partition 有一個 Leader 與若干 Follower。Follower 向 Leader fetch，抄寫同一條 log。跟得上的副本組成 ISR（In-Sync Replicas）：落後超過 replica.lag.time.max.ms 就會被踢出。消費者能讀到的不是 Leader 的 log end offset（LEO），而是 High Watermark——ISR 裡最小的那個 LEO。沒進 HWM 的紀錄，對消費者仍是不可見，也還談不上「已提交」。

通用的 quorum／任期／日誌匹配規則請回複寫與 Raft 那兩篇。本段只使用 Kafka 的觀測語言：Leader、Follower、ISR、HWM、unclean election。

RF=3、min.insync.replicas=2、acks=all、關閉 unclean election，是常見的耐久組合：允許少一張副本，但不允許「只寫在 Leader 上」或「用過期日誌接班」。下方的決策器預設就是這一組（所以它的建議清單是空的）；把「同時掛掉幾台」從 1 拖到 2，就會看到它為什麼從「可寫入」翻成「拒絕寫入」。

四組值得停下來比對的設定。(1) 預設 RF=3、min.isr=2、acks=all、unclean=off、掛 1 台：8 筆全部接受、HWM=8，但兩條刻度尺停在不同格——可用性容忍 1 台、耐久容忍 2 台，先撐不住的是可用性。(2) 把「同時掛掉幾台」拖到 2：ISR 剩 1 台 < 需求 2 台，後 2 筆被擋（矩陣右側兩欄變成 ✕），判定翻成「拒絕寫入 — 保護成功」，並算出「要在 2 台掛掉下仍可寫，RF 至少要 4」。(3) 維持掛 2 台再勾選 unclean：耐久容忍度從 2 掉到 1，序列②算出落後副本 r2 會以 LEO=3 接班，offset 3–5 共 3 筆永久消失——矩陣上那三欄被畫上刪除線。(4) 把 min.insync.replicas 拖到 4（超過 RF=3）：矩陣整個空掉，8 筆全被擋，因為 acks=all 要求的 ISR 數已經超過副本總數——這組設定自相矛盾。接著把 acks 切到 1，同一組矛盾設定卻寫得進去：acks=0／1 根本不查 min.insync.replicas，於是 min.isr 完全沒有在保護你。

兩種清理語義：依時間／容量丟掉舊段，或每個 key 只留最後一筆。

Log 模型「不因消費而刪」不代表永遠不刪。Kafka 提供兩條彼此不同的清理軸，混用前先問資料是事件歷史還是狀態快照。

Compaction 不保證立刻發生：active segment 不會被壓，dirty ratio 未達門檻時舊值仍在。它也不是備份——被壓掉的歷史無法重放。需要「每個 key 的現況 + 一段可重放歷史」時，用 compact,delete 並分開設定兩段保留，或乾脆拆成兩個 topic。

先答定址與耐久旋鈕，再談產品周邊。事件建模、串流視窗、通用複寫各有自己的篇。

下一站：用事件重劃服務邊界與 Outbox，見 Event-Driven Architecture；把資料庫日誌變成事件流，見 CDC；視窗與水位線見後續 Stream Processing。複寫協定與分片理論請走資料面那兩條線，不要在本篇展開。