介紹：
Kafka是一個高吞吐量的分佈是消息系統 ，原本開發自LinkedIn，用作LinkedIn的活動流（activity stream）和運營數據處理管道（pipeline）的基礎。現在它已爲多家不同類型的公司作爲多種類型的數據管道（data pipeline）和消息系統使用。
現在Kafak作爲apache的項目，被apache託管。
企業應用的背景：
企業集成的基本特點是把企業中現存的本不相干的各種應用進行集成。例如：一個企業可能想把財務系統和倉管系統進行集成，減少部門間結算和流通的成本和時間，並能更好的支持上層決策。但這兩個系統是由不同的廠家做的，不能修改。另外企業集成是一個持續漸進的過程，需求變化非常頻繁。這對MQ系統的要求是要非常靈活，可定製性要求高。所以常見的MQ系統通常都可以通過複雜的xml配置或插件開發進行定製以適應不同企業的業務流程的需要。他們大多數都能通過配置不同程度的支持EIP中定義一些模式。但設計目標並沒有很重視擴展性和性能，因爲通常企業級應用的數據流和規模都不會非常大。即使有的比較大，使用高配置的服務器或做一個簡單幾個節點的集羣就可以滿足了。
大規模的service是指面向公衆的向facebook，google，linkedin和taobao這樣級別或有可能成長到這個級別的應用。相對企業集成來講，這些應用的業務流程相對比較穩定。子系統間集成的業務複雜度也相對較低，因爲子系統通常也是經過精心選擇和設計的並能做一定的調整。所以對MQ系統的可定製性及定製的複雜性要求並不高。但由於數據量會非常巨大，不是幾臺Server能滿足的，可能需要幾十甚至幾百臺，且對性能要求較高以降低成本，所以MQ系統需要有很好的擴展性。
kafka正是一個滿足SaaS要求的MQ系統，它通過降低MQ系統的複雜度來提高性能和擴展性。
使用場景：
- 消息處理。Kafka可以用來替代傳統的消息系統。與傳統的消息系統相比，Kafka有更好的吞吐量，分隔，複製，負載均衡和容錯能力。
- 網頁動態跟蹤。最初的Kafak就是以管道的方式使用發佈訂閱的，構建一個用戶的活動跟蹤系統的管道。
- 運營數據監控。用來作爲監控系統運營的數據管道。
- 日誌聚合。將不同系統，不同平臺的日誌聚合到一起做集中處理，很多場景用來做爲一個日誌聚合的解決方案。
- 流處理。通過對原始數據的聚合，富有化，轉化，包裝成新的數據，再次發佈成消息供以後使用。
可靠性（一致性)
MQ要實現從producer到consumer之間的可靠的消息傳送和分發。傳統的MQ系統通常都是通過broker和consumer間的確認（ack）機制實現的，並在broker保存消息分發的狀態。即使這樣一致性也是很難保證的（當然kafka也支持ack）。kafka的做法是由consumer自己保存狀態，也不要任何確認。這樣雖然consumer負擔更重，但其實更靈活了。因爲不管consumer上任何原因導致需要重新處理消息，都可以再次從broker獲得。
kafka的producer有一種異步發送的操作。這是爲提高性能提供的。producer先將消息放在內存中，就返回。這樣調用者（應用程序）就不需要等網絡傳輸結束就可以繼續了。內存中的消息會在後臺批量的發送到broker。由於消息會在內存呆一段時間，這段時間是有消息丟失的風險的。所以使用該操作時需要仔細評估這一點。
高可用性
Kafaka可以將log文件複製到其他topic的分隔點(可以看成是server)。當一個server在集羣中fails，可以允許自動的failover到其他的複製的server，所以消息可以繼續存在在這種情況下。
擴展性
kafka使用zookeeper來實現動態的集羣擴展，不需要更改客戶端（producer和consumer）的配置。broker會在zookeeper註冊並保持相關的元數據（topic，partition信息等）更新。而客戶端會在zookeeper上註冊相關的watcher。一旦zookeeper發生變化，客戶端能及時感知並作出相應調整。這樣就保證了添加或去除broker時，各broker間仍能自動實現負載均衡。
負載均衡
負載均衡可以分爲兩個部分：producer發消息的負載均衡和consumer讀消息的負載均衡。
producer有一個到當前所有broker的連接池，當一個消息需要發送時，需要決定發到哪個broker（即partition）。這是由partitioner實現的，partitioner是由應用程序實現的。應用程序可以實現任意的分區機制。要實現均衡的負載均衡同時考慮到消息順序的問題（只有一個partition/broker上的消息能保證按順序投遞），partitioner的實現並不容易。個人認爲這一點還有待改進。
consumer讀取消息時，除了考慮當前的broker情況外，還要考慮其他consumer的情況，才能決定從哪個partition讀取消息。具體的機制還不是很清楚，需要做更深入的研究。
性能
性能是kafka設計重點考慮的因素。使用多種方法來保證穩定的O(1)性能。
kafka使用磁盤文件保存收到的消息。它使用一種類似於WAL（write ahead log）的機制來實現對磁盤的順序讀寫，然後再定時的將消息批量寫入磁盤。消息的讀取基本也是順序的。這正符合MQ的順序讀取和追加寫特性。
另外，kafka通過批量消息傳輸來減少網絡傳輸，並使用java中的sendfile和0拷貝機制減少從讀取文件到發送消息間內存數據拷貝和內核用戶態切換的次數。
根據kafka的性能測試報告(https://cwiki.apache.org/confluence/display/KAFKA/Performance+testing)，它的性能基本達到了O(1)的複雜度。
一些特點：
- 消息持久化及其緩存更多的依賴文件系統，而不是內存。通過巧妙的順序讀寫設計，與內存讀寫相比，依然很強悍。
- 消息持久化操作的複雜度幾乎都是O(1) 。消息系統元數據的持久化數據結構往往採用BTree，通過特別的設計實現。
- 效率最大化。通過調用linux的sendfile系統實現，將數據從文件傳輸到socket的數據路徑從傳統的4步減少到2步。
- 端到端的批量壓縮。多數情況下系統的瓶頸是網絡而不是CPU，支持GZIP和Snappy壓縮協議。
- 客戶端維護消息狀態，而不是broker維護狀態。一是，提高消息狀態的準確性，二是，將管理成本放到客戶端提高borker的性能。
- 消息傳遞語義。提供幾種消息傳遞保障，滿足不通業務場景。如最少發送一次，最多發送一次，只發送一次。
- 生產者和消費者自動負載均衡。Kafka支持客戶端負載均衡，也可以使用一個專用的負載均衡器對TCP連接進行負載均衡調整。
- 異步發送。將消息預先存儲到內存中，當達到某個閥值的時候，將消息批量發到broker，提高網絡利用率。
- 語義分區。可以按照消息中某個鍵值進行分區，將不同的分區發給各自相應的代理(broker)。默認是隨機分區。
- 對Hadoop以及其它批量數據裝載的支持。能夠週期性將快照數據載入進行批量處理的離線系統，如數據倉庫和hadoop集羣。
總結
Kafk和其它絕大多數消息系統的區別，是有下面這幾個比較重要的設計決策：
- Kafka在設計之時爲就將持久化消息作爲通常的使用情況進行了考慮。
- 主要的設計約束是吞吐量而不是功能。
- 有關哪些數據已經被使用了的狀態信息保存爲數據使用者（consumer）的一部分，而不是保存在服務器之上。
- Kafka是一種顯式的分佈式系統。它假設，數據生產者（producer）、代理（brokers）和數據使用者（consumer）分散於多臺機器之上。
附：Kafka在LinkedIn中的應用：
在LinkedIn中部署後的各系統形成的拓撲結構
下面的示意圖所示是在LinkedIn中部署後各系統形成的拓撲結構。
要注意的是，一個單個的Kafka集羣系統用於處理來自各種不同來源的所有活動數據。它同時爲在線和離線的數據使用者提供了一個單個的數據管道，在線活動和異步處理之間形成了一個緩衝區層。我們還使用kafka，把所有數據複製（replicate）到另外一個不同的數據中心去做離線處理。
我們並不想讓一個單個的Kafka集羣系統跨越多個數據中心，而是想讓Kafka支持多數據中心的數據流拓撲結構。這是通過在集羣之間進行鏡像或“同步”實現的。這個功能非常簡單，鏡像集羣只是作爲源集羣的數據使用者的角色運行。這意味着，一個單個的集羣就能夠將來自多個數據中心的數據集中到一個位置。下面所示是可用於支持批量裝載（batch loads）的多數據中心拓撲結構的一個例子：
請注意，在圖中上面部分的兩個集羣之間不存在通信連接，兩者可能大小不同，具有不同數量的節點。下面部分中的這個單個的集羣可以鏡像任意數量的源集羣。要了解鏡像功能使用方面的更多細節。
原創文章，歡迎轉載，轉載請標明出處 http://write.blog.csdn.net/postedit/40818711