一、選型速查表

場景	關鍵目標	推薦清單（示例）
消息（Messaging）	解耦、低延遲、可靠投遞	acks=all、enable.idempotence=true、retries>0、min.insync.replicas=2、合理分區鍵、DLT
網站活動追蹤	吞吐極高、可回放	主題按類型拆分（page_view, search…），compression.type=zstd，長保留或分層存儲，Schema Registry
指標（Metrics）	運維聚合、準實時	窗口聚合（Streams/Flink），短保留（1–7 天），多分區避免熱點，消費者組擴展
日志聚合	統一采集、低時延	Log agent（Fluent Bit/Vector）→ Kafka，cleanup.policy=delete，分來源建主題，DLT+重試
流處理	多階段管道、圖式數據流	Kafka Streams/Flink，主題“每階段一寫”，冪等寫出，回放友好
事件溯源 / 提交日志	可追溯、狀態重建	cleanup.policy=compact（或 compact+delete），鍵=實體ID，Materialized View

二、用日志做消息

目標：生產者與消費者解耦、低端到端延遲、強持久性。
與傳統 MQ 的區別：Kafka 的消息默認保留（不會因消費而刪除），天然支持回放與多訂閱者，并通過分區獲得線性擴展。

最小配置建議

• 生產者：

  • acks=all、enable.idempotence=true（開啟冪等，避免重復寫）
  • max.in.flight.requests.per.connection=1~5（Exactly-Once 時設 ≤5）
  • retries & 退避（exponential backoff）

• Broker/主題：

  • replication.factor=3、min.insync.replicas=2（容錯 + 一致性）
  • 分區鍵選擇：滿足局部有序（如 orderId）、避免熱點

• 消費側：

  • 合理的消費者組并行度
  • 死信主題（DLT） + 重試隊列，隔離“毒消息”

常見坑

• 只配 acks=1 → 故障丟消息
• 錯分分區鍵 → 熱點/順序失控
• 忽略 DLT → 處理鏈路被一條異常消息“卡死”

三、網站活動追蹤（Website Activity Tracking）：超高吞吐的“點擊流”

模式：每種活動類型一條中心主題（page_view, search, click…），多下游并行消費：實時監控、風控、離線數倉、畫像計算。

落地要點

• 數據模型：強烈建議Schema Registry（Avro/Protobuf），版本演進友好

• 分區策略：userId/sessionId 做 key，保障會話內順序

• 吞吐與成本：compression.type=zstd 或 lz4，批量發送（linger/batch.size）

• 保留策略：

  • 實時主題：7–30 天
  • 歷史歸檔：tiered storage/對象存儲 + 索引（按需）

參考主題

• activity.page_view、activity.search、activity.click
• activity.enriched.*（清洗/富化后）

四、指標（Metrics）：把分布式指標“匯江成海”

場景：應用/服務把運行指標聚合到中心流，做SLA 監控、容量規劃、異常檢測。

設計建議

• 生產端聚合后再上報（降噪/降頻），或在 Streams/Flink 中做窗口聚合（如 10s/1m）
• 消費側多用途：存時序庫（M3DB/ClickHouse/Influx/TSDB）、在線告警
• 保留：1–7 天足矣（更久走冷存儲）

參數要點

• 主題分區數 ≥ 生產端節點數/區域數，避免單分區熱點
• retention.ms 以窗口與排查周期為準

五、日志聚合（Log Aggregation）：比“拉文件”更干凈的抽象

對比：與 Scribe/Flume 相比，Kafka 提供復制與更低端到端延遲，把“文件”抽象成事件流，天然支持多源多消費者。

推薦鏈路

配置要點

• cleanup.policy=delete（日志通常無需去重）
• 分來源/級別建主題：logs.app1.info、logs.app1.error…
• DLT + 重試：解析失敗/超大行單獨處理
• 大行處理：生產端分片/截斷策略，避免單消息過大

六、流處理（Stream Processing）：多階段實時數據管道

模式：原始 → 清洗/富化 → 主題 A → 統計/聚合 → 主題 B → 推薦/畫像…
每一階段寫回 Kafka，形成有向圖，具備回放能力與可觀察性。

工具選擇

• Kafka Streams（輕量、內嵌、與 Kafka 緊耦合，運維簡單）
• 或 Flink/Spark Streaming/Samza（復雜拓撲/跨源融合/批流一體）

工程要點

• Exactly-Once：Streams/Flink 均可配置 EOS 事務與一致性寫（雙寫避免）
• 窗口：滾動/滑動/會話窗口，按事件時間處理 + 水位線
• 回放：定位時間點 → 重置消費者位點 → 重新計算

七、事件溯源（Event Sourcing）與提交日志（Commit Log）

事件溯源：把狀態變更記錄為按時間排序的不可變事件；當前狀態 = 事件重放后的結果。
提交日志：為分布式系統提供外部復制與重放的“真相來源”（Source of Truth）。

Kafka 配置要點

• 主題：cleanup.policy=compact（或 compact,delete 組合）
• key 設計：實體ID（accountId / orderId），保證“最后一次事件”長留
• 讀側：Materialized View（Streams/Flink 的 KTable/State），對外提供查詢
• 故障恢復：新副本/新服務節點通過回放日志快速重建狀態

何時選 compact？

• 需要任意時刻的最新值（KV 視圖）且保留“最后一次變更”
• 結合 delete：既要最新值，又要保留一段歷史

八、參考參數模板（可直接套用）

通用（Broker/主題）

# 可用性與一致性
replication.factor=3
min.insync.replicas=2# 吞吐與成本
compression.type=zstd
message.max.bytes=10485760    # 10MB，視業務調整

消息/交易類主題

cleanup.policy=delete
retention.ms=604800000        # 7 天

活動追蹤/點擊流

cleanup.policy=delete
retention.ms=2592000000       # 30 天或更長

指標主題

cleanup.policy=delete
retention.ms=604800000        # 1–7 天

事件溯源/提交日志（KV 視圖）

cleanup.policy=compact
min.cleanable.dirty.ratio=0.1
segment.ms=604800000

生產者（Exactly-Once/高可靠）

acks=all
enable.idempotence=true
retries=2147483647
max.in.flight.requests.per.connection=5
delivery.timeout.ms=120000
linger.ms=5
batch.size=131072

九、監控與可觀測性（必做）

• 延遲：生產端/消費端/端到端
• Lag：消費者組積壓
• 吞吐與錯誤率：生產失敗、重試、DLT 數量
• 存儲水位：磁盤占用、Log Cleaner（壓縮）進度
• 再均衡：頻率與耗時（過于頻繁需排查分區分配/會話超時）

十、常見設計誤區與修正

• 把 Kafka 當“隊列”：忽視保留與回放 → 設計 DLT、位點重置、歷史重算
• 分區數拍腦袋：過多導致內存/FD/控制面成本陡增；過少限制并行度
• schema 無約束：序列化隨意 → 引入 Schema Registry，版本演進有序
• 忽視跨數據中心/多活：需評估 MirrorMaker 2 / Flink CDC / 云托管多區域復制方案

十一、結語

把 Kafka 用對地方，你會得到一條既能頂住流量、又能回溯歷史，還能驅動實時決策的“數據中樞神經”。
從消息解耦到點擊流，從運維指標到日志聚合，再到流式計算與事件溯源，Kafka 提供了統一的抽象與工業級的可靠性。