一．瞭解淘寶Kafka架構
在ActiveMQ、RabbitMQ、RocketMQ、Kafka訊息中介軟體之間，我們為什麼要選擇Kafka?下面詳細介紹一下，2012年9月份我在支付寶做餘額寶研發，2013年6月支付寶正式推出餘額寶，2013年8月擔任支付寶淘寶彩票專案經理帶領兄弟們一起做研發，期間需要與淘寶和500萬對接競彩介面資料，業餘時間與淘寶的同事溝通，瞭解天貓在電商節如何處理這些大資料的？技術架構上採用了哪些策略呢？
一、應用無狀態(淘寶session框架)
二、有效使用快取(Tair)
三、應用拆分(HSF)
四、資料庫拆分(TDDL)
五、非同步通訊(Notify)
六、非結構化資料儲存 ( TFS,NOSQL)
七、監控、預警系統
八、配置統一管理
天貓的同事把大致的架構跟我描述了一番，心有感悟。我們們來看一下2018年雙11當天的成交額。
二．kafka實現天貓億萬級資料統計架構
Flume是Cloudera提供的一個高可用的，高可靠的，分散式的海量日誌採集、聚合和傳輸的系統，Flume支援在日誌系統中定製各類資料傳送方，用於收集資料；同時，Flume提供對資料進行簡單處理，並寫到各種資料接受方（可定製）的能力
- Data Access：資料通道
- Computing：計算
- Persistence：執行儲存方式
- spout：表示一個流的源頭，產生tuple
- bolt：處理輸入流併產生多個輸出流，可以做簡單的資料轉換計算，複雜的流處理一般需要經過多個bolt進行處理
為什麼不能用分散式檔案HDFS叢集？
1、實時性：hdfs的實時性沒有kafka高。
2、消費量的記錄：hdfs不會記錄你這個塊檔案消費到了哪裡，而基於zookeeper的kafka會記錄你消費的點。
3、併發消費：hdfs不支援併發消費，而kafka支援併發消費，即多個consumer.
4、彈性且有序：當資料量會很大，而且處理完之後就可以刪除時，頻繁的讀寫會對hdfs中NameNode造成很大的壓力。而kafka的消費點是記錄在zookeeper的，並且kafka的每條資料都是有“座標”的，所以消費的時候只要這個“座標”向後移動就行了，而且刪除的時候只要把這個“座標”之前的資料刪掉即可。
三．什麼是Kafka?
通過上圖就可以瞭解到，生產者Producers(農民和廚師)，消費主題top(魚，骨頭，草，香蕉),消費者Comsumer(貓，狗，老牛，猴子)，生產者根據消費主題獲取自己想要的食物
四．Kafka架構原理
五．Kafka能幫我們解決什麼問題？
請高手指明一下kafka解決了什麼問題，什麼場景下使用？訊息訂閱和釋出嗎，好像redis也支援，功能是否有重疊？
一．訊息佇列
假設你意氣風發，要開發新一代的網際網路應用，以期在網際網路事業中一展巨集圖。藉助雲端計算，很容易開發出如下原型系統：
- Web應用：部署在雲伺服器上，為個人電腦或者移動使用者提供的訪問體驗。
- SQL資料庫：為Web應用提供資料持久化以及資料查詢。
這套架構簡潔而高效，很快能夠部署到百度雲等雲端計算平臺，以便快速推向市場。網際網路不就是講究小步快跑嘛！
好景不長。隨著使用者的迅速增長，所有的訪問都直接通過SQL資料庫使得它不堪重負，不得不加上快取服務以降低SQL資料庫的荷載；為了理解使用者行為，開始收集日誌並儲存到Hadoop上離線處理，同時把日誌放在全文檢索系統中以便快速定位問題；由於需要給投資方看業務狀況，也需要把資料彙總到資料倉儲中以便提供互動式報表。此時的系統的架構已經盤根錯節了，考慮將來還會加入實時模組以及外部資料互動，真是痛並快樂著……
這時候，應該跑慢一些，讓靈魂跟上來。
本質上，這是一個資料整合問題。沒有任何一個系統能夠解決所有的事情，所以業務資料根據不同用途存而放在不同的系統，比如歸檔、分析、搜尋、快取等。資料冗餘本身沒有任何問題，但是不同系統之間像義大利麵條一樣複雜的資料同步卻是挑戰。
這時候就輪到Kafka出場了。
Kafka可以讓合適的資料以合適的形式出現在合適的地方。Kafka的做法是提供訊息佇列，讓生產者單往佇列的末尾新增資料，讓多個消費者從佇列裡面依次讀取資料然後自行處理。之前連線的複雜度是O(N^2)，而現在降低到O(N)，擴充套件起來方便多了：
在Kafka的幫助下，你的網際網路應用終於能夠支撐飛速增長的業務，成為下一個BAT指日可待。
以上故事說明了Kafka主要用途是資料整合，或者說是流資料整合，以Pub/Sub形式的訊息匯流排形式提供。但是，Kafka不僅僅是一套傳統的訊息匯流排，本質上Kafka是分散式的流資料平臺，因為以下特性而著名：
- 提供Pub/Sub方式的海量訊息處理。
- 以高容錯的方式儲存海量資料流。
- 保證資料流的順序。
二．日誌採集
隨著網際網路的不斷髮展，使用者所產生的行為資料被越來越多的網站重視，如何對於使用者資訊進行採集則越來越受到重視，下面就為大家介紹基於Kafka的服務端使用者行為日誌採集方式。
1. 技術選型
服務端日誌採集主要通過在Controller的介面中進行埋點，然後通過AOP技術、Kafka訊息系統以及logback對使用者行為進行採集。
之所以使用AOP技術是因為AOP的以下重要特定：
- 程式碼的侵入性小。對於業務程式碼的侵入性小，只需要在Controller的介面上新增註解，然後在其他模組對使用者行為進行採集。
- 重用性。對於相同作用的程式碼可以進行重用。
- 擴充套件性。能夠很好的對系統進行擴充套件。
由於使用非同步方式對使用者行為資訊進行收集，因此需要使用訊息中介軟體。目前訊息中介軟體非常多，比較流行的有ActiveMQ、ZeroMQ、RabbitMQ、Kafka等。每個訊息中介軟體都有各種的優勢劣勢，之所以使用Kafka訊息中介軟體，是因為以下幾點因素：
- 高效能。每秒鐘可以處理數以千計生產者生成的訊息。
- 高擴充套件性。可以通過簡單的增加伺服器橫向擴充套件Kafka叢集的容量。
- 分散式。訊息來自數以千計的服務，使用分散式來解決單機處理海量資料的瓶頸。
- 永續性。Kafka中的訊息可以持久化到硬碟上，這樣可以防止資料的丟失。
因為使用者的行為資料最終是以日誌的形式持久化的，因此使用logback對日誌持久化到日誌伺服器中。
2.總體架構
圖1 總體架構圖
服務端日誌採集系統主要由兩個工程組成：陸金所-bi-core和lu-bi-service。由於中國平安陸金所使用dubbo框架，因此有服務提供方和服務消費方。lu-bi-core被web、wap和mainsite服務消費方依賴。此外，lu-bi-service也依賴於lu-bi-core，主要是依賴於其中的一些實體類及工具類。
lu-bi-core工程為Kafka訊息的生產者，主要封裝實現切面的具體邏輯，其主要職責如下：
- 解析使用者請求的Request資訊：從Request中提取使用者的基本資訊，如裝置型號、使用者的供應商、ip、裝置的解析度、裝置平臺、裝置的作業系統、裝置id、app渠道等。
- 介面對應的引數：通過切面可以提取介面的引數值，從而知道使用者的業務資訊。
- 應用層返回的結果資訊：因為切面使用AfterReturning方式，因此可以獲取用層的返回結果，從返回結果中可以提取有用的資訊。
- 使用者的基本資訊：使用者的id資訊。
- 資訊格式化：將資訊轉化成JSON字串。
- 傳送訊息：將最終需要傳送的訊息放入本地阻塞佇列中，通過另一個執行緒非同步從阻塞佇列中獲取訊息併傳送到Kafka Broker中。
lu-bi-service工程為Kafka訊息的消費者，其主要職責如下：
- 實時從Kafka中拉取最新的資料。
- 將JSON字串轉化成，方便進一步對用資訊進行加工。
- 對使用者的ip進行解析，獲取ip對應的地區以及經緯度資訊。
- 將加工好的最終資訊持久化到log檔案中。
3.部署圖
圖2 部署圖
上圖為陸金所與日誌系統系統相關的部署圖，App、Wap和Mainsite伺服器叢集分別對應不同終端的應用。Kafka叢集使用杭研的叢集，目前有10個Broker。日誌伺服器有兩臺，通過Kafka的均衡策略對日誌進行消費。
4.日誌採集的流程
日誌採集流程圖如下所示：
圖3 日誌打點流程圖
上圖為訊息生產者和訊息消費者共同組成的流程圖。
- 訊息生產者的具體步驟如下：
- 通過切面攔截使用者的請求。
- 從切面中提取請求頭的基本資訊，如裝置資訊，cookie資訊，ip資訊等。
- 提取請求的介面引數資訊。
- 從介面返回值中提取相關資訊，如id，pvid等。
- 將提取的資訊封裝成JSON字串，放到阻塞佇列中，假如阻塞佇列溢位會有三次重試機制。
- 非同步執行緒從本地阻塞佇列中獲取資料，並將資訊組裝傳送到Kafka的Broker中，此時訊息生產者結束。
訊息消費者的具體步驟如下：
- 實時從Kafka Broker中批量拉取訊息。
- 將拉取的訊息轉化成物件。
- 解析ip對應的國家、省份、城市、經緯度資訊。
- 對不同業務場景的資訊進一步解析。
- 將日誌資訊轉化成JSON字串，持久化到log檔案中。
5. 相關配置
- application-XXX.properties：該配置放Kafka的相關屬性，包括topic、groupId、server等資訊。
- lu-log-msg.xml：該配置放在app-web，mainsite-web，wap-web的src/main/resources目錄下，主要是初始化kafka生產者的資訊。
- lu-bi-service.xml：該配置放在lu-bi-service工程的src/main/resources目錄下，主要用於載入kafka消費者的配置資訊，並且啟動kafka消費者服務。
- logback.xml：該配置放在lu-bi-service工程的src/main/resources目錄下，主要用於宣告日誌檔案存放的目錄，需要持久化的日誌的package路徑，以及日誌持久化的格式。
- ip_conf.txt：該配置放在lu-bi-service工程的src/main/resources目錄下，用於解析ip對應的地域、經緯度等資訊。
六．關於面試問題
1.Redis和Kafka區別？
作者跟大家舉個例子：
老闆有個好訊息要告訴大家，公司要發放年終獎，有兩個辦法:
1.到會議室每個座位上挨個兒告訴每個人。什麼？張三去上廁所了？那張三就只能錯過好訊息了！
2.老闆把訊息寫到會議上的黑板報上，誰想知道就來看一下，什麼？張三請假了？沒關係，我一週之後才擦掉，總會看見的！什麼張三請假兩週？那就算了，我反正只保留一週，不然其他好訊息沒地方寫了
redis用第一種辦法，kafka用第二種辦法，知道什麼區別了吧
Redis PUB/SUB使用場景：
1. 訊息永續性需求不高
2. 吞吐量要求不高
3. 可以忍受資料丟失
4. 資料量不大
Kafka使用場景：
上面以外的其他場景：）
1. 高可靠性
2. 高吞吐量
3. 永續性高
Kafka、RabbitMQ、RocketMQ等訊息中介軟體的對比
有關測試結論
Kafka的吞吐量高達17.3w/s，不愧是高吞吐量訊息中介軟體的行業老大。這主要取決於它的佇列模式保證了寫磁碟的過程是線性IO。此時broker磁碟IO已達瓶頸。
RocketMQ也表現不俗，吞吐量在11.6w/s，磁碟IO %util已接近100%。RocketMQ的訊息寫入記憶體後即返回ack，由單獨的執行緒專門做刷盤的操作，所有的訊息均是順序寫檔案。
RabbitMQ的吞吐量5.95w/s，CPU資源消耗較高。它支援AMQP協議，實現非常重量級，為了保證訊息的可靠性在吞吐量上做了取捨。我們還做了RabbitMQ在訊息持久化場景下的效能測試，吞吐量在2.6w/s左右。
在服務端處理同步傳送的效能上，Kafka>RocketMQ>RabbitMQ
寫在最後
如今都在談論寒冬有多可怕，筆者作為一個過來人，卻有不同的看法：寒冬不可怕，在寒冬裡沒有生存能力，才是最可怕的。
因此小編總結了這幾年在阿里的工作經驗並結合目前網際網路最主流的Java架構技術，最後錄製了七大Java架構技術專題視訊（原始碼閱讀、分散式架構、微服務、效能優化、阿里專案實戰、Devops、併發程式設計）分享在我的裙669275137中，並且每晚我都會在群內直播講解這些架構技術的底層實現原理，感興趣的程式設計師們可以加群找管理員獲取。