第一篇：Google Megastore分布式存儲(chǔ)技術(shù)全揭秘

Google Megastore分布式存儲(chǔ)技術(shù)全揭秘

導(dǎo)讀：本文根據(jù)Google最新Megastore論文翻譯而來，原作者為Google團(tuán)隊(duì)，團(tuán)隊(duì)人員包括：Jason Baker，Chris Bond，James C.Corbett，JJ Furman，Andrey Khorlin，James Larson，Jean-Michel Léon，Yawei Li，Alexander Lloyd，Vadim Yushprakh。翻譯者為國(guó)內(nèi)知名IT人士。

在上個(gè)月舉行的創(chuàng)新數(shù)據(jù)系統(tǒng)研討會(huì)上(CIDR)，Google公開了其Megastore分布式存儲(chǔ)技術(shù)的白皮書。

Megastore是谷歌一個(gè)內(nèi)部的存儲(chǔ)系統(tǒng)，它的底層數(shù)據(jù)存儲(chǔ)依賴Bigtable，也就是基于NoSql實(shí)現(xiàn)的，但是和傳統(tǒng)的NoSql不同的是，它實(shí)現(xiàn)了類似RDBMS的數(shù)據(jù)模型(便捷性)，同時(shí)提供數(shù)據(jù)的強(qiáng)一致性解決方案(同一個(gè)datacenter，基于MVCC的事務(wù)實(shí)現(xiàn))，并且將數(shù)據(jù)進(jìn)行細(xì)顆粒度的分區(qū)(這里的分區(qū)是指在同一個(gè)datacenter，所有datacenter都有相同的分區(qū)數(shù)據(jù))，然后將數(shù)據(jù)更新在機(jī)房間進(jìn)行同步復(fù)制(這個(gè)保證所有datacenter中的數(shù)據(jù)一致)。Megastore的數(shù)據(jù)復(fù)制是通過paxos進(jìn)行同步復(fù)制的，也就是如果更新一個(gè)數(shù)據(jù)，所有機(jī)房都會(huì)進(jìn)行同步更新，因?yàn)槭褂胮axos進(jìn)行復(fù)制，所以不同機(jī)房針對(duì)同一條數(shù)據(jù)的更新復(fù)制到所有機(jī)房的更新順序都是一致的，同步復(fù)制保證數(shù)據(jù)的實(shí)時(shí)可見性，采用paxos算法則保證了所有機(jī)房更新的一致性，所以個(gè)人認(rèn)為megastore的更新可能會(huì)比較慢，而所有讀都是實(shí)時(shí)讀(對(duì)于不同機(jī)房是一致的)，因?yàn)椴渴鹩卸鄠€(gè)機(jī)房，并且數(shù)據(jù)總是最新。

為了達(dá)到高可用性，megastore實(shí)現(xiàn)了一個(gè)同步的，容錯(cuò)的，適合長(zhǎng)距離連接的日志同步器 為了達(dá)到高可擴(kuò)展性，megastore將數(shù)據(jù)分區(qū)成一個(gè)個(gè)小的數(shù)據(jù)庫(kù)，每一個(gè)數(shù)據(jù)庫(kù)都有它們自己的日志，這些日志存儲(chǔ)在NoSql中 Megastore將數(shù)據(jù)分區(qū)為一個(gè)Entity Groups的集合，這里的Entity Groups相當(dāng)于一個(gè)按id切分的分庫(kù)，這個(gè)Entity Groups里面有多個(gè)Entity Group(相當(dāng)于分庫(kù)里面的表)，而一個(gè)Entity Group有多個(gè)Entity(相當(dāng)于表中的記錄)

在同一個(gè)Entity Group中(相當(dāng)于單庫(kù))的多個(gè)Entity的更新事務(wù)采用single-phase ACID事務(wù)，而跨Entity Group(相當(dāng)于跨庫(kù))的Entity更新事務(wù)采用two-phase ACID事務(wù)(2段提交)，但更多使用Megastore提供的高效異步消息實(shí)現(xiàn)。需要說明的一點(diǎn)是，這些事務(wù)都是在同一個(gè)機(jī)房的，機(jī)房之間的數(shù)據(jù)交互都是通過數(shù)據(jù)復(fù)制來實(shí)現(xiàn)的。

傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)使用join來滿足用戶的需求，對(duì)于Megastore來說，這種模型(也就是完全依賴join的模型)是不合適的。原因包括

1.高負(fù)載交互性型應(yīng)用能夠從可預(yù)期的性能提升得到的好處多于使用一種代價(jià)高昂的查詢語言所帶來的好處。2.Megastore目標(biāo)應(yīng)用是讀遠(yuǎn)遠(yuǎn)多于寫的，所以更好的方案是將讀操作所需要做的工作轉(zhuǎn)移到寫操作上面(比如通過具體值代替外鍵以消除join)3.因?yàn)閙egastore底層存儲(chǔ)是采用BigTable，而類似BigTable的key-value存儲(chǔ)對(duì)于存取級(jí)聯(lián)數(shù)據(jù)是直接的

所以基于以上幾個(gè)原因，Megastore設(shè)計(jì)了一種數(shù)據(jù)模型和模式語言來提供基于物理地點(diǎn)的細(xì)顆粒度控制，級(jí)聯(lián)布局，以及申明式的不正規(guī)數(shù)據(jù)存儲(chǔ)來幫助消除大部分joins。查詢時(shí)只要指定特定表和索引即可。

當(dāng)然可能有時(shí)候不得不使用到j(luò)oin，Megastore提供了一種合并連接算法實(shí)現(xiàn)，具體算法這里我還是沒弄清楚，原文是[the user provides multiple queries that return primary keys for the same table in the same order;we then return the intersection of keys for all the provided queries.] 使用Megastore的應(yīng)用通過并行查詢實(shí)現(xiàn)了outer joins。通常先進(jìn)行一個(gè)初始的查詢，然后利用這個(gè)查詢結(jié)果進(jìn)行并行索引查詢，這個(gè)過程我理解的是，初始查詢查出一條數(shù)據(jù)，就馬上根據(jù)這個(gè)結(jié)果進(jìn)行并行查詢，這個(gè)時(shí)候初始查詢繼續(xù)取出下一條數(shù)據(jù)，再根據(jù)這個(gè)結(jié)果并行查詢(可能前面那個(gè)外鍵查詢還在繼續(xù)，使用不同的線程)。這種方法在初始查詢數(shù)據(jù)量較小并且外鍵查詢使用并行方式的情況下，是一種有效的并且具有sql風(fēng)格的joins。Megastore的數(shù)據(jù)結(jié)構(gòu)介于傳統(tǒng)的RDBMS和NoSql之間的，前者主要體現(xiàn)在他的schema表示上，而后者體現(xiàn)在具體的數(shù)據(jù)存儲(chǔ)上(BigTable)。和RDBMS一樣，Megastore的數(shù)據(jù)模型是定義schema中并且是強(qiáng)類型的。每一個(gè)schema有一個(gè)表集合，每個(gè)表包含一個(gè)實(shí)體集合(相當(dāng)于record)，每個(gè)實(shí)體有一系列的屬性(相當(dāng)于列屬性)，屬性是命名的，并且指定類型，這些類型包括字符串，各種數(shù)字類型，或者google的protocol buffer。這些屬性可以被設(shè)置成必需的，可選的，或者可重復(fù)的(一個(gè)屬性上可以具有多個(gè)值)。一個(gè)或者多個(gè)屬性可以組成一個(gè)主鍵。

在上圖中，User和Photo共享了一個(gè)公共屬性u(píng)ser_id，IN TABLE User這個(gè)標(biāo)記直接將Photo和User這兩張表組織到了同一個(gè)BigTable中，并且鍵的順序(PRIMARY KEY(user_id,photo_id)？是這個(gè)還是schema中定義的順序？)保證Photo的實(shí)體存儲(chǔ)在對(duì)應(yīng)的User實(shí)體鄰接位置上。這個(gè)機(jī)制可以遞歸的應(yīng)用，加速任意深度的join查詢速度。這樣，用戶能夠通過操作鍵的順序強(qiáng)行改變數(shù)據(jù)級(jí)聯(lián)的布局。其他標(biāo)簽請(qǐng)參考原文。Megastore支持事務(wù)和并發(fā)控制。一個(gè)事務(wù)寫操作會(huì)首先寫入對(duì)應(yīng)Entity Group的日志中，然后才會(huì)更新具體數(shù)據(jù)。BigTable具有一項(xiàng)在相同row/column中存儲(chǔ)多個(gè)版本帶有不同時(shí)間戳的數(shù)據(jù)。正是因?yàn)橛羞@個(gè)特性，Megastore實(shí)現(xiàn)了多版本并發(fā)控制(MVCC，這個(gè)包括oracle，innodb都是使用這種方式實(shí)現(xiàn)ACID，當(dāng)然具體方式會(huì)有所不同)：當(dāng)一個(gè)事務(wù)的多個(gè)更新實(shí)施時(shí)，寫入的值會(huì)帶有這個(gè)事務(wù)的時(shí)間戳。讀操作會(huì)使用最后一個(gè)完全生效事務(wù)的時(shí)間戳以避免看到不完整的數(shù)據(jù).讀寫操作不相互阻塞，并且讀操作在寫事務(wù)進(jìn)行中會(huì)被隔離(？)。

Megastore 提供了current，snapshot，和inconsistent讀，current和snapshot級(jí)別通常是讀取單個(gè)entity group。當(dāng)開始一個(gè)current讀操作時(shí)，事務(wù)系統(tǒng)會(huì)首先確認(rèn)所有之前提交的寫已經(jīng)生效了；然后系統(tǒng)從最后一個(gè)成功提交的事務(wù)時(shí)間戳位置讀取數(shù)據(jù)。對(duì)于snapshot讀取，系統(tǒng)拿到己經(jīng)知道的完整提交的事務(wù)時(shí)間戳并且從那個(gè)位置直接讀取數(shù)據(jù)，和current讀取不同的是，這個(gè)時(shí)候可能提交的事務(wù)更新數(shù)據(jù)還沒有完全生效(提交和生效是不同的)。Megastore提供的第三種讀就是inconsistent讀，這種讀無視日志狀態(tài)并且直接讀取最后一個(gè)值。這種方式的讀對(duì)于那些對(duì)減少延遲有強(qiáng)烈需求，并且能夠容忍數(shù)據(jù)過期或者不完整的讀操作是非常有用的。

一個(gè)寫事務(wù)通常開始于一個(gè)current讀操作以便確定下一個(gè)可用的日志位置。提交操作將數(shù)據(jù)變更聚集到日志，并且分配一個(gè)比之前任何一個(gè)都高的時(shí)間戳，并且使用Paxos將這個(gè)log entry加入到日志中。這個(gè)協(xié)議使用了樂觀并發(fā)：即使有可能有多個(gè)寫操作同時(shí)試圖寫同一個(gè)日志位置，但只會(huì)有1個(gè)成功。所有失敗的寫都會(huì)觀察到成功的寫操作，然后中止，并且重試它們的操作。咨詢式的鎖定能夠減少爭(zhēng)用所帶來的影響。通過特定的前端服務(wù)器分批寫入似乎能夠完全避免競(jìng)爭(zhēng)(這幾句有些不能理解)[ Advisory locking is available to reduce the effects of contention.Batching writes through session affinity to a particular front-end server can avoid contention altogether.]。完整事務(wù)生命周期包括以下步驟：

1.讀：獲取時(shí)間戳和最后一個(gè)提交事務(wù)的日志位置

2.應(yīng)用邏輯：從BigTable讀取并且聚集寫操作到一個(gè)日志Entry 3.提交：使用Paxos將日志Entry加到日志中 4.生效：將數(shù)據(jù)更新到BigTable的實(shí)體和索引中 5.清理：刪除不再需要的數(shù)據(jù)

寫操作能夠在提交之后的任何點(diǎn)返回，但是最好還是等到最近的副本(replica)生效(再返回)。Megastore提供的消息隊(duì)列提供了在不同Entity Group之間的事務(wù)消息。它們能被用作跨Entity Group的操作，在一個(gè)事務(wù)中分批執(zhí)行多個(gè)更新，或者延緩工作(？)。一個(gè)在單個(gè)Entity Group上的事務(wù)能夠原子性地發(fā)送或者收到多個(gè)信息除了更新它自己的實(shí)體。每個(gè)消息都有一個(gè)發(fā)送和接收的Entity Group；如果這兩個(gè)Entity Group是不同的，那么傳輸將會(huì)是異步的。

消息隊(duì)列提供了一種將會(huì)影響到多個(gè)Entity Group的操作的途徑，舉個(gè)例子，日歷應(yīng)用中，每一個(gè)日歷有一個(gè)獨(dú)立的Entity Group，并且我們現(xiàn)在需要發(fā)送一個(gè)邀請(qǐng)到多個(gè)其他人的日歷中，一個(gè)事務(wù)能夠原子地發(fā)送邀請(qǐng)消息到多個(gè)獨(dú)立日歷中。每個(gè)日歷收到消息都會(huì)把邀請(qǐng)加入到它自己的事務(wù)中，并且這個(gè)事務(wù)會(huì)更新被邀請(qǐng)人狀態(tài)然后刪除這個(gè)消息。Megastore大規(guī)模使用了這種模式：聲明一個(gè)隊(duì)列后會(huì)自動(dòng)在每一個(gè)Entity Group上創(chuàng)建一個(gè)收件箱。Megastore支持使用二段提交進(jìn)行跨Entity Group的原子更新操作。因?yàn)檫@些事務(wù)有比較高的延遲并且增加了競(jìng)爭(zhēng)的風(fēng)險(xiǎn)，一般不鼓勵(lì)使用。

接下來內(nèi)容具體來介紹下Megastore最核心的同步復(fù)制模式：一個(gè)低延遲的Paxos實(shí)現(xiàn)。Megastore的復(fù)制系統(tǒng)向外提供了一個(gè)單一的，一致的數(shù)據(jù)視圖，讀和寫能夠從任何副本(repli ca)開始，并且無論從哪個(gè)副本的客戶端開始，都能保證ACID語義。每個(gè)Entity Group復(fù)制結(jié)束標(biāo)志是將這個(gè)Entity Group事務(wù)日志同步地復(fù)制到一組副本中。寫操作通常需要一個(gè)數(shù)據(jù)中心內(nèi)部的網(wǎng)絡(luò)交互，并且會(huì)跑檢查健康狀況的讀操作。current級(jí)別的讀操作會(huì)有以下保證：

1.一個(gè)讀總是能夠看到最后一個(gè)被確認(rèn)的寫。(可見性)2.在一個(gè)寫被確認(rèn)后，所有將來的讀都能夠觀察到這個(gè)寫的結(jié)果。(持久性，一個(gè)寫可能在確認(rèn)之前就被觀察到)數(shù)據(jù)庫(kù)典型使用Paxos一般是用來做事務(wù)日志的復(fù)制，日志中每個(gè)位置都由一個(gè)Paxos實(shí)例來負(fù)責(zé)。新的值將會(huì)被寫入到之前最后一個(gè)被選中的位置之后。

Megastore在事先Paxos過程中，首先設(shè)定了一個(gè)需求，就是current reads可能在任何副本中進(jìn)行，并且不需要任何副本之間的RPC交互。因?yàn)閷懖僮饕话銜?huì)在所有副本上成功，所以允許在任何地方進(jìn)行本地讀取是現(xiàn)實(shí)的。這些本地讀取能夠很好地被利用，所有區(qū)域的低延遲，細(xì)顆粒度的讀取failover，還有簡(jiǎn)單的編程體驗(yàn)。

Megastore設(shè)計(jì)實(shí)現(xiàn)了一個(gè)叫做Coordinator(協(xié)調(diào)者)的服務(wù)，這個(gè)服務(wù)分布在每個(gè)副本的數(shù)據(jù)中心里面。一個(gè)Coordinator服務(wù)器跟蹤一個(gè)Entity Groups集合，這個(gè)集合中的Entity Groups需要具備的條件就是它們的副本已經(jīng)觀察到了所有的Paxos寫。在這個(gè)集合中的Entity Groups，它們的副本能夠進(jìn)行本地讀取(local read)。

寫操作算法有責(zé)任保持Coordinator狀態(tài)是保守的，如果一個(gè)寫在一個(gè)副本上失敗了，那么這次操作就不能認(rèn)為是提交的，直到這個(gè)entity group的key從這個(gè)副本的coordinator中去除。(這里不明白)為了達(dá)到快速的單次交互的寫操作，Megastore采用了一種Master-Slave方式的優(yōu)化，如果一次寫成功了，那么會(huì)順帶下一次寫的保證(也就是下一次寫就不需要prepare去申請(qǐng)一個(gè)log position)，下一次寫的時(shí)候，跳過prepare過程，直接進(jìn)入accept階段。Megastore沒有使用專用的Masters，但是使用Leaders。

Megastore為每一個(gè)日志位置運(yùn)行一個(gè)Paxos算法實(shí)例。[ The leader for each log position is a distinguished replica chosen alongside the preceding log position's consensus value.] Leader仲裁在0號(hào)提議中使用哪一個(gè)值。第一個(gè)寫入者向Leader提交一個(gè)值會(huì)贏得一個(gè)向所有副本請(qǐng)求接收這個(gè)值做為0號(hào)提議最終值的機(jī)會(huì)。所有其他寫入者必需退回到Paxos的第二階段。

因?yàn)橐粋€(gè)寫入在提交值到其他副本之前必需和Leader交互，所以必需盡量減少寫入者和Leader之間的延遲。Megastore設(shè)計(jì)了它們自己的選取下一個(gè)寫入Leader的規(guī)則，以同一地區(qū)多數(shù)應(yīng)用提交的寫操作來決定。這個(gè)產(chǎn)生了一個(gè)簡(jiǎn)單但是有效的原則：使用最近的副本。(這里我理解的是哪個(gè)位置提交的寫多，那么使用離這個(gè)位置最近的副本做為L(zhǎng)eader)Megastore的副本中除了有日志有Entity數(shù)據(jù)和索引數(shù)據(jù)的副本外，還有兩種角色，其中一種叫做觀察者(Witnesses)，它們只寫日志，并且不會(huì)讓日志生效，也沒有數(shù)據(jù)，但是當(dāng)副本不足以組成一個(gè)quorum的時(shí)候，它們就可以加入進(jìn)來。另外一種叫只讀副本(Read-Only)，它剛剛和觀察者相反，它們只有數(shù)據(jù)的鏡像，在這些副本上只能讀取到最近過去某一個(gè)時(shí)間點(diǎn)的一致性數(shù)據(jù)。如果讀操作能夠容忍這些過期數(shù)據(jù)，只讀副本能夠在廣闊的地理空間上進(jìn)行數(shù)據(jù)傳輸并且不會(huì)加劇寫的延遲。

上圖顯示了Megastore的關(guān)鍵組件，包括兩個(gè)完整的副本和一個(gè)觀察者。應(yīng)用連接到客戶端庫(kù)，這個(gè)庫(kù)實(shí)現(xiàn)了Paxos和其他一些算法：選擇一個(gè)副本進(jìn)行讀，延遲副本的追趕，等等。

Each application server has a designated local replica.The client library makes Paxos operations on that replica durable by submitting transactions directly to the local Bigtable.To minimize wide-area roundtrips, the library submits remote Paxos operations to stateless intermediary replication servers communicating with their local Bigtables.客戶端，網(wǎng)絡(luò)，或者BigTable失敗可能讓一個(gè)寫操作停止在一個(gè)中間狀態(tài)。復(fù)制的服務(wù)器會(huì)定期掃描未完成的寫入并且通過Paxos提議沒有操作的值來讓寫入完成。

接下來介紹下Megastore的數(shù)據(jù)結(jié)構(gòu)和算法，每一個(gè)副本存有更新和日志Entries的元數(shù)據(jù)。為了保證一個(gè)副本能夠參與到一個(gè)寫入的投票中即使是它正從一個(gè)之前的宕機(jī)中恢復(fù)數(shù)據(jù)，Megastore允許這個(gè)副本接收不符合順序的提議。Megastore將日志以獨(dú)立的Cells存儲(chǔ)在BigTable中。

當(dāng)日志的前綴不完整時(shí)(這個(gè)前綴可能就是一個(gè)日志是否真正寫入的標(biāo)記，分為2段，第一段是在寫入日志之前先寫入的幾個(gè)字節(jié)，然后寫入日志，第二段是在寫入日志之后寫入的幾個(gè)字節(jié)，只有這個(gè)日志前綴是完整的，這個(gè)日志才是有效的)，日志將會(huì)留下holes。下圖表示了一個(gè)單獨(dú)Megastore Entity Group的日志副本典型場(chǎng)景。0-99的日志位置已經(jīng)被清除了，100的日志位置是部分被清除，因?yàn)槊總€(gè)副本都會(huì)被通知到其他副本已經(jīng)不需要這個(gè)日志了。101日志位置被所有的副本接受了(accepted)，102日志位置被Y所獲得，103日志位置被A和C副本接受，B副本留下了一個(gè)hole，104日志位置因?yàn)楦北続和B的不一致，復(fù)本C的沒有響應(yīng)而沒有一致結(jié)果。

在一個(gè)current讀的準(zhǔn)備階段(寫之前也一樣)，必需有一個(gè)副本要是最新的：所有之前更新必需提交到那個(gè)副本的日志并且在該副本上生效。我們叫這個(gè)過程為catchup。省略一些截止超時(shí)的管理，一個(gè)current讀算法步驟如下：

1.本地查詢：查詢本地副本的Coordinator，判定當(dāng)前副本的Entity Group是最新的 2.查找位置：確定最高的可能已提交的日志位置，然后選擇一個(gè)己經(jīng)將這個(gè)日志位置生效的副本

a.(Local read)如果步驟1發(fā)現(xiàn)本地副本是最新的，那么從本地副本中讀取最高的被接受(accepted)的日志位置和時(shí)間戳。

b.(Majority read)如果本地副本不是最新的(或者步驟1或步驟2a超時(shí))，那么從一個(gè)多數(shù)派副本中發(fā)現(xiàn)最大的日志位置，然后選取一個(gè)讀取。我們選取一個(gè)最可靠的或者最新的副本，不一定總是是本地副本

3.追趕：當(dāng)一個(gè)副本選中之后，按照下面的步驟追趕到已知的日志位置: a.對(duì)于被選中的不知道共識(shí)值的副本中的每一個(gè)日志位置，從另外一個(gè)副本中讀取值。對(duì)于任何一個(gè)沒有已知已提交的值的日志位置，發(fā)起一個(gè)沒有操作的寫操作。Paxos將會(huì)驅(qū)動(dòng)多數(shù)副本在一個(gè)值上打成共識(shí)-----可能是none-op的寫操作或者是之前提議的寫操作 b.順序地將所有沒有生效的日志位置生效成共識(shí)的值，并將副本的狀態(tài)變?yōu)榈椒植际焦沧R(shí)狀態(tài)(應(yīng)該是Coordinator的狀態(tài)更新)如果失敗，在另外一個(gè)副本上重試。4.驗(yàn)證：如果本地副本被選中并且之前沒有最新，發(fā)送一個(gè)驗(yàn)證消息到coordinator斷定(entity group,replica)能夠反饋(reflects)所有提交的寫操作。不要等待回應(yīng)----如果請(qǐng)求失敗，下一個(gè)讀操作會(huì)重試。

5.查詢數(shù)據(jù)：從選中的副本中使用日志位置所有的時(shí)間戳讀取數(shù)據(jù)。如果選中的副本不可用，選取另外一個(gè)副本重新開始執(zhí)行追趕，然后從它那里讀取。一個(gè)大的讀取結(jié)果有可能從多個(gè)副本中透明地讀取并且組裝返回

注意在實(shí)際使用中 1和2a通常是并行執(zhí)行的。

在完整的讀操作算法執(zhí)行后，Megastore發(fā)現(xiàn)了下一個(gè)沒有使用的日志位置，最后一個(gè)寫操作的時(shí)間戳，還有下一個(gè)leader副本。在提交時(shí)刻，所有更新的狀態(tài)都變?yōu)榇虬?packaged)和提議(proposed)，并且包含一個(gè)時(shí)間戳和下一個(gè)leader 候選人，做為下一個(gè)日志位置的共識(shí)值。如果這個(gè)值贏得了分布式共識(shí)，那么這個(gè)值將會(huì)在所有完整的副本中生效。否則整個(gè)事務(wù)將會(huì)終止并且必需重新從讀階段開始。

就像上面所描述的，Coordinators跟蹤Entity Groups在它們的副本中是否最新。如果一個(gè)寫操作沒有被一個(gè)副本接受，我們必需將這個(gè)Entity Group的鍵從這個(gè)副本的Coordinator中移除。這個(gè)步驟叫做invalidation(失效)。在一個(gè)寫操作被認(rèn)為提交的并且準(zhǔn)備生效，所有副本必需已經(jīng)接受或者讓這個(gè)Entity Group在它們coordinator上失效。寫算法的步驟如下：

1.接受Leader：請(qǐng)求Leader接受值做為0號(hào)提議的值。如果成功。跳到第三步

2.準(zhǔn)備：在所有副本上執(zhí)行Paxos Prepare階段，使用一個(gè)關(guān)于當(dāng)前l(fā)og位置更高的提議號(hào)。將值替換成擁有最高提議號(hào)的那個(gè)值。[Replace the value being written withthe highest-numbered proposal discovered, if any] 3.接受：請(qǐng)求余下的副本接受這個(gè)值。如果多數(shù)副本失敗，轉(zhuǎn)到第二步。4.失效：將沒有接受值的副本coordinator失效掉。錯(cuò)誤處理將在接下來描述

5.生效：將更新在盡可能多的副本上生效。如果選擇的值不同于原始提議的，返回沖突錯(cuò)誤[？]

Coordinator進(jìn)程在每一個(gè)數(shù)據(jù)中心運(yùn)行并且只保持其本地副本的狀態(tài)。在上述的寫入算法中，每一個(gè)完整的副本必需接受或者讓其coordinator失效，所以這個(gè)可能會(huì)出現(xiàn)任何單個(gè)副本失效就會(huì)引起不可用。在實(shí)際使用中這個(gè)不是一個(gè)尋常的問題。Coordinator是一個(gè)簡(jiǎn)單的進(jìn)程，沒有其他額外的依賴并且沒有持久存儲(chǔ)，所以它表現(xiàn)得比一個(gè)BigTable服務(wù)器更高的穩(wěn)定性。然而，網(wǎng)絡(luò)和主機(jī)失敗仍然能夠讓coordinator不可用。

Megastore使用了Chubby鎖服務(wù)：Coordinators在啟動(dòng)的時(shí)候從遠(yuǎn)程數(shù)據(jù)中心獲取指定的Chubby locks。為了處理請(qǐng)求，一個(gè)Coordinator必需持有其多數(shù)locks。一旦因?yàn)殄礄C(jī)或者網(wǎng)絡(luò)問題導(dǎo)致它丟失了大部分鎖，它就會(huì)恢復(fù)到一個(gè)默認(rèn)保守狀態(tài)----認(rèn)為所有在它所能看見的Entity Groups都是失效的。隨后(該Coordinator對(duì)應(yīng)的)副本中的讀操作必需從多數(shù)其他副本中得到日志位置直到Coordinator重新獲取到鎖并且Coordinator的Entries重新驗(yàn)證的。

寫入者通過測(cè)試一個(gè)Coordinator是否丟失了它的鎖從而讓其在Coordinator不可用過程中得到保護(hù)：在這個(gè)場(chǎng)景中，一個(gè)寫入者知道在恢復(fù)之前Coordinator會(huì)認(rèn)為自己是失效的。在一個(gè)數(shù)據(jù)中心活著的Coordinator突然不可用時(shí)，這個(gè)算法需要面對(duì)一個(gè)短暫(幾十秒)的寫停頓風(fēng)險(xiǎn)---所有的寫入者必需等待Coordinator的Chubby locks過期(相當(dāng)于等待一個(gè)master failover后重新啟動(dòng))，不同于master failover，寫入和讀取都能夠在coordinator狀態(tài)重建前繼續(xù)平滑進(jìn)行。除了可用性問題，對(duì)于Coordinator的讀寫協(xié)議必需滿足一系列的競(jìng)爭(zhēng)條件。失效的信息總是安全的，但是生效的信息必需小心處理。在coordinator中較早的寫操作生效和較晚的寫操作失效之間的競(jìng)爭(zhēng)通過帶有日志位置而被保護(hù)起來。標(biāo)有較高位置的失效操作總是勝過標(biāo)有較低位置的生效操作。一個(gè)在位置n的失效操作和一個(gè)在位置m

總體來說，使用Coordinator從而能夠在任何數(shù)據(jù)中心進(jìn)行快速的本地讀取對(duì)于可用性的影響并不是完全沒有的。但是實(shí)際上，以下因素能夠減輕使用Coordinator所帶來的問題。1.Coordinators是比任何的BigTable 服務(wù)器更加簡(jiǎn)單進(jìn)程，機(jī)會(huì)沒有依賴，所以可用性更高。

2.Coordinators簡(jiǎn)單，均勻的工作負(fù)載讓它們能夠低成本地進(jìn)行預(yù)防措施。3.Coordinators輕量的網(wǎng)絡(luò)傳輸允許使用高可用連接進(jìn)行服務(wù)質(zhì)量監(jiān)控。

4.管理員能夠在維護(hù)期或者非安全期集中地讓一批Coordinators失效。對(duì)于默寫信號(hào)的監(jiān)測(cè)是自動(dòng)的。

5.一個(gè)Chubby qunrum能夠監(jiān)測(cè)到大多數(shù)網(wǎng)絡(luò)問題和節(jié)點(diǎn)不可用。總結(jié)

文章總體介紹了下google megastore的實(shí)現(xiàn)思路，其主要解決的問題就是如何在復(fù)雜的環(huán)境下(網(wǎng)絡(luò)問題,節(jié)點(diǎn)失效等等)保證數(shù)據(jù)存取服務(wù)的可用性。對(duì)于多機(jī)房，多節(jié)點(diǎn)，以及ACID事務(wù)支持，實(shí)時(shí)非實(shí)時(shí)讀取，錯(cuò)誤處理等等關(guān)鍵問題上給出了具體方案。

第二篇：從Google Spanner漫談分布式存儲(chǔ)與數(shù)據(jù)庫(kù)技術(shù)

從Google Spanner漫談分布式存儲(chǔ)與數(shù)據(jù)庫(kù)技術(shù)

文/曹偉

Spanner 的設(shè)計(jì)反映了 Google 多年來在分布式存儲(chǔ)系統(tǒng)領(lǐng)域上經(jīng)驗(yàn)的積累和沉淀，它采用了 Megastore 的數(shù)據(jù)模型，Chubby 的數(shù)據(jù)復(fù)制和一致性算法，而在數(shù)據(jù)的可擴(kuò)展性上使用了 BigTable 中的技術(shù)。新穎之處在于，它使用高精度和可觀測(cè)誤差的本地時(shí)鐘來判斷分布式系統(tǒng)中事件的先后順序。Spanner 代表了分布式數(shù)據(jù)庫(kù)領(lǐng)域的新趨勢(shì)——NewSQL。

Spanner 是 Google 最近公開的新一代分布式數(shù)據(jù)庫(kù)，它既具有 NoSQL 系統(tǒng)的可擴(kuò)展性，也具有關(guān)系數(shù)據(jù)庫(kù)的功能。例如，它支持類似 SQL 的查詢語言、支持表連接、支持事務(wù)（包括分布式事務(wù)）。Spanner 可以將一份數(shù)據(jù)復(fù)制到全球范圍的多個(gè)數(shù)據(jù)中心，并保證數(shù)據(jù)的一致性。一套 Spanner 集群可以擴(kuò)展到上百個(gè)數(shù)據(jù)中心、百萬臺(tái)服務(wù)器和上T條數(shù)據(jù)庫(kù)記錄的規(guī)模。目前，Google 廣告業(yè)務(wù)的后臺(tái)（F1）已從 MySQL 分庫(kù)分表方案遷移到了 Spanner 上。

數(shù)據(jù)模型

傳統(tǒng)的 RDBMS（例如 MySQL）采用關(guān)系模型，有豐富的功能，支持 SQL 查詢語句。而 NoSQL 數(shù)據(jù)庫(kù)多是在 key-value 存儲(chǔ)之上增加有限的功能，如列索引、范圍查詢等，但具有良好的可擴(kuò)展性。Spanner 繼承了 Megastore 的設(shè)計(jì)，數(shù)據(jù)模型介于 RDBMS 和 NoSQL 之間，提供樹形、層次化的數(shù)據(jù)庫(kù) schema，一方面支持類 SQL 的查詢語言，提供表連接等關(guān)系數(shù)據(jù)庫(kù)的特性，功能上類似于 RDBMS；另一方面整個(gè)數(shù)據(jù)庫(kù)中的所有記錄都存儲(chǔ)在同一個(gè) key-value 大表中，實(shí)現(xiàn)上類似于 BigTable，具有 NoSQL 系統(tǒng)的可擴(kuò)展性。

在 Spanner 中，應(yīng)用可以在一個(gè)數(shù)據(jù)庫(kù)里創(chuàng)建多個(gè)表，同時(shí)需要指定這些表之間的層次關(guān)系。例如，圖 1 中創(chuàng)建的兩個(gè)表——用戶表（Users）和相冊(cè)表（Albums），并且指定用戶表是相冊(cè)表的父節(jié)點(diǎn)。父節(jié)點(diǎn)和子節(jié)點(diǎn)間存在著一對(duì)多的關(guān)系，用戶表中的一條記錄（一個(gè)用戶）對(duì)應(yīng)著相冊(cè)表中的多條記錄（多個(gè)相冊(cè)）。此外，要求子節(jié)點(diǎn)的主鍵必須以父節(jié)點(diǎn)的主鍵作為前綴。例如，用戶表的主鍵（用戶 ID）就是相冊(cè)表主鍵（用戶 ID+ 相冊(cè) ID）的前綴。

圖 1 schema 示例，表之間的層次關(guān)系，記錄排序后交錯(cuò)的存儲(chǔ)

顯然所有表的主鍵都將根節(jié)點(diǎn)的主鍵作為前綴，Spanner 將根節(jié)點(diǎn)表中的一條記錄，和以其主鍵作為前綴的其他表中的所有記錄的集合稱作一個(gè) Directory。例如，一個(gè)用戶的記錄及該用戶所有相冊(cè)的記錄組成了一個(gè) Directory。Directory 是 Spanner 中對(duì)數(shù)據(jù)進(jìn)行分區(qū)、復(fù)制和遷移的基本單位，應(yīng)用可以指定一個(gè) Directory 有多少個(gè)副本，分別存放在哪些機(jī)房中，例如把用戶的 Directory 存放在這個(gè)用戶所在地區(qū)附近的幾個(gè)機(jī)房中。

這樣的數(shù)據(jù)模型具有以下好處。

? 一個(gè) Directory 中所有記錄的主鍵都具有相同前綴。在存儲(chǔ)到底層 key-value 大表時(shí)，會(huì)被分配到相鄰的位置。如果數(shù)據(jù)量不是非常大，會(huì)位于同一個(gè)節(jié)點(diǎn)上，這不僅提高了數(shù)據(jù)訪問的局部性，也保證了在一個(gè) Directory 中發(fā)生的事務(wù)都是單機(jī)的。

? Directory 還實(shí)現(xiàn)了從細(xì)粒度上對(duì)數(shù)據(jù)進(jìn)行分區(qū)。整個(gè)數(shù)據(jù)庫(kù)被劃分為百萬個(gè)甚至更多個(gè) Directory，每個(gè) Directory 可以定義自己的復(fù)制策略。這種 Directory-based 的數(shù)據(jù)分區(qū)方式比 MySQL 分庫(kù)分表時(shí) Table-based 的粒度要細(xì)，而比 Yahoo!的 PNUTS 系統(tǒng)中 Row-based 的粒度要粗。

? Directory 提供了高效的表連接運(yùn)算方式。在一個(gè) Directory 中，多張表上的記錄按主鍵排序，交錯(cuò)（interleaved）地存儲(chǔ)在一起，因此進(jìn)行表連接運(yùn)算時(shí)無需排序即可在表間直接進(jìn)行歸并。

復(fù)制和一致性

Spanner 使用 Paxos 協(xié)議在多個(gè)副本間同步 redo 日志，從而保證數(shù)據(jù)在多個(gè)副本上是一致的。Google 的工程師鐘情于 Paxos 協(xié)議，Chubby、Megastore 和 Spanner 等一系列產(chǎn)品都是在 Paxos 協(xié)議的基礎(chǔ)上實(shí)現(xiàn)一致性的。

Paxos 的基本協(xié)議很簡(jiǎn)單。協(xié)議中有三個(gè)角色：Proposer、Acceptor 和 Learner，Learner 和 Proposer 分別是讀者和寫者，Acceptor 相當(dāng)于存儲(chǔ)節(jié)點(diǎn)。整個(gè)協(xié)議描述的是，當(dāng)系統(tǒng)中有多個(gè) Proposer 和 Acceptor 時(shí)，每次 Proposer 寫一個(gè)變量就會(huì)啟動(dòng)一輪決議過程（Paxos instance），如圖 2 所示。決議過程可以保證即使多個(gè) Proposer 同時(shí)寫，結(jié)果也不會(huì)在 Acceptor 節(jié)點(diǎn)上不一致。確切地說，一旦某個(gè) Proposer 提交的值被大多數(shù) Acceptor 接受，那么這個(gè)值就被選中，在整輪決議的過程中該變量就不會(huì)再被修改為其他值。如果另一個(gè) Proposer 要寫入其他值，必須啟動(dòng)下一輪決議過程，而決議過程之間是串行（serializable）的。

圖 2 Paxos 協(xié)議正常執(zhí)行流程

一輪決議過程分為兩個(gè)階段，即 prepare 階段和 accept 階段。

? 第一階段A：Proposer 向所有 Acceptor 節(jié)點(diǎn)廣播 prepare 消息，消息中只包含一個(gè)序號(hào)——N。Proposer 需要保證這個(gè)序號(hào)在這輪決議過程中是全局唯一的（這很容易做到，假如系統(tǒng)中有兩個(gè) Proposer，那么一個(gè) Proposer 使用1，3，5，7，9，??，另一個(gè) Proposer 則使用0，2，4，6，8，??）。

?

第一階段B：Acceptor 接收到 prepare 消息后，如果N是到目前為止見過的最大序號(hào)，就返回一個(gè) promise 消息，承諾不會(huì)接受序號(hào)小于N的請(qǐng)求；如果已接受過其他 Proposer 提交的值，則會(huì)將這個(gè)值連同提交這個(gè)值的請(qǐng)求的序號(hào)一同返回。? 第二階段A：當(dāng) Proposer 從大多數(shù) Acceptor 節(jié)點(diǎn)收到了 promise 消息后，就可以選擇接下來要向 Acceptor 提交的值了。一般情況下，當(dāng)然選原本打算寫入的值，但如果從收到的 promise 消息中發(fā)現(xiàn)已經(jīng)有其他值被 Acceptor 接受了，那么為了避免造成數(shù)據(jù)不一致的風(fēng)險(xiǎn)，這時(shí) Proposer 就必須“大義滅親”，放棄自己打算寫入的值，從其他 Proposer 提交的序號(hào)中選擇一個(gè)最大的值。接下來 Proposer 向所有的 Acceptor 節(jié)點(diǎn)發(fā)送 accept 包，其中包含在第一階段中挑選的序號(hào)N和剛才選擇的值V。

?

第二階段B：Acceptor 收到 accept 包之后，如果N的大小不違反對(duì)其他

Proposer 的承諾，就接受這個(gè)請(qǐng)求，記錄下值V和序號(hào)N，返回一個(gè) ack 消息。反之，則返回一個(gè) reject 消息。

如果 Proposer 從大多數(shù) Acceptor 節(jié)點(diǎn)收到了 ack 消息，說明寫操作成功。而如果在寫操作過程中失敗，Proposer 可以增大序號(hào)，重新執(zhí)行第一階段。

基本的 Paxos 協(xié)議可以保證值一旦被選出后就一定不會(huì)改變，但不能保證一定會(huì)選出值來。換句話說，這個(gè)投票算法不一定收斂。有兩個(gè)方法可以加速收斂的過程：一個(gè)是在出現(xiàn)沖突后通過隨機(jī)延遲把機(jī)會(huì)讓給其他 Proposer，另一個(gè)是盡量讓系統(tǒng)中只有一個(gè) Proposer 去提交。在 Chubby 和 Spanner 系統(tǒng)中這兩種方法都用上了，先用隨機(jī)延遲的方法通過一輪 Paxos 協(xié)議，在多個(gè) Proposer 中選舉出一個(gè) leader 節(jié)點(diǎn)。接下來所有的寫操作都通過這個(gè) leader 節(jié)點(diǎn)，而 leader 節(jié)點(diǎn)一般還是比較“長(zhǎng)壽”的，在廣域網(wǎng)環(huán)境下平均“任期”可以達(dá)到一天以上。而 Megastore 系統(tǒng)中沒有很好地解決這個(gè)問題，所有的 Proposer 都可以發(fā)起寫操作，這是 Megastore 寫入性能不高的原因之一。

基本的 Paxos 協(xié)議還存在性能上的問題，一輪決議過程通常需要進(jìn)行兩個(gè)回合通信，而一次跨機(jī)房通信的代價(jià)為幾十到一百毫秒不等，因此兩個(gè)回合的通信就有點(diǎn)開銷過高了。不過幸運(yùn)的是，絕大多數(shù)情況下，Paxos 協(xié)議可以優(yōu)化到僅需一個(gè)回合通信。決議過程的第一階段是不需要指定值的，因此可以把 prepare/promise 的過程捎帶在上一輪決議中完成，或者更進(jìn)一步，在執(zhí)行一輪決議的過程中隱式地涵蓋接下來一輪或者幾輪決議的第一階段。這樣，當(dāng)一輪決議完成之后，其他決議的第一階段也已經(jīng)完成了。如此看來，只要 leader 不發(fā)生更替，Paxos 協(xié)議就可以在一個(gè)回合內(nèi)完成。為了支持實(shí)際的業(yè)務(wù)，Paxos 協(xié)議還需要支持并發(fā)，多輪決議過程可以并發(fā)執(zhí)行，而代價(jià)是故障恢復(fù)會(huì)更加復(fù)雜。

因?yàn)?leader 節(jié)點(diǎn)上有最新的數(shù)據(jù)，而在其他節(jié)點(diǎn)上為了獲取最新的數(shù)據(jù)來執(zhí)行 Paxos 協(xié)議的第一階段，需要一個(gè)回合的通信代價(jià)。因此，Chubby 中的讀寫操作，以及 Spanner 中的讀寫事務(wù)都僅在 leader 節(jié)點(diǎn)上執(zhí)行。而為了提高讀操作的性能，減輕 leader 節(jié)點(diǎn)的負(fù)載，Spanner 還提供了只讀事務(wù)和本地讀。只讀事務(wù)只在 leader 節(jié)點(diǎn)上獲取時(shí)間戳信息，再用這個(gè)時(shí)間戳在其他節(jié)點(diǎn)上執(zhí)行讀操作；而本地讀則讀取節(jié)點(diǎn)上最新版本的數(shù)據(jù)。

與 Chubby、Spanner 這種讀寫以 leader 節(jié)點(diǎn)為中心的設(shè)計(jì)相比，Megastore 體現(xiàn)了一定的“去中心化”設(shè)計(jì)。每個(gè)客戶端都可以發(fā)起 Paxos 寫操作，而讀操作則盡可能在本地執(zhí)行。如果客戶端發(fā)現(xiàn)本地?cái)?shù)據(jù)不是最新的，會(huì)啟動(dòng) catchup 流程更新數(shù)據(jù)，再執(zhí)行本地讀操作返回給客戶端。

最后，對(duì)比下其他系統(tǒng)中 replication 的實(shí)現(xiàn)。在 BigTable 系統(tǒng)中每個(gè) tablet 服務(wù)器是沒有副本的，完全依賴底層 GFS 把數(shù)據(jù)存到多臺(tái)機(jī)器上。數(shù)據(jù)的讀寫都通過單個(gè) tablet 服務(wù)器，在 tablet 服務(wù)器出現(xiàn)故障的時(shí)需要 master 服務(wù)器將 tablet 指派到其他 tablet 服務(wù)器上才能恢復(fù)可用。Dynamo 系統(tǒng)則貫徹了“去中心化”的思想，將數(shù)據(jù)保存在多個(gè)副本上，每個(gè)副本都可以寫入（update everywhere）。而不同副本同時(shí)寫入的數(shù)據(jù)可能會(huì)存在不一致，則需要使用版本向量（version vector）記錄不同的值和時(shí)間戳，由應(yīng)用去解釋或合并不一致的數(shù)據(jù)。盡管 Dynamo 系統(tǒng)還提供了 NWR 的方式來支持有一致性保證的讀寫操作，但總的來說 Dynamo 為了高可用性犧牲了一致性。ZooKeeper、MongoDB 與 Chubby、Spanner 類似，通過 leader 選舉協(xié)議從多個(gè)副本中選擇一個(gè) leader，所有寫操作都在經(jīng)過 leader 節(jié)點(diǎn)序列化后，同步到其他副本上。ZooKeeper 則是在寫入大多數(shù)節(jié)點(diǎn)后返回，而 MongoDB 主要采用異步的主從復(fù)制方式。

分布式事務(wù)

Spanner 系統(tǒng)中的分布式事務(wù)通過兩階段提交協(xié)議（2PC）實(shí)現(xiàn)。2PC 是一類特殊的一致性協(xié)議，假設(shè)一個(gè)分布式事務(wù)涉及了多個(gè)數(shù)據(jù)節(jié)點(diǎn)，2PC 可以保證在這些節(jié)點(diǎn)上的操作要么全部提交，要么全部失敗，從而保證了整個(gè)分布式事務(wù)的原子性（ACID 里的A）。協(xié)議中包含兩個(gè)角色：協(xié)調(diào)者（coordinator）和參與者（participant/cohort）。協(xié)調(diào)者是分布式事務(wù)的發(fā)起者，而參與者是參與了事務(wù)的數(shù)據(jù)節(jié)點(diǎn)。在協(xié)議最基本的形式中，系統(tǒng)中有一個(gè)協(xié)調(diào)者和多個(gè)參與者。

顧名思義，2PC 也包含兩個(gè)階段，即投票階段和提交階段（如圖 3 所示）。

圖 3 兩階段提交協(xié)議 ? 在第一階段，協(xié)調(diào)者向所有的參與者發(fā)送投票請(qǐng)求，每個(gè)參與者決定是否要提交事務(wù)。如果打算提交的話需要寫好 redo、undo 等日志，并向協(xié)調(diào)者回復(fù) yes 或 no。

? 在第二階段，協(xié)調(diào)者收到所有參與者的回復(fù)，如果都是 yes，那么決定提交這個(gè)事務(wù)，寫好日志后向所有參與者廣播提交事務(wù)的通知。反之，則中止事務(wù)并且通知所有參與者。參與者收到提交/中止事務(wù)的命令后，執(zhí)行相應(yīng)操作，如果提交的話還需要寫日志。

協(xié)議過程包括兩回合的通信，在協(xié)調(diào)者和參與者端需要多次寫日志，而且整個(gè)過程中所有參與者都占有讀鎖、寫鎖，可見 2PC 開銷不菲。

2PC 最令人詬病之處還不在于性能，而是在有些故障條件下，會(huì)造成所有參與者占有讀鎖、寫鎖堵塞在第二階段，需要人工干預(yù)才能繼續(xù)，存在嚴(yán)重的可用性隱患。假設(shè)故障發(fā)生在第二階段，協(xié)調(diào)者在做出決定后，通知完一個(gè)參與者就宕機(jī)了，更糟糕的是被通知的這位參與者在執(zhí)行完“上級(jí)指示”之后也宕機(jī)了，這時(shí)對(duì)其他參與者來說，就必須堵塞在那里等待結(jié)果。

Spanner 利用基于 Paxos 協(xié)議的復(fù)制技術(shù)，改善了 2PC 的可用性問題。2PC 協(xié)議過程中的協(xié)調(diào)者和參與者生成的日志都會(huì)利用 Paxos 協(xié)議復(fù)制到所有副本中，這樣無論是協(xié)調(diào)者或參與者宕機(jī)，都會(huì)有其他副本代替它們，完成 2PC 過程而不至于堵塞。在 Paxos 協(xié)議上實(shí)現(xiàn) 2PC 這一思路很巧妙，Paxos 協(xié)議保證了大多數(shù)節(jié)點(diǎn)在線情況下的可用性，而 2PC 保證了分布式協(xié)議的一致性。

事件的順序

傳統(tǒng)上，在設(shè)計(jì)一個(gè)分布式系統(tǒng)時(shí)，都會(huì)假設(shè)每個(gè)節(jié)點(diǎn)的運(yùn)行速度和時(shí)鐘的快慢各不相同的情況，并且在節(jié)點(diǎn)之間進(jìn)行同步的唯一方法就是異步通信。系統(tǒng)中的每個(gè)節(jié)點(diǎn)都扮演著觀察者的角色，并從其他節(jié)點(diǎn)接收事件發(fā)生的通知。判斷系統(tǒng)中兩個(gè)事件的先后順序主要依靠分析它們的因果關(guān)系，包括 Lamport 時(shí)鐘、向量時(shí)鐘等算法，而這一切都存在通信開銷。

因此，Spanner 提出了一種新的思路，在不進(jìn)行通信的情況下，利用高精度和可觀測(cè)誤差的本地時(shí)鐘（TrueTime API）給事件打上時(shí)間戳，并且以此比較分布式系統(tǒng)中兩個(gè)事件的先后順序。利用這個(gè)方法，Spanner 實(shí)現(xiàn)了事務(wù)之間的外部一致性（external consistency）（如圖 4 所示），也就是說，一個(gè)事務(wù)結(jié)束后另一個(gè)事務(wù)才開始，Spanner 可以保證第一個(gè)事務(wù)的時(shí)間戳比第二個(gè)事務(wù)的時(shí)間戳要早，從而兩個(gè)事務(wù)被串行化后也一定能保持正確的順序。

圖 4 事務(wù)外部一致性的實(shí)現(xiàn)

TrueTime API 是一個(gè)提供本地時(shí)間的接口，但與 Linux 上 gettimeofday 接口不一樣的是，它除了可以返回一個(gè)時(shí)間戳t，還會(huì)給出一個(gè)誤差ε。例如，返回的時(shí)間戳是 1 分 30 秒 350 毫秒，而誤差是 5 毫秒，那么真實(shí)的時(shí)間在 1 分 30 秒 345 毫秒到 355 毫秒之間。真實(shí)的系統(tǒng)中ε平均下來是 4 毫秒。

利用 TrueTime API，Spanner 可以保證給出的事務(wù)標(biāo)記的時(shí)間戳介于事務(wù)開始的真實(shí)時(shí)間和事務(wù)結(jié)束的真實(shí)時(shí)間之間。假如事務(wù)開始時(shí) TrueTime API 返回的時(shí)間是{t1, ε1}，此時(shí)真實(shí)時(shí)間在 t1-ε1到 t1+ε1之間；事務(wù)結(jié)束時(shí) TrueTime API 返回的時(shí)間是{t2, ε2}，此時(shí)真實(shí)時(shí)間在 t2-ε2到 t2+ε2之間。Spanner 會(huì)在 t1+ε1和 t2-ε2之間選擇一個(gè)時(shí)間點(diǎn)作為事務(wù)的時(shí)間戳，但這需要保證 t1+ε1小于 t2-ε2，為了保證這點(diǎn)，Spanner 會(huì)在事務(wù)執(zhí)行過程中等待，直到 t2-ε2大于 t1+ε1時(shí)才提交事務(wù)。由此可以推導(dǎo)出，Spanner 中一個(gè)事務(wù)至少需要2ε的時(shí)間（平均 8 毫秒）才能完成。

由此可見，這種新方法雖然避免了通信開銷，卻引入了等待時(shí)間。為了保證外部一致性，寫延遲是不可避免的，這也印證了 CAP 定理所揭示的法則，一致性與延遲之間是需要權(quán)衡的。

最后介紹一下 TrueTime API 的實(shí)現(xiàn)。TrueTime API 的實(shí)現(xiàn)大體上類似于網(wǎng)絡(luò)時(shí)間協(xié)議（NTP），但只有兩個(gè)層次。第一層次，服務(wù)器是擁有高精度計(jì)時(shí)設(shè)備的，每個(gè)機(jī)房若干臺(tái)，大部分機(jī)器都裝備了 GPS 接收器，剩下少數(shù)機(jī)器是為 GPS 系統(tǒng)全部失效的情況而準(zhǔn)備的，叫做“末日”服務(wù)器，裝備了原子鐘。所有的 Spanner 服務(wù)器都屬于第二層，定期向多個(gè)第一層的時(shí)間服務(wù)器獲取時(shí)間來校正本地時(shí)鐘，先減去通信時(shí)間，再去除異常值，最后求交集。

NewSQL

六年前，BigTable 展示了一個(gè)簡(jiǎn)潔、優(yōu)美、具有高可擴(kuò)展性的分布式數(shù)據(jù)庫(kù)系統(tǒng)，引起了 NoSQL 浪潮。然而 Spanner 的設(shè)計(jì)者們指出了 BigTable 在應(yīng)用中遇到的一些阻力。

? 缺少類似 SQL 的界面，缺少關(guān)系數(shù)據(jù)庫(kù)擁有的豐富的功能。? 只支持單行事務(wù)，缺少跨行事務(wù)。

?

需要在跨數(shù)據(jù)中心的多個(gè)副本間保證一致性。

這些來自應(yīng)用開發(fā)者的需求催生了 Spanner，一個(gè)既擁有 key-value 系統(tǒng)的高可擴(kuò)展性，也擁有關(guān)系數(shù)據(jù)庫(kù)的豐富功能（包括事務(wù)、一致性等特性）的系統(tǒng)。這類兼顧可擴(kuò)展性和關(guān)系數(shù)據(jù)庫(kù)功能的產(chǎn)品被稱為“NewSQL”，Spanner 的公開會(huì)不會(huì)開啟 NewSQL 的時(shí)代呢？我們拭目以待。

總結(jié)

最后從 CAP 定理的角度來分析下 Spanner。

CAP 定理是指在網(wǎng)絡(luò)可能出現(xiàn)分區(qū)故障的情況下，一致性和可用性不可得兼。形式化地說就是，P => 非(A與P)，可以更進(jìn)一步地總結(jié)為，一致性和延遲之間必須進(jìn)行權(quán)衡。Paxos 協(xié)議在C和A之間選擇了嚴(yán)格的一致性，而A則降級(jí)為大多數(shù)一致性（majority available）。

Spanner 還通過在事務(wù)中增加延遲的方法實(shí)現(xiàn)了外部一致性，每個(gè)事務(wù)需要至少兩倍的時(shí)鐘誤差才能完成。如果時(shí)鐘出現(xiàn)故障造成誤差增長(zhǎng)，那么完成事務(wù)所需的時(shí)間也就隨之增長(zhǎng)。在這里，時(shí)鐘故障也應(yīng)當(dāng)認(rèn)為是P的一種形式。在發(fā)生時(shí)鐘故障（P）的情況下，為了保證一致性（C），而必須增加延遲（A），這一點(diǎn)充分印證了 CAP 定理。

從 Spanner 系統(tǒng)中，我們可以學(xué)習(xí)到一些經(jīng)驗(yàn)。

? MegaStore、Spanner 和 F1 系統(tǒng)所選擇的樹形、層次化的數(shù)據(jù)庫(kù) schema 是很精妙的，它能支持高效的表連接，這既提供了類似關(guān)系模型的范式，也提供了一個(gè)合適的粒度進(jìn)行數(shù)據(jù)分區(qū)，具有好的可擴(kuò)展性，H-Store 也采用了這樣的 schema。

? 跨數(shù)據(jù)中心的多個(gè)副本間保持一致是可行的，Paxos 協(xié)議的性能可以優(yōu)化到一個(gè)可接受的范圍。

? 在 Paxos 協(xié)議的基礎(chǔ)之上實(shí)現(xiàn)的兩階段提交的可用性得到了提高。? 在一個(gè)分布式系統(tǒng)中，本地時(shí)鐘的作用可以比我們之前想象的大很多。

作者曹偉，淘寶核心系統(tǒng)數(shù)據(jù)庫(kù)組技術(shù)專家，從事高性能服務(wù)器、IM、P2P、微博等各類型分布式系統(tǒng)、海量存儲(chǔ)產(chǎn)品的開發(fā)，關(guān)注系統(tǒng)高可用性和一致性及分布式事務(wù)領(lǐng)域。

第三篇：分布式太陽(yáng)能技術(shù)（最終版）

家用、屋頂按階梯電價(jià)算（算上國(guó)家0.42元補(bǔ)貼，若地方暫無補(bǔ)貼）：

第一檔（月）：180度以下，收費(fèi)標(biāo)準(zhǔn)在0.56元/度

推薦安裝1KW-2KW發(fā)電設(shè)備，投資1—2萬元左右，全部自用成本回收年限7年左右，全部出售給電網(wǎng)公司成本回收年限（按賣電0.43元/度算）8年左右。

綜述：成本回收年限在7—8年左右

第二檔（月）：180度—260度，收費(fèi)標(biāo)準(zhǔn)在0.61元/度

推薦安裝2KW-3KW發(fā)電設(shè)備，投資2—3萬元左右，全部自用成本回收年限6.7年左右，全部出售給電網(wǎng)公司成本回收年限（按賣電0.43元/度算）8年左右

綜述：成本回收年限在6.7—8年左右

第三檔（月）：260度以上，收費(fèi)標(biāo)準(zhǔn)在0.86元/度

推薦安裝3KW以上發(fā)電設(shè)備，投資3萬元以上，全部自用成本回收年限在5.5年左右，全部出售給電網(wǎng)公司成本回收年限（按賣電0.43元/度算）8年左右

綜述：成本回收年限在5.5—8年左右

投資家用太陽(yáng)能發(fā)電不僅在一定程度上擺脫對(duì)傳統(tǒng)電力的依賴，還是一份高回報(bào)無風(fēng)險(xiǎn)的對(duì)未來收益擁有充分保障的投資，更是您對(duì)全球碳減排做出的一份努力。江陰中望光伏科技有限公司，專業(yè)提供太陽(yáng)能發(fā)電一站式服務(wù)，質(zhì)量有保障，如果您有相關(guān)需求，請(qǐng)撥打我們的聯(lián)系電話：400-600-5338。

家用、屋頂按階梯電價(jià)算（算上國(guó)家0.42元補(bǔ)貼，若地方暫無補(bǔ)貼）：

第一檔（月）：180度以下，收費(fèi)標(biāo)準(zhǔn)在0.56元/度

推薦安裝1KW-2KW發(fā)電設(shè)備，投資1—2萬元左右，全部自用成本回收年限7年左右，全部出售給電網(wǎng)公司成本回收年限（按賣電0.43元/度算）8年左右。

綜述：成本回收年限在7—8年左右

第二檔（月）：180度—260度，收費(fèi)標(biāo)準(zhǔn)在0.61元/度

推薦安裝2KW-3KW發(fā)電設(shè)備，投資2—3萬元左右，全部自用成本回收年限6.7年左右，全部出售給電網(wǎng)公司成本回收年限（按賣電0.43元/度算）8年左右

綜述：成本回收年限在6.7—8年左右

第三檔（月）：260度以上，收費(fèi)標(biāo)準(zhǔn)在0.86元/度

推薦安裝3KW以上發(fā)電設(shè)備，投資3萬元以上，全部自用成本回收年限在5.5年左右，全部出售給電網(wǎng)公司成本回收年限（按賣電0.43元/度算）8年左右

綜述：成本回收年限在5.5—8年左右

投資家用太陽(yáng)能發(fā)電不僅在一定程度上擺脫對(duì)傳統(tǒng)電力的依賴，還是一份高回報(bào)無風(fēng)險(xiǎn)的對(duì)未來收益擁有充分保障的投資，更是您對(duì)全球碳減排做出的一份努力。江陰中望光伏科技有限公司，專業(yè)提供太陽(yáng)能發(fā)電一站式服務(wù)，質(zhì)量有保障，如果您有相關(guān)需求，請(qǐng)撥打我們的聯(lián)系電話：400-600-5338。

家庭屋頂怎樣安裝光伏發(fā)電系統(tǒng)？

發(fā)布者：gaoming發(fā)布時(shí)間：2016-08-17 10:39:54瀏覽：100

近年來，太陽(yáng)能光伏發(fā)電這一綠色能源走進(jìn)了人們的視野，我們看到一些山上排布整齊、大氣的藍(lán)色光伏組房以及一些居民區(qū)屋頂上也會(huì)發(fā)現(xiàn)光伏發(fā)電系統(tǒng)。光伏發(fā)電開始走進(jìn)了我們的生活中，有不少朋友很好奇，太陽(yáng)不能也安裝一套呢?不要著急，下面PVtrade光伏交易網(wǎng)來給您介紹一下屋頂?shù)降自趺窗惭b太陽(yáng)能光伏發(fā)電系統(tǒng)

1、安裝光伏發(fā)電系統(tǒng)的屋頂類型要求

一般情況下分為水平屋頂和斜屋頂，水平屋頂即屋頂是平面的，主要以水泥屋頂為主。斜屋頂包括彩鋼斜屋的話，南方一般以角度大的斜屋頂資源為主;中部地區(qū)兼有，而東北地區(qū)則大部分是陶瓦屋頂資源。

日常用電單位為千瓦時(shí)，安裝太陽(yáng)能光伏發(fā)電系統(tǒng)通常以功率單位千瓦來計(jì)算。安裝設(shè)備位置主要以向陽(yáng)面光伏發(fā)電系統(tǒng)大小，詳細(xì)參考如下表：

2、光伏發(fā)電設(shè)備安裝條件

這些數(shù)據(jù)是怎么計(jì)算的呢?由于水泥屋頂放置光伏組件時(shí)，需將組件傾斜一定角度，用以保證光照盡可能垂光伏支架將組件固定，為避免前后排組件間遮擋，要空余一定間隔。間隔大小根據(jù)地區(qū)有所差異，一般每千瓦光平米左右。斜屋頂可直接敷設(shè)于屋頂上，因此可忽略間隔，而斜屋頂每千瓦組件需屋頂面積在10-15平米左右。

在安裝光伏系統(tǒng)時(shí)，首先要保證在避免破壞屋頂?shù)那闆r下安裝。

對(duì)于水泥平屋頂來說，對(duì)于使用防水層的屋頂，比如覆蓋瀝青等。要盡量避免在屋頂打孔，可采用放置水泥基礎(chǔ)下面墊橡膠墊以保護(hù)防水層，并防止水泥基礎(chǔ)的滑動(dòng)。

對(duì)于斜屋頂而言，瓦式屋頂需將瓦片掀起，將陶瓦掛鉤固定在房梁上或水泥層上。因此部分地區(qū)建造房屋頂致陶瓦掛鉤附著力下降，因此要尋找更合理的方式安裝;彩鋼屋頂可根據(jù)彩鋼類型進(jìn)行夾具式或打孔式安裝，打

3、光伏發(fā)電系統(tǒng)發(fā)電量

對(duì)一般家庭來說，安裝一套3-5kW光伏發(fā)電系統(tǒng)即可滿足日常用電所需。例如河北地區(qū)一套3千瓦系統(tǒng)平以供給戶用個(gè)體使用。

由于地區(qū)不同，下面以3千瓦光伏發(fā)電系統(tǒng)為例，光伏交易網(wǎng)為您整理了各地區(qū)3千瓦系統(tǒng)每日發(fā)電量匯總

若您不屬于以上城市，可根據(jù)就近原則作為參考，由于安裝角度不同、光照情況的變化以及設(shè)備的差異，可若想要系統(tǒng)達(dá)到較高的性價(jià)比，需要更合理的優(yōu)化匹配才行。

四、安裝光伏發(fā)電系統(tǒng)價(jià)格

大多數(shù)人最關(guān)心問題大多集中在價(jià)格方面。根據(jù)現(xiàn)在光伏市場(chǎng)上光伏發(fā)電系統(tǒng)平均價(jià)格計(jì)算，一套3千瓦的而安裝環(huán)境難度及光伏產(chǎn)品品牌和質(zhì)量等也會(huì)影響價(jià)格的高低。

光伏發(fā)電已經(jīng)成為很多朋友關(guān)注的熱點(diǎn)，那么光伏發(fā)電系統(tǒng)到底是什么樣子?我們自家屋頂想要安裝需要知道哪些東西呢?

首先我們應(yīng)該了解大致流程是什么，下面筆者為大家介紹一下如何安裝一套家用光伏系統(tǒng)。

一、根據(jù)屋頂情況計(jì)算裝機(jī)容量

一般情況下，我們估算自家屋頂能夠裝多大光伏系統(tǒng)，可根據(jù)下面公式進(jìn)行計(jì)算：

水泥平屋頂：裝機(jī)量=80瓦/平米×屋頂面積;

彩鋼或瓦屋頂：裝機(jī)量=100瓦/平米×屋頂面積;下面是筆者為大家測(cè)算的裝機(jī)量可供參考：

二、光伏系統(tǒng)發(fā)電量

對(duì)一般家庭來說，安裝一套3到5kW的光伏發(fā)電系統(tǒng)即可滿足日常用電所需。例如河北地區(qū)一套3千瓦系統(tǒng)平均每天可發(fā)電12度電左右;5千瓦系統(tǒng)一天發(fā)電量平均在20多度，天氣較好的時(shí)候可達(dá)到30度以上，足以供給戶用個(gè)體使用。由于地區(qū)不同，溫度和光照條件不同，所有發(fā)電量會(huì)有所差異。

三、了解當(dāng)?shù)毓夥a(bǔ)貼政策

想要安裝光伏發(fā)電系統(tǒng)，了解補(bǔ)貼政策必不可少，這關(guān)乎到我們能夠獲得多少收益!光伏補(bǔ)貼分為國(guó)家補(bǔ)貼和地方補(bǔ)貼，國(guó)家補(bǔ)貼為0.42元/度電，共補(bǔ)貼20年，地方補(bǔ)貼因各地政策不同而有所差異，今后筆者會(huì)將匯總的地方補(bǔ)貼政策陸續(xù)分享給大家。

一般家用系統(tǒng)的光伏補(bǔ)貼主要和我們的上網(wǎng)模式有關(guān)，分為兩種情況：

1.自發(fā)自用，余電上網(wǎng)模式：即光伏所發(fā)的電量?jī)?yōu)先為用戶的家用電器等設(shè)備使用，用不完的電量賣給國(guó)家電網(wǎng)。當(dāng)然，所發(fā)電量不夠用時(shí)，家用設(shè)備用電還需要從電網(wǎng)取電。

補(bǔ)貼金額為：自用電量×(國(guó)家補(bǔ)貼×補(bǔ)貼年限+地方補(bǔ)貼×補(bǔ)貼年限)

其中：國(guó)家補(bǔ)貼0.42元/度，補(bǔ)貼20年;各地方補(bǔ)貼政策不同，詳細(xì)情況可加筆者微信進(jìn)行咨詢。

2.全額上網(wǎng)模式：所發(fā)電量全部賣給國(guó)家電網(wǎng)。

補(bǔ)貼金額為：發(fā)電量×(國(guó)家補(bǔ)貼×補(bǔ)貼年限+地方補(bǔ)貼×補(bǔ)貼年限)

其中：國(guó)家補(bǔ)貼0.88元/度-0.98元/度，補(bǔ)貼20年;各地補(bǔ)貼政策不同。

按照河北(冀南地區(qū))補(bǔ)貼條件計(jì)算，假如一天發(fā)電25度，按照全額上網(wǎng)測(cè)算：

日收益為：22度×(國(guó)家補(bǔ)貼0.98元/度+地方補(bǔ)貼0.2元/度)=25.96元

年收益為：25.96元×365天=9475.4元

按照全額上網(wǎng)模式計(jì)算，我們一年的收益可以達(dá)到9475.4元左右。大家可以根據(jù)兩種收益進(jìn)行測(cè)算比較，選擇收益較高的上網(wǎng)模式。(算法不清楚的也可咨詢筆者哦!)

四、系統(tǒng)成本報(bào)價(jià)

看完了每年能得到的補(bǔ)貼，有人會(huì)問，我們建這一套系統(tǒng)需要多少錢呢?下面筆者為您呈上設(shè)備價(jià)格單，以供參考：

注：產(chǎn)品價(jià)格根據(jù)品牌、采購(gòu)量、時(shí)間等有所差異，以上價(jià)格僅供參考。

由上表可知，一套5千瓦的光伏系統(tǒng)基本在8.5元/瓦的價(jià)格，一套系統(tǒng)做下來要在4萬多元左右。不同的廠家產(chǎn)品價(jià)格會(huì)有所差異，但是筆者需要提醒大家不要貪圖一時(shí)便宜，買到不合格的產(chǎn)品哦!辛辛苦苦安裝好的光伏系統(tǒng)，若是沒幾年就不發(fā)電了，咱們豈不是要賠慘了?

五、并網(wǎng)申請(qǐng)流程

知道了安裝系統(tǒng)的相關(guān)知識(shí)，我們還需要到電網(wǎng)公司進(jìn)行并網(wǎng)申請(qǐng)，保證安裝好后能夠與電網(wǎng)相連，才能拿到補(bǔ)貼和售電收益!

第一步：帶上身份證，房產(chǎn)證(土地使用證)，到當(dāng)?shù)仉娏郑?guī)模不同受理單位是不一樣的，家用系統(tǒng)到區(qū)縣電力局就可以辦理。

第二步：制訂接入系統(tǒng)方案，這一步是電網(wǎng)公司完成的，不需要你做，靜等消息吧，當(dāng)然，有些地方電網(wǎng)公司會(huì)讓你等得比較久。

第三步：確認(rèn)接入系統(tǒng)方案，這一步主要就是確認(rèn)是全額上網(wǎng)還是余電上網(wǎng)，一般來說，業(yè)主用電電價(jià)比較高且用電量較大的適合自發(fā)自用模式，否則直接選全額上網(wǎng)即可。

第四步：出具接網(wǎng)意見書，就是原則上同意接入電網(wǎng)了。

第五步：找一個(gè)有資質(zhì)的施工單位吧，參考以上的表格價(jià)格去談價(jià)吧，太低的價(jià)格可是做不出來好的系統(tǒng)的，最好是選擇正規(guī)可靠的廠家，不要貪圖一時(shí)的便宜，安裝的系統(tǒng)質(zhì)量無法保證，售后找不到人可就悲劇了哦!

六、建光伏電站

現(xiàn)在開始建電站了，首先施工方會(huì)來看場(chǎng)地，并出初步的圖紙，一般有平面圖，效果圖，工程預(yù)算等，現(xiàn)在一般選用255W-260W組件，系統(tǒng)示意圖見如下。

電氣連接示意圖

組件安裝示意圖

有經(jīng)驗(yàn)的工程隊(duì)大約只需要二個(gè)工作日即可完成施工，這個(gè)過程是非常快速的，然后，你家的屋頂上就多了一個(gè)漂亮的光伏電站啦!

七、并網(wǎng)驗(yàn)收

建成后的電站經(jīng)并網(wǎng)驗(yàn)收后加裝雙向電表，然后簽訂售電合同，你就可以合法的向電網(wǎng)輸送電力了，是不是真的很神奇?

第四篇：網(wǎng)絡(luò)存儲(chǔ)技術(shù)優(yōu)缺點(diǎn)與發(fā)展趨勢(shì)

網(wǎng)絡(luò)存儲(chǔ)技術(shù)優(yōu)缺點(diǎn)與發(fā)展趨勢(shì)

隨著不斷加速的信息需求使得存儲(chǔ)容量飛速增長(zhǎng)，存儲(chǔ)系統(tǒng)網(wǎng)絡(luò)平臺(tái)已經(jīng)成為一個(gè)核心平臺(tái)，同時(shí)各種應(yīng)用對(duì)平臺(tái)的要求也越來越高，不僅在存儲(chǔ)容量上，還包括數(shù)據(jù)訪問性能、數(shù)據(jù)傳輸性能、數(shù)據(jù)管理能力、存儲(chǔ)擴(kuò)展能力等等多個(gè)方面。可以說，存儲(chǔ)網(wǎng)絡(luò)平臺(tái)的綜合性能的優(yōu)劣，將直接影響到整個(gè)系統(tǒng)的正常運(yùn)行。因此，發(fā)展一種具有成本效益的和可管理的先進(jìn)存儲(chǔ)方式就成為必然。下面就當(dāng)前的存儲(chǔ)技術(shù)及發(fā)展趨勢(shì)進(jìn)行分析和探討。信息量的飛速發(fā)展使得存儲(chǔ)容量也飛速增長(zhǎng)，發(fā)展一種具有成本效益和可管理和先進(jìn)存儲(chǔ)方式就成為必然。本文就幾種傳統(tǒng)的網(wǎng)絡(luò)存儲(chǔ)框架進(jìn)行探討，之后介紹了新的存儲(chǔ)技術(shù)，并分析了網(wǎng)絡(luò)存儲(chǔ)體系結(jié)構(gòu)的發(fā)展趨勢(shì)。

隨著不斷加速的信息需求使得存儲(chǔ)容量飛速增長(zhǎng)，存儲(chǔ)系統(tǒng)網(wǎng)絡(luò)平臺(tái)已經(jīng)成為一個(gè)核心平臺(tái)，同時(shí)各種應(yīng)用對(duì)平臺(tái)的要求也越來越高，不僅在存儲(chǔ)容量上，還包括數(shù)據(jù)訪問性能、數(shù)據(jù)傳輸性能、數(shù)據(jù)管理能力、存儲(chǔ)擴(kuò)展能力等等多個(gè)方面。可以說，存儲(chǔ)網(wǎng)絡(luò)平臺(tái)的綜合性能的優(yōu)劣，將直接影響到整個(gè)系統(tǒng)的正常運(yùn)行。因此，發(fā)展一種具有成本效益的和可管理的先進(jìn)存儲(chǔ)方式就成為必然。下面就當(dāng)前的存儲(chǔ)技術(shù)及發(fā)展趨勢(shì)進(jìn)行分析和探討。

一、網(wǎng)絡(luò)存儲(chǔ)技術(shù)概述

所謂網(wǎng)絡(luò)存儲(chǔ)技術(shù)(Network Storage Technologies)，就是以互聯(lián)網(wǎng)為載體實(shí)現(xiàn)數(shù)據(jù)的傳輸與存儲(chǔ)，數(shù)據(jù)可以在遠(yuǎn)程的專用存儲(chǔ)設(shè)備上，也可以是通過服務(wù)器來進(jìn)行存儲(chǔ)。網(wǎng)絡(luò)存儲(chǔ)技術(shù)是基于數(shù)據(jù)存儲(chǔ)的一種通用網(wǎng)絡(luò)術(shù)語。實(shí)際上，我們可以將存儲(chǔ)技術(shù)分為三個(gè)階段：①總線存儲(chǔ)階段；②存儲(chǔ)網(wǎng)絡(luò)階段；③虛擬存儲(chǔ)階段。以存儲(chǔ)網(wǎng)絡(luò)為中心的存儲(chǔ)是對(duì)數(shù)據(jù)存儲(chǔ)新需求的回答。它采用面向網(wǎng)絡(luò)的存儲(chǔ)體系結(jié)構(gòu)，使數(shù)據(jù)處理和數(shù)據(jù)存儲(chǔ)分離；網(wǎng)絡(luò)存儲(chǔ)體系結(jié)構(gòu)包括了網(wǎng)絡(luò)和I/O的精華，將I/O能力擴(kuò)展到網(wǎng)絡(luò)上，特別是靈活的網(wǎng)絡(luò)尋址能力，遠(yuǎn)距離數(shù)據(jù)傳輸能力，I/O高效的原性能；通過網(wǎng)絡(luò)連接服務(wù)器和存儲(chǔ)資源，消除了不同存儲(chǔ)設(shè)備和服務(wù)器之間的連接障礙；提高了數(shù)據(jù)的共享性、可用性和可擴(kuò)展性、管理性。

二、幾種傳統(tǒng)的網(wǎng)絡(luò)存儲(chǔ)架構(gòu)

網(wǎng)絡(luò)存儲(chǔ)架構(gòu)大致分為三種：直連附加存儲(chǔ)、網(wǎng)絡(luò)附加存儲(chǔ)、存儲(chǔ)區(qū)域網(wǎng)絡(luò)。這幾種網(wǎng)絡(luò)存儲(chǔ)方式特點(diǎn)各異，應(yīng)用在不同的領(lǐng)域。下面我們來做簡(jiǎn)單的介紹并分析其中區(qū)別。

2.1 直連附加存儲(chǔ)(DAS：Direct Attached Storage)

直接網(wǎng)絡(luò)存儲(chǔ)(DAS)是指將存儲(chǔ)設(shè)備通過SCSI接口或光纖通道直接連接到服務(wù)器上的方式。這種連接方式主要應(yīng)用于單機(jī)或兩臺(tái)主機(jī)的集群環(huán)境中，主要優(yōu)點(diǎn)是存儲(chǔ)容量擴(kuò)展的實(shí)施簡(jiǎn)單，投入成本少，見效快。DAS主要應(yīng)用于：

①服務(wù)器在地理分布上很分散，SAN或NAS在它們之間進(jìn)行互連非常困難時(shí)；

②存儲(chǔ)系統(tǒng)必須被直接連接到應(yīng)用服務(wù)器時(shí)；

③包括許多數(shù)據(jù)庫(kù)應(yīng)用和應(yīng)用服務(wù)器在內(nèi)的應(yīng)用時(shí)。

缺點(diǎn)：

①不能提供跨平臺(tái)的文件共享功能；

②用戶要備份數(shù)據(jù)和存儲(chǔ)數(shù)據(jù)，都要占用服務(wù)器CPU的時(shí)間，降低了服務(wù)器的管理效能；

③由于各個(gè)主機(jī)之間的數(shù)據(jù)獨(dú)立，數(shù)據(jù)需要逐一備份，使數(shù)據(jù)備份工作較為困難；

④隨著服務(wù)器的增多，數(shù)據(jù)管理會(huì)越來越復(fù)雜；增加存儲(chǔ)設(shè)備，擴(kuò)展存儲(chǔ)容量，需要對(duì)服務(wù)器進(jìn)行重新配置，這樣做容易中斷單位的業(yè)務(wù)連接性，造成數(shù)據(jù)丟失。

2.2 網(wǎng)絡(luò)附加存儲(chǔ)(NAS：Network Attached Storage)

網(wǎng)絡(luò)附加存儲(chǔ)(NAS)是一種將分布、獨(dú)立的數(shù)據(jù)整合為大型、集中化管理的數(shù)據(jù)中心，以便于對(duì)不同主機(jī)和應(yīng)用服務(wù)器進(jìn)行訪問的技術(shù)。NAS中服務(wù)器與存儲(chǔ)之間的通信使用TCP/IP協(xié)議，數(shù)據(jù)處理是“文件級(jí)”。NAS可附加大容量的存儲(chǔ)內(nèi)嵌操作系統(tǒng)，專門針對(duì)文件系統(tǒng)進(jìn)行重新設(shè)計(jì)和優(yōu)化以提供高效率的文件服務(wù)，降低了存儲(chǔ)設(shè)備的成本，數(shù)據(jù)傳輸速率也很高。

NAS應(yīng)用于電子出版、CAD、圖像、教育、銀行、政府、法律環(huán)境等那些對(duì)數(shù)據(jù)量有較大需求的應(yīng)用中。多媒體、Internet下載以及在線數(shù)據(jù)的增長(zhǎng)，特別是那些要求存儲(chǔ)器能隨著公司文件大小規(guī)模而增長(zhǎng)的企業(yè)、小型公司、大型組織的部門網(wǎng)絡(luò)，更需要這樣一個(gè)簡(jiǎn)單的可擴(kuò)展的方案。

缺點(diǎn)：

①NAS采用File I/O方式，因此當(dāng)客戶端數(shù)目或來自客戶端的請(qǐng)求較多時(shí)，NAS服務(wù)器仍將成為系統(tǒng)的瓶頸；

②進(jìn)行數(shù)據(jù)備份時(shí)需要占用LAN的帶寬，造成資源浪費(fèi)；

③NAS只能對(duì)單個(gè)存儲(chǔ)(單個(gè)NAS內(nèi)部)設(shè)備中的磁盤進(jìn)行資源整合，目前還無法跨越不同的NAS設(shè)備，只能進(jìn)行單獨(dú)管理，不適合密集型大規(guī)模的數(shù)據(jù)傳輸。

2.3 存儲(chǔ)區(qū)域網(wǎng)絡(luò)(SAN：Storage Area Network)

SAN(Storage Area Network，存儲(chǔ)區(qū)域網(wǎng))，通常SAN由RAID陣列連接光纖通道(Fibre Channel)組成，SAN和服務(wù)器以及客戶機(jī)的數(shù)據(jù)通信通過SCSI命令而非TCP/IP，數(shù)據(jù)處理是“塊級(jí)”。

應(yīng)用：

①數(shù)據(jù)共享由于存儲(chǔ)設(shè)備的中心化，大量的文件服務(wù)器可以低成本的存取和共享信息，同時(shí)也不會(huì)使系統(tǒng)性能有明顯下降；

②存儲(chǔ)共享兩個(gè)或多個(gè)服務(wù)器可以共享一個(gè)存儲(chǔ)單元，這個(gè)存儲(chǔ)單元在物理上可以被分成多個(gè)部分，而每個(gè)部分又連接在特定的服務(wù)器上；

③數(shù)據(jù)備份通過使用SAN，這些操作可以獨(dú)立于原來的網(wǎng)絡(luò)，從而能夠提高操作的性能；

④災(zāi)難恢復(fù)傳統(tǒng)方法，當(dāng)災(zāi)難發(fā)生時(shí)，使用磁帶實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。通過使用SAN，可采用多種手段實(shí)現(xiàn)數(shù)據(jù)的自動(dòng)備份，而且這種備份是熱備份形式，也就是說，一旦數(shù)據(jù)出錯(cuò)，立即可以獲得該數(shù)據(jù)的鏡像內(nèi)容。

三、新的網(wǎng)絡(luò)存儲(chǔ)技術(shù)IP—SAN

網(wǎng)絡(luò)存儲(chǔ)的發(fā)展產(chǎn)生了一種新技術(shù)IP—SANt。IP—SAN是以IP為基礎(chǔ)的SAN存儲(chǔ)方案，是IP存儲(chǔ)技術(shù)應(yīng)用的第三階段，是完全的端到端的、基于IP的全球SAN存儲(chǔ)。它充分利用了IP網(wǎng)絡(luò)的技術(shù)成熟、性能穩(wěn)定、傳輸距離遠(yuǎn)、安裝實(shí)施簡(jiǎn)單、后期維護(hù)量少的特點(diǎn)，可為用戶提供一個(gè)運(yùn)行穩(wěn)定、實(shí)施簡(jiǎn)單方便、價(jià)格低廉的大容量存儲(chǔ)系統(tǒng)，是一種可共同使用SAN與NAS，并遵循各項(xiàng)標(biāo)準(zhǔn)的純軟件解決方案。IP—SAN可讓用戶同時(shí)使用GigabitEtherne SCSI與Fibre Channel，建立以IP為基礎(chǔ)的網(wǎng)絡(luò)存儲(chǔ)基本架構(gòu)，由于IP在局域網(wǎng)和廣域網(wǎng)上的應(yīng)用以及良好的技術(shù)支持，在IP網(wǎng)絡(luò)中也可實(shí)現(xiàn)遠(yuǎn)距離的塊級(jí)存儲(chǔ)，以IP協(xié)議替代光纖通道協(xié)議，IP協(xié)議用于網(wǎng)絡(luò)中實(shí)現(xiàn)用戶和服務(wù)器連接，隨著用于執(zhí)行1P協(xié)議的計(jì)算機(jī)的速度的提高及G比特的以太網(wǎng)的出現(xiàn)，基于IP協(xié)議的存儲(chǔ)網(wǎng)絡(luò)實(shí)現(xiàn)方案成為SAN的更佳選擇。

四、虛擬存儲(chǔ)

所謂虛擬存儲(chǔ)，就是把內(nèi)存與外存有機(jī)的結(jié)合起來使用，從而得到一個(gè)容量很大的“內(nèi)存”。以存儲(chǔ)網(wǎng)絡(luò)為中心的存儲(chǔ)解決不了全部的數(shù)據(jù)存儲(chǔ)問題，如存儲(chǔ)資源共享、數(shù)據(jù)共享、數(shù)據(jù)融合等。不少先進(jìn)存儲(chǔ)系統(tǒng)的倡導(dǎo)者都提出，存儲(chǔ)作為一種資源，應(yīng)該像我們?nèi)粘Ｉ钪械淖詠硭碗娏σ粯樱S時(shí)可以方便的存取和使用，這就是存儲(chǔ)公用設(shè)施模型，也是網(wǎng)絡(luò)存儲(chǔ)的發(fā)展目標(biāo)。實(shí)現(xiàn)存儲(chǔ)公用設(shè)施模型的關(guān)鍵就是在網(wǎng)絡(luò)存儲(chǔ)基礎(chǔ)上實(shí)現(xiàn)統(tǒng)一虛擬存儲(chǔ)系統(tǒng)。目前存儲(chǔ)技術(shù)還處于存儲(chǔ)網(wǎng)絡(luò)階段，虛擬存儲(chǔ)才剛剛起步。

五、云存儲(chǔ)

云存儲(chǔ)是在云計(jì)算(Cloud computing)概念上延伸和發(fā)展出來的一個(gè)新的概念。云計(jì)算是是分布式處理(Distributed Computing)、并行處理(Parallel Computing)和網(wǎng)格計(jì)算(Grid Computing)的發(fā)展，是透過網(wǎng)絡(luò)將龐大的計(jì)算處理程序自動(dòng)分拆成無數(shù)個(gè)較小的子程序，再交由多部服務(wù)器所組成的龐大系統(tǒng)經(jīng)計(jì)算分析之后將處理結(jié)果回傳給用戶。

云存儲(chǔ)的概念與云計(jì)算類似，它是指通過集群應(yīng)用、網(wǎng)格技術(shù)或分布式文件系統(tǒng)等功能，將網(wǎng)絡(luò)中大量各種不同類型的存儲(chǔ)設(shè)備通過應(yīng)用軟件集合起來協(xié)同工作，共同對(duì)外提供數(shù)據(jù)存儲(chǔ)和業(yè)務(wù)訪問功能的一個(gè)系統(tǒng)。云存儲(chǔ)的核心是應(yīng)用軟件與存儲(chǔ)設(shè)備相結(jié)合，通過應(yīng)用軟件來實(shí)現(xiàn)存儲(chǔ)設(shè)備向存儲(chǔ)服務(wù)的轉(zhuǎn)變。

云存儲(chǔ)對(duì)使用者來講，不是指某一個(gè)具體的設(shè)備，而是指一個(gè)由許許多多個(gè)存儲(chǔ)設(shè)備和服務(wù)器所構(gòu)成的集合體。用戶使用云存儲(chǔ)，并不是使用某一個(gè)存儲(chǔ)設(shè)備，而是使用整個(gè)云存儲(chǔ)系統(tǒng)帶來的一種數(shù)據(jù)訪問服務(wù)。所以嚴(yán)格來講，云存儲(chǔ)不是存儲(chǔ)，而是一種服務(wù)。

六、結(jié)束語

數(shù)據(jù)的重要性越來越得到人們的廣泛認(rèn)同，未來網(wǎng)絡(luò)的核心將是數(shù)據(jù)，網(wǎng)絡(luò)化存儲(chǔ)正是數(shù)據(jù)存儲(chǔ)的一個(gè)發(fā)展方向。目前網(wǎng)絡(luò)存儲(chǔ)技術(shù)沿著三個(gè)主要的方向發(fā)展：NAS、SAN、IP—SAN。而SAN和NAS的融合將更有利于數(shù)據(jù)的存儲(chǔ)和備份，因此，SAN和NAS的融合、統(tǒng)一虛擬存儲(chǔ)技術(shù)是未來網(wǎng)絡(luò)存儲(chǔ)技術(shù)發(fā)展的兩個(gè)趨勢(shì)。

第五篇：APEC領(lǐng)導(dǎo)人服裝全揭秘范文

APEC領(lǐng)導(dǎo)人服裝全揭秘

2014年APEC領(lǐng)導(dǎo)人歡迎宴會(huì)在北京國(guó)家游泳中心“水立方”舉行。參加會(huì)議的各成員經(jīng)濟(jì)體領(lǐng)導(dǎo)人身著中國(guó)特色服裝抵達(dá)現(xiàn)場(chǎng)時(shí)，受到隆重?zé)崃业臍g迎。領(lǐng)導(dǎo)人拍攝了一張具有濃郁中國(guó)特色的亞太大家庭“全家福”照片。

據(jù)APEC領(lǐng)導(dǎo)人服裝工作團(tuán)隊(duì)人員介紹，為領(lǐng)導(dǎo)人制作特色中式服裝，雖然大多數(shù)都是按照其提供的尺寸，但有一些國(guó)家領(lǐng)導(dǎo)人的尺寸無法直接取得。設(shè)計(jì)師們開動(dòng)腦筋，根據(jù)人體工程學(xué)，再加上多年的裁衣經(jīng)驗(yàn)，從領(lǐng)導(dǎo)人公開露面的新聞圖片中“目測(cè)”尺寸。從實(shí)際效果來看，設(shè)計(jì)師們的“眼光”都很準(zhǔn)，令人嘆服。

為照顧領(lǐng)導(dǎo)人不同體型，采用中西結(jié)合的剪裁方式，表達(dá)中國(guó)意韻的同時(shí)更為合體、舒適。領(lǐng)導(dǎo)人穿在身上，透出的是一種圓融大氣，溫潤(rùn)儒雅的氣質(zhì)。

此次的APEC領(lǐng)導(dǎo)人服裝是一系列展示中國(guó)人新形象的中式服裝，其根為“中”，其魂為“禮”，其形為“新”，合此三者，謂之“新中裝”。

女領(lǐng)導(dǎo)人服裝為立領(lǐng)、對(duì)襟、連肩袖，雙宮緞面料、飾海水江崖紋外套。

為與會(huì)領(lǐng)導(dǎo)人及配偶提供了多種款式和顏色供自由選擇。其中，男領(lǐng)導(dǎo)人一款四式五色，女領(lǐng)導(dǎo)人一款兩色，女配偶外套及內(nèi)搭各四款四色。

APEC領(lǐng)導(dǎo)人服裝面料織造團(tuán)隊(duì)負(fù)責(zé)人吳建華介紹，近代以來，由于工藝復(fù)雜，產(chǎn)量較低，宋錦多為書畫裝潢使用，一般不作為衣料。但與蜀錦、云錦相比，宋錦質(zhì)地堅(jiān)柔，平服挺括，圖紋豐富而流暢生動(dòng)，色彩艷而不火，繁而不亂，富有明麗古雅的韻味。2009年，宋錦被列入世界非物質(zhì)遺產(chǎn)，逐漸走向全球。但是，領(lǐng)導(dǎo)人把宋錦這一“非遺”穿在身上，而且是在APEC這樣的舞臺(tái)上盛裝亮相，是宋錦的第一次，也是中國(guó)給APEC和世界帶來的一份驚喜。