前言

簡單整理一些kafka的設計。

正文

前文提及到log 的重要性，以及kafka在其中的作用，起著一個日誌管理分發的作用，對於其他服務來說相當於新聞報社，訂閱某種主題就會收到某類資訊。

當人們意識到事件狀態的重要性的時候，當時還沒有日誌管理系統，可能像下面這樣:

他們各自傳遞著各自的事件狀態給需要的服務，有點亂且難以維護。

於是為了給他們解耦，就出現了下面這樣的:

這種模式解決了日誌分發問題。

這種模式的出現是否解決了各種服務之間日誌的共享。

現在日誌和資料庫似乎沒有什麼關聯了，也就是事件狀態的出現滿足了新的需求，並沒有和事物的狀態有什麼影響，似乎這兩者在並行的發展。

在事物狀態歷史發展中，出現了一種東西叫做也就是資料倉庫。

通過清洗業務倉庫裡面的東西來進行對聚合整理，這個清洗過程叫做etl，也就是extract-transform-load.

顧明思議哈，收集、轉換、載入。

ETL是將業務系統的資料經過抽取、清洗轉換之後載入到資料倉庫的過程，目的是將企業中的分散、零亂、標準不統一的資料整合到一起，為企業的決策提供分析依據， ETL是BI（商業智慧）專案重要的一個環節。

這東西有什麼作用呢，比如說，要查詢進一個月每天的訂單，如果直接這樣查的話，一個是資料庫語句難寫，有人可能會問怎麼就難寫哈，不就是group by 聚合嗎，但是還有一個問題那就可能有一天沒有訂單哈。

第二個問題就是效能消耗大，假如訂單多的話，做group by 也是很損耗的。 elk 可以做一些簡單的工作，比如說每天統計一次訂單數量，然後查詢的時候複雜度就很低了，現在的資料庫設計更偏向於設計更加簡單的資料表，而不是寫複雜的語句，語句寫的複雜更多的可能是資料庫設計問題。

資料倉庫對於分析很有作用。但是傳統的資料倉庫有一個問題，那就是一般清洗過程是定時去業務資料庫裡面取資料哈。

且不從技術層面上考慮效能問題， 有一個問題就是時效性，也就是說無法對現有的資料進行監控。

然後還有另外一個問題，似乎資料倉庫是一個獨立的服務了，和其他服務脫鉤了，取資料也是直接面向資料庫，處理的結果也無法反饋到其他服務中去。

資料倉庫服務，似乎成了業務孤島。那麼怎麼協調他們呢，日誌系統去協調他們。

各自的服務傳送各自的事件進入日誌系統，elk 訂閱這些進入到資料倉庫中，資料倉庫又反饋給自動化營銷服務中。

這也對服務提出了新的需求了，也就是資料的釋出者。 比如說使用者的退款，那麼產生的事件裡面有: 訂單id 使用者id 退款時間，這樣似乎就能對這件事情的狀態有了描述了。

但是更多的是在釋出的時候就進行了清洗，裡面的事件裡面有： 訂單id 使用者id 訂單金額 退款金額 退款商品 退款數量 退款時間等（什麼人在什麼地點幹了一件什麼事） 這些清洗好的資料，這樣elk 的負擔相對小很多，如果需要查詢商品的退款情況，就很明白了。

而對於市場服務的效能上也沒有很大的問題，因為在退款上本來就要查詢訂單，順便清洗。對於擴充套件性，如果有新的服務，那麼可以定義新的資料模型釋出即可。

這些也就是事件驅動了，事件驅動是指在持續事務管理過程中，進行決策的一種策略，即跟隨當前時間點上出現的事件，調動可用資源，執行相關任務，使不斷出現的問題得以解決，防止事務堆積。在計算機程式設計、公共關係、經濟活動等領域均有應用。

事件驅動達到了很好的解耦的目的，比如說商家訂單支付完，然後要進行騎手送餐，市場服務只需要完成自己的事情即可，然後傳送事件到kafka即可。

那麼對於日誌業務的可擴充套件性，kafka 是能滿足的。

需求基本滿足了，通過這種日誌的訂閱釋出是可以達到需求的。

那麼就開始考慮到實際情況，各個服務的日誌是很龐大的，那麼是否kafka能滿足呢？

最簡單的一個問題，就是生產和消費的速度很有可能不一致。很有可能就是生產要大於消費，可能遠大於。

畢竟生產沒啥業務邏輯，消費的時候可能就要複雜的業務邏輯了。

故而kafka 一個主題可以有多個分割槽:

且每個分割槽的消費都是順序的。

後來又出現了流處理，那麼什麼是流處理呢？

上面介紹了，有了日誌系統後將數倉業務和線上業務打通了，業務服務有也承擔著一部分清洗功能。

但是面對著大量的資料，可能就處理不過來，有hadoop 這種這種是批處理程式，但是無法到達實時。

比如說可能能達到這個使用者幾天沒有續費，然後發個問卷調查，但是無法達到下面這種。

達不到使用者如果連輸輸了15把，給一張優惠券的目的，使用者贏了10把，匹配更強對手的戰略營銷。

尤其是贏了10把，下一把匹配更強了，這就需要計算實效非常高。

為啥有專門的流處理呢？ 自己寫個服務進行處理不是也挺好嗎。其實自己寫服務達到流處理，也是可以的呀，但是可能面對資料太大，撐不住啊，但是隻能說人家更專業，在低延遲、高吞吐、結果和準確性和良好的容錯性上。

然而最關鍵的不是處理能力問題，而是流式處理是一門學問。

那麼為什麼hadoop 一開始不做成這種流式的呢？ 是不是當時就沒有這個需求呢。 肯定是有需求的，不然後面也不會出現流處理。那到底是什麼問題呢？僅僅是處理能力的問題嗎？ 這就是流式的學問了。

結

下一節正式kafka 整理。