分佈式消息系統研究報告之Kafka

最近在看消息系統方面的東西。做爲一個實踐主義者，在看消息系統的各類實現時，不妨先粗略思考一下如何設計一個消息系統。我總覺出來有這麼幾個點(比較粗陋，之後繼續補充)：

1. 隊列的存儲和管理

   用什麼方式存儲消息決定了這個消息系統的最終表現。

2. push仍是pull

   producer沒啥好說的，確定是push，這裏主要說consumer，pull的好處是能夠根據consumer消費能力來處理消息，而push的好處則是實時性

3. 服務橫向擴展

   是否存在單點？如何進行橫向擴展的？failover如何作？

4. 保證一次消費

   消息不丟失；不會重複消費。

5. topic模式

   是否支持單條message多個comsumer同時消費？用什麼機制保證其工做？

6. 監控

   有沒有監控手段？

好了，如今先來看Kafka。Kafka是LinkedIn的一個消息系統。主要用來處理日誌並進行實時分析。 Kafka有一篇翻譯好的文章http://www.oschina.net/translate/kafka-design。

Kafka要解決的是大吞吐量下的消息隊列問題。

1. 隊列過長時，不少消息系統都不給力 Kafka使用文件系統來進行存儲，基本沒有什麼限制。文件都是馬上flush。
2. 將消息打包成MessageSet，自己是Buffer的思想，例如nagle算法
3. 消息壓縮 支持GZIP
4. 將消息強制排序，並用「最高水位標記」（high water mark）"來記錄消費者狀態
5. 用groupId+atomicInteger代替guid來標識每一條消息，減小複雜性

一些與結構無關的notes:

1. Java實用sendfile FileChannel.transferTo

2. flush與分頁緩存的關係

實際中這麼作意味着，數據被傳輸到OS內核的頁面緩存中了，OS隨後會將這些數據刷新到磁盤的。 這段話的思路能夠考慮一下。

3. 問題4的科學稱呼：消息傳遞語義（Message delivery semantics）

   系統能夠提供的幾種可能的消息傳遞保障以下所示:

   1. 最多一次—這種用於處理前段文字所述的第一種狀況。消息在發出後當即標示爲已使用，所以消息不會被髮出去兩次，但這在許多故障中都會致使消息丟失。

   2. 至少一次—這種用於處理前文所述的第二種狀況，系統保證每條消息至少會發送一次，但在有故障的狀況下可能會致使重複發送。

   3. 僅僅一次—這種是人們實際想要的，每條消息只會並且僅會發送一次。

   這個問題已獲得普遍的研究，屬於「事務提交」問題的一個變種。提供僅僅一次語義的算法已經有了，兩階段或者三階段提交法以及Paxos算法的一些變種就是其中的一些例子，但它們都有與生俱來的的缺陷。這些算法每每須要多個網絡往返（round trip），可能也沒法很好的保證其活性（liveness）（它們可能會致使無限期停機）。FLP結果給出了這些算法的一些基本的侷限。