大型互聯網技術架構4－分布式存儲-II Google

The largest single database on earth - Google Spanner.

我們繼續互聯網技術架構－散布式存儲。

上文大篇幅介紹了1些散布式存儲的理論，偏重理論。可別小視這些理論，Google的各個神器都是建立在這些理論之上，乃至全部Apache的大數據3劍客項目都是沾恩于這些理論。難怪@Tiger大牛講Google靠的是1大批世界頂尖數據，物理，計算領域的Ph.D.，這些大神和他們的Paper是Google為何是Google的緣由，和Google沒有開源為何仍然強大的緣由，其背后有著強大的基礎研究團隊。

總目錄

散布式存儲概述

散布式存儲特性 － 哈希散布/1致性哈希散布

散布式存儲協議 － 兩階段與Paxos

散布式文件系統 － Google GFS

散布式鍵值系統－ Alibaba Tair

散布式表格系統－ Google BigTable /Megastore

散布式數據庫系統－MySQL Sharding, Google Spanner / F1

1. 散布式文件系統

GFS Google文件系統

提到散布式文件系統，固然首推GFS了。GFS是Google散布式存儲的基石，所有的神器都是建立在散布式存儲之上的，如Google BigTable, Google Megastore, Google Percolator, MapReduce等。

GFS

GFS系統節點可以分為3種角色：GFS Master, GFS ChunkServer, GFS Client.

GFS文件被劃分固定大小的數據庫，稱為Chunk, 由Master分配1個64位全局唯1ID; ChunkServer(CS)以普通Linux文件情勢將chunk存儲在磁盤，為了HA, Chunk被replication，默許3份。

客戶端訪問GFS時，首先訪問Master，獲得CS信息，以后再去訪問CS，完成數據存取。GFS目前主要用于MapReduce, Bigtable.

租約機制(Lease)

GFS追加的記錄大小從即是KB到幾10MB不等，為了不Master變成系統瓶頸，GFS引入了租約機制，行將Chunk的寫操作授權給ChunkServer。具有租約授權的CS稱為主ChunkServer。在租約有效期內，如60秒，對該chunk的寫操作都由主CS負責。主CS也能夠在租約到期后，不斷向Master提出續約直到Chunk寫滿。

1致性模型

GFS支持1個寬松的1致性模型，GFS從相對需求和簡單化層名斟酌，設計成主要是為了追加append而不是為了改寫override的架構，如我們了解的

HBase。

看1下記錄追加的流程：

1）客戶端向Master要求chunk每一個副本所在CS

2）Master返回客戶端主副本和備副本所在CS位置

3）客戶端將追加記錄發送給每個副本，CS會內部LRU結構緩存這些數據

4）當所有副本都確認收到數據，客戶端接著發起1個要求控制命令給主副本

5）主副本把寫要求提交給所有副本。

6）備副本成功完成后應對主副本。

7）主副本響應客戶端。

其中，分為控制流與數據流。

容錯

1）Master容錯：

與傳統類似，通過操作日志加checkpoint來進行。

2）CS容錯：

采取復制多個副本方式。

從GFS的架構可以看出，GFS是1個具有良好可擴大能力并可以自動處理各種異常的系統。Google的系統已開始就斟酌了如河水平擴大，所以后續的系統能夠站在偉人的肩膀上，如Bigtable建構在GFS之上，Megastore, Spanner又在

Biigtable之上融會了關系型數據庫的功能，全部方案華麗，完善。

另外，Google的成功經驗反過來證明了單Master是可行的，簡化了系統同時實現了1致性。

2. 散布式鍵值系統

散布式鍵值類似于散布式表格模型Bigtable的1種特例。比較著名的有Amazon Dynamo, Memcache和國內阿里的Tair系統。

前兩天有火伴提到Tair, 那我們就以Tail來聊聊吧。

Tair散布式系統

Tair是阿里/淘寶開發的1個散布式鍵/值存儲系統，tair分為持久化和非持久化兩種方式。非持久化的tair可以看做1個散布式緩存，持久化的tair將數據寄存置磁盤，固然tair可以自動備份以免磁盤破壞等問題。

系統架構：

一樣，Tair由1個Master和1系列Slave節點組成，稱之為Config Server作為整體的控制中心，而服務節點為可伸縮的Data Server。Config Server負責管理所有的data server， 保護其狀態信息。Data Server則對外提供各種數據服務，并以心跳來將本身信息反饋給config server。可以看到，Config Server是核心控制點，而且是單點，只有主－備情勢保證其可靠性。

ConfigServer的功能

1) 通過保護和dataserver心跳獲知集群中存活節點信息

2) 根據存活節點的信息來構建數據在集群中的散布表。

3) 提供數據散布表的查詢服務。

4) 調度dataserver之間的數據遷移、復制。

另外ConfigServer實現了從配置文件load進節點信息，然后根據配置的數據散布的桶和需要建立的數據備份數，建立數據散布表，長度為桶數乘以備份數。如目前有1023個桶，備份3，所以長度為1023*3的數組。數組元素就是數據要存儲的主節點信息，下標即桶號碼。其中后面的1023*2為備份節點信息。為了負載均衡，主桶會盡可能均勻散布到所有節點，備桶則根據策略，如不同數據中心來散布。

DataServer的功能

1) 提供存儲引擎

2) 接受client的put/get/remove等操作

3) 履行數據遷移，復制等

4) 插件：在接受要求的時候處理1些自定義功能

5) 訪問統計

操作層面：

客戶端首先要求Config Server獲得數據所在Data Server， 以后向Data Server發送讀寫要求。

負載均衡：

Tair采取散布式1致性哈希算法，可參考我們上1篇介紹，正所謂理論之基石。tair對所有的key，分配到Q個桶，桶是負載均衡和數據遷移的基本單位。config server根據已定策略把每一個桶指派到不同的data server，由于數據依照key做hash算法，所以每一個桶中的數據基本平衡。

以下圖：

1致性和可靠性：

散布式系統中的可靠性和1致性是沒法同時保證的,由于有網絡毛病. tair采取復制技術來提高可靠性,并做了1些優化,當無網絡毛病的時候, tair提供的是1種強1致性.但是在有data server產生故障的時候,客戶有可能在1定時間窗口內讀不到最新的數據.乃至產生最新數據丟失的情況.

參考：http://tair.taobao.org/

3. 散布式表格系統

顧名思義，表格模型，多行多列，通過主鍵唯1標識。如始祖Google Bigtable

Google Bigtable:

基于GFS與Chubby的散布式表格系統，目標是解決讀取速度，許多Google數據如web索引，衛星圖象數據都寄存在bigtabe。

整體結構：

(row:string, column:string, timestamp:int64) -> string

RowKey為任意字符串，長度小于64kb。全部數據依照主鍵進行排序，字典排序，如果域名的話通常使用反向變換來排序，這樣可以做到2級，子域名可以連續。

系統架構：

Bigtable

整體分為客戶端，主控服務器和子表服務器Tablet Server。 Bigtable把大表分割為100⑵00m的子表tablet。

Master:

管理所有子表tablet server，暴扣分配子表給子表服務器，子表合并，和接受子表分裂消息，監控子表服務器，和在子表實現負載均衡與故障恢復。

Tablet Server:

子表服務器，實現子表的裝載／卸載，和表格內容的讀寫，合并，分裂。其服務的數據包括操作日志及子表sstable數據，而數據保存于底層GFS中。

Chubby:

Google的散布式服務，zk的鼻祖。底層核心算法就是我們上文提及的Paxos,即多數派達成1致，類似昨天的英國公投脫歐。Chubby作為全部bigtable的核心，如果產生故障，則全部bigtabe不可用。Chubby為了保持HA, 通常大型部署結構為兩地3數據中心5副本。

為何需要5個副本？

理論上3個數據中心就已很高可用了,為何要選擇5個呢?假設只部署在3個數據中心,1個掛了后剩余兩個必須不能掛,由于commit成功在Paxos協議里需要最少2節點;但如果第2個節點又掛了此時就真的沒法訪問了,為了高可用,所以選擇了5個數據中心節點.

Chubby在Bigtable中提供了／輔助了以下核心功能：

1）選取并保證同1時間有且只有1個主控服務器master

2）保存bigtable系統引導信息

3）配合master發現子表服務器加載與卸載

4）獲得bigtable的schema信息和訪問控制信息

Bigtable

分為用戶表（User Table）, 元數據表（Meta Table）和根表（Root Table）。客戶段查詢時，首先訪問Chubby讀取根表位置，再從根表讀取所需元數據子表的位置。

復制與1致性：

Bigtable采取強1致性，同1時刻同1個子表只能被1臺tablet server服務，master需要來控制這類1致性，而這也是通過Chubby的散布式互斥鎖機制來保證的。

GFS + Bigtable兩層架構以1種優雅的方式統籌系統的強1致和HA。底層的GFS是弱1致性，可用性和性能很好，但是多客戶追加可能會出現重復記錄等數據不1致問題；上層的Bigtable通過量級散布式索引使得系統對外表現為強1致。Bigtable最大優勢在于線性擴大，單機出現故障，可以將服務（1分鐘內）自動遷移到全部集群。

Google Megastore:

Megastore在Bigtable的基礎上，提供了數據庫功能的支持，介于關系型數據庫與NoSQL之間的存儲。Google在其公然的Megastore論文中指出，傳統的關系型數據庫在Google已被否定，如MySQL。昂貴的商業數據庫會大幅加大用戶在云中大幅部署的總本錢。

Megastore設計原理與精華在于，能夠在廣域網中同步復制文件寫操作，可接受的延時，支持數據中心的故障遷移。論文還透漏，目前Google和有100多個生產利用Megastore作為存儲服務，其可靠度在99.99%⑴00%，并且平均讀取延遲小于萬分之1毫秒，寫入延遲100⑷00毫秒。

系統架構以下：

客戶端庫Megastore Library:

提供利用程序的接口，包括映照megastore操作到bigtable，事務及并發控制，基于Paxos的復制，將要求分發給復制服務器，通過調和者快速讀寫。

復制服務器Replication:

接受客戶真個用戶要求并轉發到所在機房的bigtable實例解決跨機房連接數過量的問題。

調和者Coord.

存儲每一個機房本地的實體組是不是處于最新狀態信息，實現快速讀寫。

Megastore主要功能分為：映照Megastore到Bigtable; 事務并發控制；跨機房數據復制與讀寫優化。

操作流程：

首先解析用戶的SQL，接著根據用戶定義的Megastore數據模型將sSQL轉換為底層對應的Bigtable。

數據復制Replication：

數據拆分成不同的實體組，每一個實體組內的操作日志采取基于Paxos的方式同步到多個機房保持強1致性。實體組之間通過散布式隊列或兩階段提交協議實現散布式事務。

如上圖所示，Megastore的數據復制是通過paxos進行同步復制的，即如果更新1個數據，所有機房都會進行同步更新，由于使用了paxos協議，所以不同機房真對同1條數據的更新復制到所有機房的更新順序都是1致的；同步復制保證了數據的實時可見性，采取paxos算法則保證了所有機房的更新1致性。

Megastore主要創新：

1） 包括提出了實體組的數據模型，實體組內部保持了關系數據庫的ACID特性，實體組之間保持NoSQL弱1致性，創新的融會了SQL和NoSQL的優勢。另外實體組的定義規避了性能殺手Join。

2） 通過Paxos協議同時保證了高可靠與高可用，既可把數據強同步到多個機房，又做到產生故障時自動切換不影響讀寫服務。

散布式存儲系統有兩個目標：可擴大性 ＋ 全功能SQL在Megastore上基本實現了。固然，Megastore也有1些問題，其中1些來源于底層Bigtable，如單副本等等。實際上，在Google, Megastore已過時，并重新開發了1套革命性的散布式系統Spanner用于解決這些問題。

4. 散布式數據庫

關系型數據庫聚集了計算機領域的智慧，也為如今互聯網，大數據做好了鋪墊。在互聯網時期，如何水平擴大是傳統關系型數據的最大挑戰。

MySQL Sharding

通常水平擴大的做法是利用層依照規則將數據查分到多個分片，散布到多個數據庫節點，并引入1個中間層利用來屏蔽后段的拆分細節。

一樣，在MySQL Sharding中也是類似：

如上圖，整體分為：利用端，中間層dbproxy集群，數據庫組，元數據服務器等。

1）利用端／客戶端：通過MySQL與客戶端交互，支持JDBC，使得原有單機數據庫無縫對接。

2）中間層dbproxy:解析客戶SQL，并轉發到后端數據庫。解析MySQL協議，履行SQL路由，過濾，讀寫分離，結果歸并，排序和分組等。另外可以引入LVS（Linux Virtual Server）進行負載均衡。

3）數據庫組dbgroup：每一個dbgroup由n臺數據庫機器組成，1臺master，剩余為slave。master負責所有些事務及強1致讀，并復制到備機。

4）元數據服務器：保護dbgroup拆分規則并用于dbgroup選主。dbproxy通過元數據服務器拆分規則肯定SQL的履行計劃。另外采取zk來實現多個副本HA。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈