一．了解淘寶Kafka架構(gòu)

在ActiveMQ芦倒、RabbitMQ、RocketMQ赴叹、Kafka消息中間件之間刘绣，我們?yōu)槭裁匆x擇Kafka?下面詳細介紹一下震肮，2012年9月份我在支付寶做余額寶研發(fā)，2013年6月支付寶正式推出余額寶奕翔，2013年8月?lián)沃Ц秾毺詫毑势表椖拷?jīng)理帶領(lǐng)兄弟們一起做研發(fā)拇舀，期間需要與淘寶和500萬對接競彩接口數(shù)據(jù)孤里，業(yè)余時間與淘寶的同事溝通姻政，了解天貓在電商節(jié)如何處理這些大數(shù)據(jù)的傲霸？技術(shù)架構(gòu)上采用了哪些策略呢？

一是辕、應用無狀態(tài)(淘寶session框架)

二囤热、有效使用緩存(Tair)

三、應用拆分(HSF)

四免糕、數(shù)據(jù)庫拆分(TDDL)

五赢乓、異步通信(Notify)

六忧侧、非結(jié)構(gòu)化數(shù)據(jù)存儲 ( TFS,NOSQL)

七石窑、監(jiān)控、預警系統(tǒng)

八蚓炬、配置統(tǒng)一管理

天貓的同事把大致的架構(gòu)跟我描述了一番松逊，心有感悟。咱們來看一下2018年雙11當天的成交額肯夏。

二．kafka實現(xiàn)天貓億萬級數(shù)據(jù)統(tǒng)計架構(gòu)

Flume是Cloudera提供的一個高可用的经宏，高可靠的，分布式的海量日志采集驯击、聚合和傳輸?shù)南到y(tǒng)烁兰，F(xiàn)lume支持在日志系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)徊都；同時沪斟，F(xiàn)lume提供對數(shù)據(jù)進行簡單處理，并寫到各種數(shù)據(jù)接受方（可定制）的能力

Data Access：數(shù)據(jù)通道

Computing：計算

Persistence：執(zhí)行保存方式

spout：表示一個流的源頭暇矫，產(chǎn)生tuple

bolt：處理輸入流并產(chǎn)生多個輸出流主之，可以做簡單的數(shù)據(jù)轉(zhuǎn)換計算，復雜的流處理一般需要經(jīng)過多個bolt進行處理

為什么不能用分布式文件HDFS集群李根？

1槽奕、實時性：hdfs的實時性沒有kafka高。

2房轿、消費量的記錄：hdfs不會記錄你這個塊文件消費到了哪里粤攒，而基于zookeeper的kafka會記錄你消費的點所森。

3、并發(fā)消費：hdfs不支持并發(fā)消費夯接，而kafka支持并發(fā)消費必峰，即多個consumer.

4、彈性且有序：當數(shù)據(jù)量會很大钻蹬，而且處理完之后就可以刪除時吼蚁，頻繁的讀寫會對hdfs中NameNode造成很大的壓力。而kafka的消費點是記錄在zookeeper的问欠，并且kafka的每條數(shù)據(jù)都是有“坐標”的肝匆，所以消費的時候只要這個“坐標”向后移動就行了，而且刪除的時候只要把這個“坐標”之前的數(shù)據(jù)刪掉即可顺献。

三．什么是Kafka?

通過上圖就可以了解到旗国，生產(chǎn)者Producers(農(nóng)民和廚師)，消費主題top(魚注整，骨頭能曾，草，香蕉),消費者Comsumer(貓肿轨，狗寿冕，老牛，猴子)椒袍，生產(chǎn)者根據(jù)消費主題獲取自己想要的食物

四．Kafka架構(gòu)原理

五．Kafka能幫我們解決什么問題驼唱？

請高手指明一下kafka解決了什么問題，什么場景下使用驹暑？消息訂閱和發(fā)布嗎玫恳，好像redis也支持，功能是否有重疊优俘？

一．消息隊列

假設(shè)你意氣風發(fā)京办，要開發(fā)新一代的互聯(lián)網(wǎng)應用，以期在互聯(lián)網(wǎng)事業(yè)中一展宏圖帆焕。借助云計算惭婿，很容易開發(fā)出如下原型系統(tǒng)：

Web應用：部署在云服務(wù)器上，為個人電腦或者移動用戶提供的訪問體驗视搏。

SQL數(shù)據(jù)庫：為Web應用提供數(shù)據(jù)持久化以及數(shù)據(jù)查詢审孽。

這套架構(gòu)簡潔而高效，很快能夠部署到百度云等云計算平臺浑娜，以便快速推向市場佑力。互聯(lián)網(wǎng)不就是講究小步快跑嘛筋遭！

好景不長打颤。隨著用戶的迅速增長暴拄，所有的訪問都直接通過SQL數(shù)據(jù)庫使得它不堪重負，不得不加上緩存服務(wù)以降低SQL數(shù)據(jù)庫的荷載编饺；為了理解用戶行為乖篷，開始收集日志并保存到Hadoop上離線處理，同時把日志放在全文檢索系統(tǒng)中以便快速定位問題透且；由于需要給投資方看業(yè)務(wù)狀況撕蔼，也需要把數(shù)據(jù)匯總到數(shù)據(jù)倉庫中以便提供交互式報表。此時的系統(tǒng)的架構(gòu)已經(jīng)盤根錯節(jié)了秽誊，考慮將來還會加入實時模塊以及外部數(shù)據(jù)交互鲸沮，真是痛并快樂著……

這時候，應該跑慢一些锅论，讓靈魂跟上來讼溺。

本質(zhì)上，這是一個數(shù)據(jù)集成問題最易。沒有任何一個系統(tǒng)能夠解決所有的事情怒坯，所以業(yè)務(wù)數(shù)據(jù)根據(jù)不同用途存而放在不同的系統(tǒng)，比如歸檔藻懒、分析剔猿、搜索、緩存等束析。數(shù)據(jù)冗余本身沒有任何問題艳馒，但是不同系統(tǒng)之間像意大利面條一樣復雜的數(shù)據(jù)同步卻是挑戰(zhàn)憎亚。

這時候就輪到Kafka出場了员寇。

Kafka可以讓合適的數(shù)據(jù)以合適的形式出現(xiàn)在合適的地方。Kafka的做法是提供消息隊列第美，讓生產(chǎn)者單往隊列的末尾添加數(shù)據(jù)蝶锋，讓多個消費者從隊列里面依次讀取數(shù)據(jù)然后自行處理。之前連接的復雜度是O(N^2)什往，而現(xiàn)在降低到O(N)扳缕，擴展起來方便多了：

在Kafka的幫助下，你的互聯(lián)網(wǎng)應用終于能夠支撐飛速增長的業(yè)務(wù)别威，成為下一個BAT指日可待躯舔。

以上故事說明了Kafka主要用途是數(shù)據(jù)集成，或者說是流數(shù)據(jù)集成省古，以Pub/Sub形式的消息總線形式提供粥庄。但是，Kafka不僅僅是一套傳統(tǒng)的消息總線豺妓，本質(zhì)上Kafka是分布式的流數(shù)據(jù)平臺惜互，因為以下特性而著名：

提供Pub/Sub方式的海量消息處理布讹。

以高容錯的方式存儲海量數(shù)據(jù)流。

保證數(shù)據(jù)流的順序训堆。

二．日志采集

隨著互聯(lián)網(wǎng)的不斷發(fā)展描验，用戶所產(chǎn)生的行為數(shù)據(jù)被越來越多的網(wǎng)站重視，如何對于用戶信息進行采集則越來越受到重視坑鱼，下面就為大家介紹基于Kafka的服務(wù)端用戶行為日志采集方式膘流。

1. 技術(shù)選型

服務(wù)端日志采集主要通過在Controller的接口中進行埋點，然后通過AOP技術(shù)鲁沥、Kafka消息系統(tǒng)以及l(fā)ogback對用戶行為進行采集睡扬。

之所以使用AOP技術(shù)是因為AOP的以下重要特定：

代碼的侵入性小。對于業(yè)務(wù)代碼的侵入性小黍析，只需要在Controller的接口上添加注解卖怜，然后在其他模塊對用戶行為進行采集。

重用性阐枣。對于相同作用的代碼可以進行重用马靠。

擴展性。能夠很好的對系統(tǒng)進行擴展蔼两。

由于使用異步方式對用戶行為信息進行收集甩鳄，因此需要使用消息中間件。目前消息中間件非常多额划，比較流行的有ActiveMQ妙啃、ZeroMQ、RabbitMQ俊戳、Kafka等揖赴。每個消息中間件都有各種的優(yōu)勢劣勢，之所以使用Kafka消息中間件抑胎，是因為以下幾點因素：

高性能燥滑。每秒鐘可以處理數(shù)以千計生產(chǎn)者生成的消息。

高擴展性阿逃∶。可以通過簡單的增加服務(wù)器橫向擴展Kafka集群的容量。

分布式恃锉。消息來自數(shù)以千計的服務(wù)搀菩，使用分布式來解決單機處理海量數(shù)據(jù)的瓶頸。

持久性破托。Kafka中的消息可以持久化到硬盤上肪跋，這樣可以防止數(shù)據(jù)的丟失。

因為用戶的行為數(shù)據(jù)最終是以日志的形式持久化的炼团，因此使用logback對日志持久化到日志服務(wù)器中澎嚣。

2.總體架構(gòu)

圖1 總體架構(gòu)圖

服務(wù)端日志采集系統(tǒng)主要由兩個工程組成：陸金所-bi-core和lu-bi-service疏尿。由于中國平安陸金所使用dubbo框架，因此有服務(wù)提供方和服務(wù)消費方易桃。lu-bi-core被web褥琐、wap和mainsite服務(wù)消費方依賴。此外晤郑，lu-bi-service也依賴于lu-bi-core敌呈，主要是依賴于其中的一些實體類及工具類。

lu-bi-core工程為Kafka消息的生產(chǎn)者造寝，主要封裝實現(xiàn)切面的具體邏輯磕洪，其主要職責如下：

解析用戶請求的Request信息：從Request中提取用戶的基本信息，如設(shè)備型號诫龙、用戶的供應商析显、ip、設(shè)備的分辨率签赃、設(shè)備平臺谷异、設(shè)備的操作系統(tǒng)、設(shè)備id锦聊、app渠道等歹嘹。

接口對應的參數(shù)：通過切面可以提取接口的參數(shù)值，從而知道用戶的業(yè)務(wù)信息孔庭。

應用層返回的結(jié)果信息：因為切面使用AfterReturning方式尺上，因此可以獲取用層的返回結(jié)果，從返回結(jié)果中可以提取有用的信息圆到。

用戶的基本信息：用戶的id信息怎抛。

信息格式化：將信息轉(zhuǎn)化成JSON字符串。

發(fā)送消息：將最終需要發(fā)送的消息放入本地阻塞隊列中构资，通過另一個線程異步從阻塞隊列中獲取消息并發(fā)送到Kafka Broker中抽诉。

lu-bi-service工程為Kafka消息的消費者，其主要職責如下：

實時從Kafka中拉取最新的數(shù)據(jù)吐绵。

將JSON字符串轉(zhuǎn)化成，方便進一步對用信息進行加工河绽。

對用戶的ip進行解析己单，獲取ip對應的地區(qū)以及經(jīng)緯度信息。

將加工好的最終信息持久化到log文件中耙饰。

3.部署圖

圖2 部署圖

上圖為陸金所與日志系統(tǒng)系統(tǒng)相關(guān)的部署圖纹笼，App、Wap和Mainsite服務(wù)器集群分別對應不同終端的應用苟跪。Kafka集群使用杭研的集群廷痘，目前有10個Broker蔓涧。日志服務(wù)器有兩臺，通過Kafka的均衡策略對日志進行消費笋额。

4.日志采集的流程

日志采集流程圖如下所示：

圖3 日志打點流程圖

上圖為消息生產(chǎn)者和消息消費者共同組成的流程圖元暴。

消息生產(chǎn)者的具體步驟如下：

通過切面攔截用戶的請求。

從切面中提取請求頭的基本信息兄猩，如設(shè)備信息茉盏，cookie信息，ip信息等枢冤。

提取請求的接口參數(shù)信息鸠姨。

從接口返回值中提取相關(guān)信息，如id淹真，pvid等讶迁。

將提取的信息封裝成JSON字符串，放到阻塞隊列中核蘸，假如阻塞隊列溢出會有三次重試機制添瓷。

異步線程從本地阻塞隊列中獲取數(shù)據(jù)，并將信息組裝發(fā)送到Kafka的Broker中值纱，此時消息生產(chǎn)者結(jié)束鳞贷。

消息消費者的具體步驟如下：

實時從Kafka Broker中批量拉取消息。

將拉取的消息轉(zhuǎn)化成對象虐唠。

解析ip對應的國家搀愧、省份、城市疆偿、經(jīng)緯度信息咱筛。

對不同業(yè)務(wù)場景的信息進一步解析。

將日志信息轉(zhuǎn)化成JSON字符串杆故，持久化到log文件中迅箩。

5. 相關(guān)配置

application-XXX.properties：該配置放Kafka的相關(guān)屬性，包括topic处铛、groupId饲趋、server等信息。

lu-log-msg.xml：該配置放在app-web撤蟆，mainsite-web奕塑，wap-web的src/main/resources目錄下，主要是初始化kafka生產(chǎn)者的信息家肯。

lu-bi-service.xml：該配置放在lu-bi-service工程的src/main/resources目錄下龄砰，主要用于加載kafka消費者的配置信息，并且啟動kafka消費者服務(wù)。

logback.xml：該配置放在lu-bi-service工程的src/main/resources目錄下换棚，主要用于聲明日志文件存放的目錄式镐，需要持久化的日志的package路徑，以及日志持久化的格式固蚤。

ip_conf.txt：該配置放在lu-bi-service工程的src/main/resources目錄下娘汞，用于解析ip對應的地域、經(jīng)緯度等信息颇蜡。

六．關(guān)于面試問題

1.Redis和Kafka區(qū)別价说？

作者跟大家舉個例子：

老板有個好消息要告訴大家，公司要發(fā)放年終獎风秤，有兩個辦法:

1.到會議室每個座位上挨個兒告訴每個人鳖目。什么？張三去上廁所了缤弦？那張三就只能錯過好消息了领迈！

2.老板把消息寫到會議上的黑板報上，誰想知道就來看一下碍沐，什么狸捅？張三請假了？沒關(guān)系累提，我一周之后才擦掉尘喝，總會看見的！什么張三請假兩周斋陪？那就算了朽褪，我反正只保留一周，不然其他好消息沒地方寫了

redis用第一種辦法无虚，kafka用第二種辦法缔赠，知道什么區(qū)別了吧

Redis PUB/SUB使用場景：

1. 消息持久性需求不高

2. 吞吐量要求不高

3. 可以忍受數(shù)據(jù)丟失

4. 數(shù)據(jù)量不大

Kafka使用場景：

上面以外的其他場景：）

1. 高可靠性

2. 高吞吐量

3. 持久性高

Kafka、RabbitMQ友题、RocketMQ等消息中間件的對比

有關(guān)測試結(jié)論

Kafka的吞吐量高達17.3w/s嗤堰，不愧是高吞吐量消息中間件的行業(yè)老大。這主要取決于它的隊列模式保證了寫磁盤的過程是線性IO度宦。此時broker磁盤IO已達瓶頸踢匣。

RocketMQ也表現(xiàn)不俗，吞吐量在11.6w/s斗埂，磁盤IO %util已接近100%符糊。RocketMQ的消息寫入內(nèi)存后即返回ack，由單獨的線程專門做刷盤的操作呛凶，所有的消息均是順序?qū)懳募?/p>

RabbitMQ的吞吐量5.95w/s，CPU資源消耗較高行贪。它支持AMQP協(xié)議漾稀，實現(xiàn)非常重量級模闲，為了保證消息的可靠性在吞吐量上做了取舍。我們還做了RabbitMQ在消息持久化場景下的性能測試崭捍，吞吐量在2.6w/s左右尸折。

在服務(wù)端處理同步發(fā)送的性能上，Kafka>RocketMQ>RabbitMQ

寫在最后

如今都在談?wù)摵卸嗫膳乱笊撸P者作為一個過來人实夹，卻有不同的看法：寒冬不可怕，在寒冬里沒有生存能力粒梦，才是最可怕的亮航。

因此小編總結(jié)了這幾年在阿里的工作經(jīng)驗并結(jié)合目前互聯(lián)網(wǎng)最主流的Java架構(gòu)技術(shù)，最后錄制了七大Java架構(gòu)技術(shù)專題視頻（源碼閱讀匀们、分布式架構(gòu)缴淋、微服務(wù)、性能優(yōu)化泄朴、阿里項目實戰(zhàn)重抖、Devops、并發(fā)編程）分享在我的裙669275137中祖灰，并且每晚我都會在群內(nèi)直播講解這些架構(gòu)技術(shù)的底層實現(xiàn)原理钟沛，感興趣的程序員們可以加群找管理員獲取。