首先Flume和Kafka都是消息系統，但是它倆也有着很多不同的地方，Flume更趨向於消息采集系統，而Kafka更趨向於消息緩存系統。
【一】設計上的不同
Flume是消息采集系統，它主要解決問題是消息的多元采集。因此Flume在實現上提供了多達十幾種的Flume Source，以供用戶根據不同的應用場景來采集數據。也正因為Flume提供了這些采集消息的Flume Source，使得用戶采集消息變得很簡單，用戶往往只需要對原始數據稍作處理然后將數據發送給Flume Source。在Flume的Thrift Source中，Flume已經實現了Thrift Source服務器端，用戶只需要編寫客戶端將數據發送給Flume。
Kafka是消息緩存系統，主要是用來緩存數據，緩存時間可以由配置文件設定，在緩存時間內，緩存的數據不論是否被消費，都不會刪除，超過緩存時間Kafka才會把數據刪除以釋放空間。這一點與Flume不同，Flume的數據一旦確認被Sink接收就會被刪除。
【二】數據處理上的不同
Flume接收到數據就會主動把數據推送(push)到Sink，Sink確認收到后會將數據從Channel中刪除，因此Flume主要是快速的采集數據，數據對它來說只是過客，Flume注重的是speed。
Kafka收到數據后會先把數據緩存起來，無論下游有沒有人消費數據，數據暫時緩存在服務器集群中，注重的是store。
【三】push vs pull
Flume是實實在在包含Source、Channel、Sink三個組件，Source用來接收數據，Channel用來緩存數據，Sink用來發送數據，而且是主動push給下游，這就導致下游接收方只能是一個，因為如果下游有多個接收者，接收的速率不同就會導致接收速度低的接收者接收不到數據的情況(Channel會在Sink確認后刪除數據)。如果想把數據發送給多個接收者，那就只能讓Source把數據寫到多個Channel，再由Channel經各自的Sink發送給不同的接收者。
Kafka其實只包含有broker cluster，用來緩存數據，他的Producer和Consumer都需要用戶自己實現；broker cluster更像是一個提供存儲數據功能的文件系統，用戶自己實現往里面讀寫數據，broker cluster不需要關心用戶怎么實現的，因此Kafka對Producer和Consumer的依賴非常小，專心做緩存。當Consumer需要訂閱某個topic的數據時候，Consumer主動去取數據，broker cluster被動的提供數據，這樣就可以同時支持多個Consumer訂閱數據。
【四】Kafka的主題和划分以及復制因子
Kafka在接收數據的時候，Producer可以指定一個主題，Kafka按照主題來分類數據，Consumer訂閱數據的時就可以按需訂閱某一類數據。
Kafka的划分是在主題上的進一步細分，例如可以把web應用中不用用戶的數據按照不同的划分來分別存儲，同一個划分內的數據存儲的時候擁有唯一的連續遞增的編號，這個編號又稱作偏移量，偏移量在Consumer中保存，用來依次讀取數據，當然也可改變編號重復讀取或者跳讀。
復制因子是Kafka集群提高容錯性的一個措施，一個划分內的數據會根據復制因子個數把數據復制到不同broker上，本broker負責將該划分內的數據讀寫請求，稱為主節點，其他從節點負責跟進復制數據。主題的復制因子定為多少個應該根據自己的broker cluster機器個數合理確定。
Kafka能夠保證一個划分內的數據在被Consumer消費的時候是有序的，而不能保證不同划分內的數據是有序的，因此如果想所有數據有序那就只能有一個划分。
轉載請注明原文出處 http://www.cnblogs.com/vincent-vg/p/5826786.html，謝謝