Kafka學習筆記02 - 適用場景

不要求消息準確性很高，可是消息的吞吐量大

因爲Kafka能夠處理高吞吐量的消息，因此很是適合處理系統點擊日誌收集。即便是有的消息被消費了一次以上，但並不影響統計結果的精確性。

並且系統點擊日誌通常都量很大，放到單一的硬盤中很容易把硬盤撐爆。而Kafka的分佈式存儲系統，能夠自動的實現消息分片和服務器擴容的功能，適合收集日誌。

不少實時分析系統，都是經過Kafka + Storm進行日誌收集和計算分析的。

業務代碼實現冪等性，且消費者速度與生產者基本匹配

若是業務代碼已經實現了冪等性，那麼能夠經過Kafka大幅提高業務系統的性能。實現冪等性有兩種方式，一種是屢次調用方法都會返回一樣的結果，而不是累加的結果；另外一種是在消費者端增長一個緩存，緩存中存儲已經消費消息的主鍵，一旦緩存中存在這個主鍵，則再也不重複消費。

另外一個須要注意的問題就是消費者的速度不能和生產者差異太大，若是消費者速度遠遠小於生產者速度，致使時間差大於消息保存的時間，則會致使消息還將來得及消費就被刪除。好比大於7天的消息就會刪除，可是消費者還將來得及消費7天以前的消息，那麼消息將丟失。遇到這種狀況能夠增長消息中介的分區和消費者實例，並行消費。可是若是瓶頸在數據庫等其餘資源，那麼這種場景就不適合使用Kafka。

若是想使用Kafka處理僅僅發送一次的消息

因爲Kafka的性能超過了傳統的消息中間件不少，因此使用Kafka帶來的優點很明顯。

若是也想使用Kafka處理僅僅發送一次的消息，好比，業務端程序並無實現冪等性。使用這種消息消費模型，須要以犧牲性能做爲代價，可是因爲其天生支持高可用和消息分片，則仍然比ActiveMQ這種消息中間件更好用。

首先須要每次存儲消息都刷入磁盤。Kafka爲了提高性能，通常是先將消息放入內存，等到必定數據或時間，才寫入磁盤。設置爲每寫入一次消息，就刷一次盤。

開啓事務永遠是最保險的回滾數據的方式，若是將消息消費的偏移量放在Zookeeper或者消費者的客戶端，是不能保證偏移量和業務數據在一個事務中一塊兒回滾的。因此這裏須要修改Kafka的程序，將消息的偏移量存入業務數據的數據庫。若是是一個庫，只要開啓事務就能夠，若是是在不一樣的庫，則須要分佈式事務。

在Kafka公佈的0.9的新版本中提供了將偏移量存入本身定製的數據庫中。預計在2014年12月發佈。

Kafka的不適用場景，不支持消息失敗的自動重試

ActiveMQ等JMS消息中間件，是支持消息失敗重試的，自動重試n次在將消息放入死消息隊列，供人工審查。不會由於某個消息有問題，影響後面的消息消費。可是Kafka這點要很是當心，若是採用將偏移量存入數據庫，和業務數據一個事務，那麼一旦某個消息有問題，須要完善的判斷機制來判斷消息是否已經消費，不然可能出現因爲某一個消息消費不了而致使後面的消息都不能消費的狀況。