緣起

身為鐵人賽多年忠實讀者的我，沒想到有一天會親自上場，突破舒適圈只需要一股衝動，身為middle碼農的我被某人一個推坑，回過神就已經在打這篇開頭了。

為什麼選擇 Kafka 作為主題

Kafka的命名就是由捷克著名的作家卡夫卡而來，2011年LinkedIn開源出來，2012年被Apache孵化，近幾年已經被各大科技公司廣泛使用，雖然Kafka已經出來很多年，在survey相關資訊時發現中文資源還是相對偏少，如果可以利用鐵人賽將Kafka做個簡單介紹，相信對於各位有需要的攻城獅們會有所幫助，或是根本就是半年後的自己。

Kafka 是什麼

A distributed streaming platform
這是 Kafka 官網給自己下的定義，由此可知 Kafka 並只是單純的一個 Message Queue，而是一個分布式的資訊串流平台，可以讓你發佈、訂閱、處理資料串流，擁有分布性、性能極強、可擴充性很高 I/O 吞吐量，並且在高吞吐量下還可以維持低延遲。

Kafka 的使用場景

=> 圖片引用至 Apache Kafka 官網

• 系統監控：這是 LinkedIn 最一開始開發 Kafka 的使用目的，將每台服務的 CPU數據、IO、request、connect..等資料進行統計分析。
• 訊息系統：一般的使用場景在於異步處理、將糾纏的服務解耦，使用方式類似於常見 ActiveMQ 或是 RabbitMQ。但 Kafka 的優勢是擁有低延遲且更大的吞吐量，內建的 partition 和 replica 副本制度，可以保證資料的持久性，這也是一般 MQ 系統所沒能擁有的。
• 操作記錄：將使用者的各種行為儲存下來，並利用即時的發佈、訂閱系統將資料做立即的處理、監控，或是將資料放到離線的 hadoop 系統作分析。

Kafka 的優點

• 具有擴展性：因為 Kafka 的資料是持久化的，不會因為有消費者消費而消失，並且 Kafka 可以將你複雜的應用系統解耦，因此需要擴張的時候，不需要新增程式，也不需要調整參數，只需要另外增加消費者來處理資料即可。
• 避免峰值：在瞬間大流量的使用場景下，Kafka 可以將避免應用服務的崩潰，不會因為超過負載的流量請求而停止運作。
• 保證其順序性：這也是 Kafka 讀取速度的保證，因為磁碟順序讀取的速度較隨機存入快很多，大部分的 MQ 設計本身就是有順序性的隊列，而 Kafka 在這裡保證的是每一個 paritition 中資料的順序性，但不能保證同時讀取多個 partition 的順序性，因此比較適用的場景是不在乎資料前後順序的使用狀況。
• 持久性：使用 MQ 的過程常常會遇到，資料尚未被持久化就遺失的情況，Kafka 可以保證資料已經同步到多個副本後才進行 commit，可以盡量避免資料遺失的狀況，在實際使用場景上，像是 Producer 或是 Consumer 連結斷線的資料遺失也都有相對性的設定可以極大程度地去避免掉。

Kafka 的缺點

• Kafka 有點肥，你只是單純需要訊息對列這個功能，那就用 RabbitMQ 吧，如果你系統每天僅需要處理幾千、幾萬條訊息，Kafka 不管是初始的部署和維運都需要不少的成本，因此吞吐量較小的話就不建議使用了
• Kafka 生產者有可能會重複消費訊息
• Kafka 是利用順序寫入來達到高吞吐量，但是其中一台機器掛掉後，就會導致訊息亂序
• 第三方套件未成熟、仍然有很多功能不支援，社群的活躍性交低
• 僅保證單一分區有順序性，但無法保證多分區的順序性
• 監控資源不完整，需要額外安裝套件
• 依賴 Zookeeper，還要額外花費成本維護 Zookeeper
• 實際上訊息是批次傳送，所以並不是絕對的實時的

Your business is in motion. Now, you have a data platform for it. Confluent makes it easy to connect your apps, systems, and your entire organization with real-time data flow and processing.

接下來30天讓我們一步步慢慢探索Kafka的世界，目前規劃綱要是：基礎的介紹、安裝和內建的腳本使用、常用指令介紹和設定、進階使用介紹

希望可以順利完賽、鐵人鍊成!

資料來源:
https://www.confluent.io/what-is-apache-kafka