分布式日志存儲系統(tǒng)-LogDevice

作者：周明耀 2017-10-16 10:24:47

存儲

存儲軟件

分布式 做過分布式系統(tǒng)的人都知道，想要在大規(guī)模集群下處理高并發(fā)事務時同時滿足CAP(一致性、可用性、分區(qū)容錯)，從理論上來說不可能，當然聽說最近谷歌已經實現(xiàn)了這樣的分布式系統(tǒng)，但是總的來說確實非常難。

 寫在前面

做過分布式系統(tǒng)的人都知道，想要在大規(guī)模集群下處理高并發(fā)事務時同時滿足CAP(一致性、可用性、分區(qū)容錯)，從理論上來說不可能，當然聽說最近谷歌已經實現(xiàn)了這樣的分布式系統(tǒng)，但是總的來說確實非常難。對于社交媒體的海量日志文件，如果我們也提出了需要確保高可用、持續(xù)寫入數(shù)據、按照記錄順序返回數(shù)據等三條要求，你覺得是否可以實現(xiàn)?FaceBook的LogDevice實現(xiàn)了。

[[206398]]

什么是日志

日志是記錄一系列序列化的系統(tǒng)行為的信息，我們需要確保它們能夠被保存在可靠的地方。對于應用程序來說，日志的作用一般有兩個，即Troubleshooting和顯示程序運行狀態(tài)。好的日志記錄方式可以提供我們足夠多定位問題的依據。對于一些復雜系統(tǒng)，例如數(shù)據庫，日志可以承擔數(shù)據備份、同步作用，很多分布式數(shù)據庫都采用“write-ahead”方案，在節(jié)點數(shù)據同步時通過日志文件恢復數(shù)據。

日志一般具有三個特性：

1、面向記錄：寫入日志的一定是孤立的行，而不是一個字節(jié)。日志實質上是問題的最小單元，用戶也一定是讀取整行日志。日志的存儲原則上按照順序，即按照LSN(日志順序數(shù)字)存放，但是也不完全這么要求，所以日志系統(tǒng)可以優(yōu)先高寫入需求，對寫入失敗容錯。

2、日志天生就是遞增的：也就是說，日志是不會修改的，那么也就意味著，日志系統(tǒng)的設計應該是以高寫入、高讀取為目標，不需要擔心更新操作的數(shù)據一致性問題。

3、日志存儲周期長：可能是一天，也可能是一個月，甚至于一年。這也就意味著，日志的刪除規(guī)則一般都是按照時間或者空間進行設定的，具有固定的規(guī)則。

來個假如

假如我們要設計一個分布式日志存儲系統(tǒng)，你會怎么設計?

日志信息需要傳輸、存儲，為了實現(xiàn)穩(wěn)定的數(shù)據交換，我們可以采用Kafka作為消息中間件。

Kafka實際上是一個消息發(fā)布訂閱系統(tǒng)。

Producer向某個Topic發(fā)布消息，而Consumer訂閱某個Topic的消息，進而一旦有新的關于某個Topic的消息，Broker會傳遞給訂閱它的所有Consumer。在Kafka中，消息是按Topic組織的，而每個Topic又會分為多個Partition，這樣便于管理數(shù)據和進行負載均衡。同時，它也使用了Zookeeper進行負載均衡。

Kafka在磁盤上的存取代價為O(1)，即便是普通服務器，每秒也能處理幾十萬條消息，并且它本身就是分布式架構，也支持將數(shù)據并行加載到Hadoop。

上面這張圖是一個典型的采用消息中間件進行日志數(shù)據交換的系統(tǒng)設計架構，但是沒有實現(xiàn)數(shù)據存儲，也沒有描述數(shù)據是如何被抽取并發(fā)送到Kafka的。

如果想要實現(xiàn)數(shù)據存儲，并描述清楚內部處理流程，我們可以采用怎么樣的日志處理系統(tǒng)架構呢?這里推薦你FaceBook的Scribe，它是一款開源的日志收集系統(tǒng)，在Facebook內部已經得到大量的應用。它能夠從各種日志源上收集日志，存儲到一個中央存儲系統(tǒng) (可以是NFS，分布式文件系統(tǒng)等)上，以便于進行集中統(tǒng)計分析處理。

Scribe最重要的特點是容錯性好。當后端的存儲系統(tǒng)奔潰時，Scribe會將數(shù)據寫到本地磁盤上，當存儲系統(tǒng)恢復正常后，Scribe將日志重新加載到存儲系統(tǒng)中。

Scribe的架構比較簡單，主要包括三部分，分別為Scribe Agent， Scribe和存儲系統(tǒng)。Scribe Agent實際上是一個Thrift Client。Scribe接收到Thrift Client發(fā)送過來的數(shù)據，根據配置文件，將不同topic的數(shù)據發(fā)送給不同的對象。存儲系統(tǒng)實際上就是Scribe中的Store，當前Scribe支持非常多的Store。

貌似市面上已經有很多分布式日志收集系統(tǒng)了，為什么FaceBook還需要推出LogDevice呢?而且FaceBook自己已經有了Scribe，為什么還要繼續(xù)設計LogDevice?因為Scribe更多實現(xiàn)了日志數(shù)據的收集，它不是一個完整的日志處理、存儲、讀取服務，系統(tǒng)設計也較為死板，存儲更多依賴HDFS，使用過程中一定出現(xiàn)了不能滿足自身需求的情況。而對于開源的哪些分布式日志收集系統(tǒng)，更多的是集成各個開源組件，共同完成日志存儲系統(tǒng)設計需求。對于FaceBook的工程師來說，他們一貫秉承著用于創(chuàng)新的精神，想想Apache Cassandra，其實當時已經有HBase等成熟的NoSQL數(shù)據庫，但是由于存在中心節(jié)點等諸多設計上的限制，F(xiàn)aceBook自己搞了一個全新的無中心化設計的架構，即便在初期飽受質疑，后續(xù)也在不斷地改進，到目前為止，Cassandra真正進入到了它的黃金時代。

新聞名稱：分布式日志存儲系統(tǒng)-LogDevice
地址分享：http://m.5511xx.com/article/dpodgii.html