寫在前面

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

[[206398]]

什么是日志

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

日志一般具有三個(gè)特性：

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

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

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

來個(gè)假如

假如我們要設(shè)計(jì)一個(gè)分布式日志存儲(chǔ)系統(tǒng)，你會(huì)怎么設(shè)計(jì)?

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

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

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

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

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

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

Scribe最重要的特點(diǎn)是容錯(cuò)性好。當(dāng)后端的存儲(chǔ)系統(tǒng)奔潰時(shí)，Scribe會(huì)將數(shù)據(jù)寫到本地磁盤上，當(dāng)存儲(chǔ)系統(tǒng)恢復(fù)正常后，Scribe將日志重新加載到存儲(chǔ)系統(tǒng)中。

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

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