Apache Kafka - 流處理平臺

參考資料

1、官方網站:http://kafka.apache.org/
2、中文網站](https://kafka.apachecn.org/

Kafka 介紹

Kafka 是由 Apache 軟件基金會開發的一個開源流處理平臺,由 Scala 和 Java 編寫。Kafka 是一種高吞吐量的分佈式發佈訂閱消息系統,它可以處理消費者在網站中的所有動作流數據。

Kafka 模式

點對點:消費者主動拉取數據,消費後,消息清除。
發佈訂閱:消費者主動拉取數據,消費後,消息不會被清除。

Kafka 集羣

1、Kafka 集羣依賴於 Zookeeper。
2、每個 Kafka 實例都必須有一個唯一整數的 broker_id。
3、可以在 Zookeeper 中執行 shell 腳本,來進行 Kafka 集羣的全部開啓和全部關閉。
4、主題消息默認會保留 Kafka 實例中7天。
5、集羣中,可以設置主題的分區和副本,副本至少一個,且不能超過 Kafka 節點個數。
6、集羣接受主題消息時,默認按照輪詢方式進行負載均衡。

使用場景

異步處理

場景說明:用戶註冊後,需要發註冊郵件和註冊短信。傳統的做法有兩種 1.串行的方式;2.並行方式。

串行方式:將註冊信息寫入數據庫成功後,發送註冊郵件,再發送註冊短信。三個任務全部完成後,響應給客戶端。

並行方式:將註冊信息寫入數據庫成功後,同時發送註冊郵和註冊短信。三個任務完成後,返回給客戶端,可以提高處理的時間。

假設三個業務節點每個使用50毫秒鐘,不考慮網絡等其他開銷,則串行方式的時間是150毫秒,並行的時間可能是100毫秒。
因爲CPU在單位時間內處理的請求數是一定的,假設CPU1秒內吞吐量是100次。則串行方式1秒內CPU可處理的請求量是7次(1000/150)。並行方式處理的請求量是10次(1000/100)。

引入隊列:將不是必須的業務邏輯,異步處理。改造後的架構如下:

按照以上約定,用戶的響應時間相當於是註冊信息寫入數據庫的時間,也就是50毫秒。註冊郵件,發送短信寫入消息隊列後,直接返回,因此寫入消息隊列的速度很快,基本可以忽略,因此用戶的響應時間可能是50毫秒。因此架構改變後,系統的吞吐量提高到每秒20 次。比串行提高了3倍,比並行提高了兩倍。

應用解耦

場景說明:用戶下單後,訂單系統需要通知庫存系統。傳統的做法是,訂單系統調用庫存系統的接口。如下圖:

傳統模式的缺點:假如庫存系統無法訪問,則訂單減庫存將失敗,從而導致訂單失敗,訂單系統與庫存系統耦合。

如何解決以上問題呢?引入應用消息隊列後的方案,如下圖:

訂單系統:用戶下單後,訂單系統完成持久化處理,將消息寫入消息隊列,返回用戶訂單下單成功。
庫存系統:訂閱下單的消息,採用拉/推的方式,獲取下單信息,庫存系統根據下單信息,進行庫存操作。
假如:在下單時庫存系統不能正常使用。也不影響正常下單,因爲下單後,訂單系統寫入消息隊列就不再關心其他的後續操作了。
實現訂單系統與庫存系統的應用解耦。

流量削鋒

流量削鋒也是消息隊列中的常用場景,一般在秒殺或團搶活動中使用廣泛。
應用場景:秒殺活動,一般會因爲流量過大,導致流量暴增,應用掛掉。爲解決這個問題,一般需要在應用前端加入消息隊列。
a、可以控制活動的人數。
b、可以緩解短時間內高流量壓垮應用。

用戶的請求,服務器接收後,首先寫入消息隊列。假如消息隊列長度超過最大數量,則直接拋棄用戶請求或跳轉到錯誤頁面。
秒殺業務根據消息隊列中的請求信息,再做後續處理。

日誌處理

日誌處理是指將消息隊列用在日誌處理中,比如Kafka的應用,解決大量日誌傳輸的問題。架構簡化如下:

日誌採集客戶端,負責日誌數據採集,定時寫受寫入Kafka隊列。
Kafka消息隊列,負責日誌數據的接收,存儲和轉發。
日誌處理應用:訂閱並消費kafka隊列中的日誌數據。

消息通訊

消息通訊是指,消息隊列一般都內置了高效的通信機制,因此也可以用在純的消息通訊。比如實現點對點消息隊列,或者聊天室等。

點對點通訊:客戶端A和客戶端B使用同一隊列,進行消息通訊。

聊天室通訊:客戶端A,客戶端B,客戶端N訂閱同一主題,進行消息發佈和接收。

以上實際是消息隊列的兩種消息模式,點對點模式和發佈訂閱模式。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章