# 虎年行大運 ~ Kafka - 介紹

## 【What is Kafka?】
**Kafka** 是由 Apache 軟體基金會開發的專門處理訊息串流的服務平台，其底層是由 Java 和 Scala 撰寫開發完成。主要負責訊息的接收與處理和後續的發送。

最初由 **LinkedIn** 開發，並於 2011 年開放原始碼，在 2012 年由 Apache 發布穩定版本。

而所謂的專門，指的便是面對 C10K、C100K 等級的訊息流量還能夠保持正常運行的硬實力

當然其所需要耗費的維護成本也相對高些，因此在低流量的商業服務中，並不需要特別架設 Kafka 的服務，可能 AWS 的 SQS、Redis 都可以暫且充當 MQ 的角色。
> 甚至可能不需要 MQ...

總而言之，如果你的商業服務正面臨著巨大的商業流量需求，而數據讀寫的速度與交流方式一直有交互影響的問題產生，那 Kafka 很適合幫助你解決這些困擾！

## 【優勢】
- **解耦合**
為了傳遞資料訊息，服務與服務之間必須要相互連接，因此就產生了高耦合的壞處，這並不符合「低耦合、高內聚」的設計精神，因此勢必在眾多需要交換資料的服務中，會需要一個統一處理資料的中心，Kafka 正好適合這個中間人的角色，他幫助所有服務斷開彼此的耦合，並把訊息的接收、處理、通知工作全攬在身上，服務們只需要送入資料、等待資料處理完成的通知，然後再做取資料即可。

- **擴展性佳**
Kafka 本身的服務也是一個集群，能透過增添更多的 Kafka 服務輕鬆擴展，且就算要減少集群的服務也算容易，Kafka 本身面對服務的擴展與減少都有很強的自動調整機制，當然減少的風險還是比增加的高很多，因為為了配合既存資料的備份與轉換身分(後續會提到)，這點要多加注意！

- **持久化**
為了避免訊息的遺失，Kafka 在保存上會直接將訊息寫入資料檔，並存於 Logs 資料夾底下，直到被正確的使用完畢後才刪除(甚至根本不刪除)。同時訊息會同步備份在不同 Kafka 服務中。

- **可恢復性**
當個別的服務停止運行時，尚且能夠在其他服務中找到相同的資料，不影響整體系統。在服務恢復運行後，會自動重新進入集群，無須再重啟所有 Kafka 項目。

- **保證資料順序**
Kafka 提供不同的區域存放資料，通常也被拿來做分類使用，Kafka 保證分區的資料順序性，但不保證不同分區的順序。通常一區域會完全放置相同類型的資料，以確保順序，但若是存放備份資料的區域則不太考慮此情況。

- **支援異步處理**
資料送入，在經過處理後，可經由設定自動發送通知，通知其他服務來取資料使用，讓服務之間不再需要互相等待。

- **緩衝**
Kafka 處理好的資料並不是透過自己傳送給需要資料的服務，僅是做到送出通知，而接收通知的服務則自行過來取用資料，這樣的好處是避免雙方的硬體設備、網路環境差異導致處理效益不彰。

## 【缺點】
- **配置參數過多**
這可以是優點，也可以是缺點。

好處是可調整性高，且 Kafka 的預設參數偏向效能取向，所以在不要求多高安全性的情況下，基本不太需要調整。

壞處就是如果要將其安全性調整的高一些，那麼首先要了解所有參數的設置方式與其影響，講一句簡單的: 如果覺得調整 JVM 不是一件難事且很享受，那調整 Kafka 你會得到相同程度的愉悅快感。

- **複雜的建置過程**
在建立代理連線或發現服務上，Kafka 都不是非常友善，若沒有透過 ZooKeeper 的話，非常容易讓新手撞壁。簡單來說幾乎是綁死 ZooKeeper 服務在一包裡。

- **分區不保證資料順序、資料可能重複等**
這個可以透過同類型的資料送入同區得到解決，但在初期尚未釐清其寫入資料的流程與方式前，這會是一個困擾許多人的點，畢竟辛苦建立起的東西居然無法解決這些順序或重複資料的問題也太奇怪了。

## 【傳送方式】
- **點對點模式**
處理好的資料只往一個點送通知，並等待被取出。被取出後的資料便會自動在 Kafka 中刪除。

- **發布/訂閱模式 (Kafka 主推)**
處理好的資料會往多個點推送通知，後續流程如上，但資料會保存在 Kafka 中更久的時間(甚至不刪除)。

## 【結語】
簡單的介紹一下優缺點，下一篇開始介紹其架構，Kai 希望能用簡單的方式帶大家讀懂 Kafka 的資料流程。

首頁 [Kai 個人技術 Hackmd](/2G-RoB0QTrKzkftH2uLueA)

###### tags: `Kafka`