1:kafka和flume都是日誌系統，kafka是分布式訊息中介軟體，自帶儲存，提供push和pull訪問資料功能。flume分為agent（資料採集器）,collector（資料簡單處理和寫入）,storage（儲存器）三部分，每一部分都是可以定製的。比如agent採用rpc（thrift-rpc）、text（檔案）等，storage指定用hdfs做。
2:kafka做日誌快取應該是更為合適的，但是 flume的資料採集部分做的很好，可以定製很多資料來源，減少開發量。所以比較流行flume+kafka模式，如果為了利用flume寫hdfs的能力，也可以採用kafka+flume的方式。
採集層 主要可以使用flume, kafka兩種技術。
flume：flume 是管道流方式，提供了很多的預設實現，讓使用者通過引數部署，及擴充套件api.
kafka：kafka是乙個可持久化的分布式的訊息佇列。
kafka 是乙個非常通用的系統。你可以有許多生產者和很多的消費者共享多個主題topics。相比之下,flume是乙個專用工具被設計為旨在往hdfs,hbase傳送資料。它對hdfs有特殊的優化，並且整合了hadoop的安全特性。所以，cloudera 建議如果資料被多個系統消費的話，使用kafka；如果資料被設計給hadoop使用，使用flume。
正如你們所知flume內建很多的source和sink元件。然而，kafka明顯有乙個更小的生產消費者生態系統，並且kafka的社群支援不好。希望將來這種情況會得到改善，但是目前：使用kafka意味著你準備好了編寫你自己的生產者和消費者**。如果已經存在的flume sources和sinks滿足你的需求，並且你更喜歡不需要任何開發的系統，請使用flume。
flume可以使用***實時處理資料。這些對資料遮蔽或者過量是很有用的。kafka需要外部的流處理系統才能做到。
kafka和flume都是可靠的系統,通過適當的配置能保證零資料丟失。然而，flume不支援副本事件。於是，如果flume**的乙個節點崩潰了，即使使用了可靠的檔案管道方式，你也將丟失這些事件直到你恢復這些磁碟。如果你需要乙個高可靠行的管道，那麼使用kafka是個更好的選擇
flume和kafka可以很好地結合起來使用。如果你的設計需要從kafka到hadoop的流資料，使用flume**並配置kafka的source讀取資料也是可行的：你沒有必要實現自己的消費者。你可以直接利用flume與hdfs及hbase的結合的所有好處。你可以使用cloudera manager對消費者的監控，並且你甚至可以新增***進行一些流處理。
flume和kafka可以結合起來使用。通常會使用flume + kafka的方式。其實如果為了利用flume已有的寫hdfs功能，也可以使用kafka + flume的方式。
Kafka與flume的整合
為我們的source channel sink起名 a1.sources r1 a1.channels c1 a1.sinks k1 指定我們的source收集到的資料傳送到哪個管道 a1.sources r1.channels c1 指定我們的source資料收集策略 a1.sources r1....
v if與v show二者效能比較
先來說說v if v if 根據表示式的值在dom中生成或者移除乙個元素，值是false就會在dom中刪除，反之會轉殖相應元素到dom中 支援加在標籤上 再說說v show v show是根據表示式的值來顯示或者隱藏元素，根據的是display的值 不支援加在標籤上 劃重點 在切換v if的時候，v...
程序 執行緒及二者區別與聯絡
概念 程序是作業系統資源分配和管理的基本單位，而執行緒是處理器任務排程和執行的基本單位 乙個程序裡有乙個或多個執行緒，執行緒也被稱為輕量級程序。區別與聯絡 程序執行緒 位址空間與資源 獨立的同一程序的執行緒共享本程序的位址空間和資源 多程序與多執行緒 乙個程序崩潰之後，在保護模式下不會對其他程序產生...