Spanner能夠在遠(yuǎn)地域數(shù)據(jù)分布的情況下，實現(xiàn)分布式事務(wù)。

成都創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供鼎城網(wǎng)站建設(shè)、鼎城做網(wǎng)站、鼎城網(wǎng)站設(shè)計、鼎城網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、鼎城企業(yè)網(wǎng)站模板建站服務(wù)，十余年鼎城做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

首先是分布式事務(wù)，那么必然引入了二階段提交的機制，同時為了避免二階段提交機制中的短板，事務(wù)協(xié)調(diào)器崩潰導(dǎo)致參與者長時間阻塞占用鎖的問題，spanner給事務(wù)協(xié)調(diào)器使用的paxos來提高可用性。但是，二階段提交機制下的事務(wù)的處理性能存在巨大的問題，paper中提及到google的廣告系統(tǒng)使用的數(shù)據(jù)庫為參考，各種事務(wù)的占比中，只讀型事務(wù)的數(shù)量有數(shù)十億，而讀寫型事務(wù)卻僅有數(shù)百萬，關(guān)鍵在于提高只讀型事務(wù)的性能。因此，spanner通過同步時鐘來實現(xiàn)了只讀事務(wù)的高效執(zhí)行。

由于數(shù)據(jù)劃分到多個服務(wù)器上進(jìn)行分片，谷歌的數(shù)據(jù)中心遍布全球，自然這些服務(wù)器也遍布美國，每份數(shù)據(jù)都會在多個數(shù)據(jù)中心進(jìn)行復(fù)制，這種冗余復(fù)制自然就是使用paxos來實現(xiàn)。為了讓只讀事務(wù)的高效處理，客戶端每次向服務(wù)器請求數(shù)據(jù)時，都將選擇距離自己最近的服務(wù)器請求，這有效降低地域距離帶來的延遲，而非向leader請求，同時，這也使得冗余復(fù)制的那幾個服務(wù)器將可以并行對只讀事務(wù)處理，大大提高只讀事務(wù)的性能，降低leader的負(fù)擔(dān)。但是，數(shù)據(jù)的最新版本由leader同步給follower，存在少數(shù)replica的數(shù)據(jù)落后的情況，讓客戶端如讀取當(dāng)?shù)氐膔eplica中的數(shù)據(jù)來提高速度的情況下，有可能客戶端會讀取到過時的數(shù)據(jù)。因此，需要外部一致性，確保每次讀操作都能看到最新的數(shù)據(jù)。

簡單來說，就是spanner針對占少數(shù)的讀寫型事務(wù)，側(cè)重于避免事故帶來的性能問題。spanner要求讀寫型事務(wù)通過二階段提交來保證分布式上的原子提交，以及其中的二階段鎖也是確保了讀寫型事務(wù)間的隔離性，但是spanner用paxos解決了二階段提交中的事務(wù)協(xié)調(diào)器崩潰阻塞的問題，后續(xù)將講解如何引入paxos并進(jìn)行結(jié)合。

spannere針對只讀型事務(wù)，側(cè)重于提高事務(wù)的執(zhí)行性能，要求這些事務(wù)能夠就近讀取本地數(shù)據(jù)中心的數(shù)據(jù)，并要求這個過程是外部一致性的。后續(xù)將優(yōu)化只讀事務(wù)將其和二階段提交機制解綁，其中的隔離性和外部一致性都通過引入快照隔離機制和安全時間機制來保證，同時快照隔離機制需要時鐘的同步，時鐘同步是難以保證的，這將引入start rule、commit wait機制來解決時鐘同步的問題。

針對讀寫型事務(wù)的優(yōu)化

spanner使用場景下，數(shù)據(jù)被分片到不同服務(wù)器中，每份數(shù)據(jù)也通過paxos冗余復(fù)制到多臺服務(wù)器上。下面通過一個例子來講解：

一個讀寫型事務(wù)，一個銀行的轉(zhuǎn)賬事務(wù)，賬戶Y轉(zhuǎn)賬給賬戶X一塊錢，X賬戶的數(shù)據(jù)和Y賬戶的數(shù)據(jù)分別保存在不同的服務(wù)器上，但是這些數(shù)據(jù)都會經(jīng)過復(fù)制到多臺服務(wù)器上。

服務(wù)器2號為X數(shù)據(jù)所屬分片的leader，服務(wù)器1號為Y數(shù)據(jù)所屬分片的leader

這個轉(zhuǎn)賬事務(wù)的步驟為先讀取x和y的值，后續(xù)再對x和y進(jìn)行修改值

客戶端先向leader發(fā)起一個DC2和DC1發(fā)起GET讀取數(shù)據(jù)的請求，此時這兩個leader也會分別對x和y數(shù)據(jù)上一個讀鎖

客戶端后續(xù)在本地進(jìn)行計算，得出更新的值，向DC2和DC1發(fā)起PUT更新數(shù)據(jù)的請求。由于需要進(jìn)行原子性提交，因此需要事務(wù)協(xié)調(diào)器，客戶端從與本事務(wù)相關(guān)的那些分片的leader中選擇一臺服務(wù)器作為事務(wù)協(xié)調(diào)器。被選中的服務(wù)器作為事務(wù)協(xié)調(diào)器，因為本身作為leader有follower進(jìn)行復(fù)制數(shù)據(jù)，因此即使發(fā)生了崩潰，follower也會立刻頂替變?yōu)閘eader，同時也會接替事務(wù)協(xié)調(diào)器的工作。

本次客戶端將DC1作為事務(wù)協(xié)調(diào)器，此時DC1不僅作為paxos中的一個leader，還作為當(dāng)前事務(wù)的事務(wù)協(xié)調(diào)器，并將該paxos組的id發(fā)送出去。

后續(xù)客戶端將PUT請求，將更新的值發(fā)送給X和Y的leader

X和Y的leader接受到PUT請求后，就會立刻進(jìn)行l(wèi)og replication，將prepare消息同步到日志中。當(dāng)log replicaition到大多數(shù)節(jié)點后，leader即可確保該事務(wù)能夠不受故障影響，確保被執(zhí)行，便可回復(fù)yes給事務(wù)協(xié)調(diào)器，而DC1本身作為事務(wù)協(xié)調(diào)器，就是發(fā)送給自身一個yes回復(fù)。

此外客戶端也會給DC1發(fā)送一個yes回復(fù)，因為DC1作為事務(wù)協(xié)調(diào)器。

當(dāng)事務(wù)協(xié)調(diào)器收到了全部的yes回復(fù)后，即可進(jìn)行commit該事務(wù)，但是事務(wù)協(xié)調(diào)器會先將該commit消息在本paxos組中進(jìn)行l(wèi)og replication，后續(xù)再發(fā)送commit消息給其他參與者。我們需要確保事務(wù)協(xié)調(diào)器不會忘記它所做的決定。當(dāng)這些commit消息被提交到了不同的shard paxos的日志中后，每個shard即可執(zhí)行這些寫操作，并將數(shù)據(jù)寫入，并釋放鎖。

可以看到讀寫型事務(wù)涉及到大量的跨數(shù)據(jù)中心溝通，而谷歌的數(shù)據(jù)中心分布在全球各地，較遠(yuǎn)的數(shù)據(jù)中心的消息來往溝通會耗費大量的時間，因此這一個事務(wù)的執(zhí)行開銷一般就會比較大。但是數(shù)據(jù)被大量分片，因此只要事務(wù)之間沒有數(shù)據(jù)沖突的存在，那么就可以并行執(zhí)行大量的無沖突事務(wù)，這樣也彌補了性能的問題，但是單個讀寫型事務(wù)的延遲還是沒法解決的，因此一般來說spanner方案下，所有的replica一般也都是放在同個城市內(nèi)或者是跨鎮(zhèn)的，paper中也展示了鄰近的數(shù)據(jù)中心完成事務(wù)的執(zhí)行時間僅需14毫秒左右。這個性能湊活，但還是十分慢。

性能優(yōu)化這塊，spanner針對占據(jù)事務(wù)比例絕大多數(shù)的只讀型事務(wù)進(jìn)行了特別的優(yōu)化，大大提高了處理速度。

針對只讀型事務(wù)的優(yōu)化

spanner對只讀型事務(wù)，消除了兩個會帶來巨大開銷的問題。

1、消除了客戶端和數(shù)據(jù)中心的遠(yuǎn)距離帶來的通信延遲，spanner使得客戶端僅需向本地數(shù)據(jù)中心讀取數(shù)據(jù)即可；

2、只讀事務(wù)執(zhí)行過程中，無需使用二階段提交機制和二階段鎖，從而避免了繁雜的跨數(shù)據(jù)中心的網(wǎng)絡(luò)通信溝通，以及避免了占用鎖對讀寫型事務(wù)造成處理速度上的影響。

從paper中的結(jié)果可以看到，這使得只讀事務(wù)的延遲相比讀寫型事務(wù)快了10倍多。

由于只讀事務(wù)并不會對數(shù)據(jù)進(jìn)行修改，因此無需要求它和讀寫型事務(wù)一樣遵守嚴(yán)格的有序性。

只讀型事務(wù)的正確執(zhí)行有兩個約束：

1、只讀型事務(wù)和讀寫型事務(wù)并行執(zhí)行的執(zhí)行結(jié)果必須是有序、線性一致性的，即執(zhí)行的結(jié)果就和事務(wù)有序執(zhí)行的結(jié)果一樣，即只讀型事務(wù)能夠看到在該事務(wù)之前的讀寫型事務(wù)的結(jié)果，但不能看到后續(xù)讀寫型事務(wù)的結(jié)果。例如，一個只讀型事務(wù)夾在兩個讀寫型事務(wù)之間，這個只讀事務(wù)應(yīng)該能夠看到第一個讀寫型事務(wù)的結(jié)果，但不應(yīng)該看到第二讀寫型事務(wù)的執(zhí)行結(jié)果，由于只讀型事務(wù)并不會占據(jù)鎖，因此有可能第二個讀寫型事務(wù)雖然開始比只讀型事務(wù)慢，但是并行執(zhí)行下，有可能第二個讀寫型事務(wù)反而先完成執(zhí)行，此時，需要確保只讀型事務(wù)讀取不到第二個讀寫型事務(wù)的結(jié)果。

如圖所示的情況下，T1和T2為讀寫型事務(wù)，T3為只讀型事務(wù)，如果不采取措施，那么T3事務(wù)讀取返回的結(jié)果為，x為T1事務(wù)修改的結(jié)果，而y為T2事務(wù)修改的結(jié)果，然而正確的返回結(jié)果應(yīng)該讀取T1事務(wù)修改的x、y值。

2、外部一致性，要求一個只讀事務(wù)能夠看到正確的最新版本的數(shù)據(jù)，需要避免只讀事務(wù)看到的是過時的數(shù)據(jù)。

快照隔離(Snapshot Isolation)

該機制建立在所有的機器都有一個同步的時鐘的前提條件下，每個機器根據(jù)這個同步時鐘給每個事務(wù)都分配了一個時間戳。

讀寫型事務(wù)的時間戳就是提交的時間，只讀型事務(wù)的時間戳就是事務(wù)開始的時間

所有的事務(wù)的執(zhí)行順序應(yīng)該嚴(yán)格按照這個時間戳的順序來執(zhí)行，因此，如果每臺服務(wù)器能夠按照遵守時間戳，并給出時間戳順序的執(zhí)行結(jié)果，那就是正確的。

每個replica在處理讀寫型事務(wù)時，進(jìn)行數(shù)據(jù)保存時，都應(yīng)該保存了該數(shù)據(jù)的多個版本，這個版本是以時間戳來標(biāo)識。

因此，只讀事務(wù)在進(jìn)行處理時，即便碰到了上面圖片的問題，T1事務(wù)提交時間假設(shè)為10，T3只讀事務(wù)的開始時間假設(shè)為15，T2事務(wù)的提交時間為20，但是T3事務(wù)執(zhí)行Ry操作的時間為21，在21這個時間，T3事務(wù)在讀取y的數(shù)值時，看到有時間戳為10和20兩個版本的結(jié)果，根據(jù)T3事務(wù)的時間戳為15，會讀取時間戳為10的那個版本的數(shù)值并返回。

只讀型事務(wù)被發(fā)起的時候，應(yīng)該提前攜帶一個時間戳，此時這個只讀事務(wù)執(zhí)行的時候，應(yīng)該去找在這個時間戳之前的最新的數(shù)據(jù)。

可見圖中，事務(wù)的執(zhí)行順序為T1、T3、T2，但是T2和T3的事務(wù)是并發(fā)執(zhí)行，在T3執(zhí)行的時候甚至已經(jīng)可以看到最新版本的數(shù)據(jù)，但是依舊返回舊的數(shù)據(jù)，這樣是否合理呢？

合理的，因為兩個事物的并發(fā)執(zhí)行，那么數(shù)據(jù)庫可以允許這兩個事務(wù)以任意的順序執(zhí)行，只要是結(jié)果是有序執(zhí)行的結(jié)果即可，要么返回T3、T2順序的結(jié)果，要么返回T2、T3順序的結(jié)果，但是Spanner的機制下，需要嚴(yán)格按照時間戳來執(zhí)行，因此返回T3、T2順序的執(zhí)行結(jié)果。

可見，Spanner使用快照隔離能夠成功解決了只讀型事務(wù)在沒有鎖協(xié)調(diào)下，和讀寫型事務(wù)達(dá)成有序執(zhí)行，但是還是無法實現(xiàn)外部一致性。

此外，快照隔離需要記錄多個版本的數(shù)據(jù)，這會給磁盤和內(nèi)存帶來額外的開銷，但是存儲成本并不昂貴，同時這些多版本的數(shù)據(jù)，我們僅需保存近期的版本數(shù)據(jù)即可，超過一定時間范圍的記錄均可丟棄，因此這其實也不算是一個特別的問題。

安全時間（Safe Time)

快照隔離機制能夠保證事務(wù)的有序執(zhí)行，但是還是無法解決外部一致性的問題，有可能發(fā)起的只讀事務(wù)到達(dá)本地的replica時，這個replica處于落后狀態(tài)，還沒同步到最新的讀寫型事務(wù)的提交，那么這個只讀事務(wù)無法讀取到該事務(wù)時間戳前的最新版本的數(shù)據(jù)。

針對上面的問題，Spanner提出了安全時間機制，由于Leader會嚴(yán)格按照Log Index的順序給follower進(jìn)行l(wèi)og replication并進(jìn)行提交，因此日志中的事務(wù)按照Index來看，時間戳也是嚴(yán)格遞增的。follower收到時間戳為15的事務(wù)的提交，那么表明時間戳15之前的事務(wù)都已經(jīng)接受完畢。

因此，當(dāng)本地replica收到一個時間戳為15的只讀型事務(wù)，但是本地只從leader處拿到了時間戳為13的事務(wù)的日志，那么本地的replica就會推遲回復(fù)這個只讀事務(wù)，直到它從leader處拿到了時間戳大于或等于15的事務(wù)日志。當(dāng)然這會帶來一點小延遲。

時鐘同步問題的解決

在只讀型事務(wù)的優(yōu)化中，提出的快照隔離和安全時間機制發(fā)揮作用的前提都是所有機器的時鐘都是同步的，但是在分布式系統(tǒng)中，想要實現(xiàn)所有機器的時鐘完美同步是不可能的。

時間是由政府實驗室里的那些價格昂貴的高精度時鐘定義，我們只能從那兒獲取時間，而獲取這些時間的數(shù)值需要通過一定途徑傳輸獲取，但是這個數(shù)據(jù)傳輸?shù)倪^程必然需要花費一定的時間，并且這個傳輸過程的延遲對于不同服務(wù)器也是不同的。

對于讀寫型事務(wù)而言，這類事務(wù)采用了二階段鎖和二階段提交機制，根本無需時鐘同步來解決什么問題。

因此，我們這里需要針對只讀型事務(wù)來考慮，因為時間戳?xí)r為了優(yōu)化只讀型事務(wù)才引入的。

時鐘不同步會發(fā)生的兩種情況

如果只讀型事務(wù)碰到時鐘不同步的情況會發(fā)生什么，我們需要設(shè)想以下兩種情況。

1、時鐘不同步導(dǎo)致只讀型事務(wù)上攜帶的時間戳大于實際時間，那么replica收到這個只讀事務(wù)后就會因為安全時間機制等待leader發(fā)來的事務(wù)的時間戳趕上這個只讀事務(wù)的時間戳。這種情況看起來不算特別糟糕，頂多就是需要等待一段時間，但是返回的結(jié)果是正確的。但是如果只讀型事務(wù)的時間戳偏差大到離譜的時候，那么就可能會發(fā)生等待超時的情況，當(dāng)然服務(wù)器會定期獲取高精度時間，不至于會有這么大的偏差。

2、時鐘不同步導(dǎo)致只讀型事務(wù)上攜帶的時間戳小于實際時間，此時就會違反正確性，因為本地的replica根據(jù)這個過小的時間戳?xí)祷匾粋€過時版本的數(shù)據(jù)，并且時鐘不同步的偏差越大，只讀事務(wù)的時間戳越小，那么返回的數(shù)據(jù)的版本就越老。這顯然是違反了之前講的外部一致性，因此，我們需要針對只讀型事務(wù)被分配比真實時間要小的時間戳的情況下的外部一致性問題。

顯然，如果時鐘不完美同步的話，那么spanner的只讀型事務(wù)將會發(fā)生錯誤。后續(xù)講解為什么不能完美同步，以及如何解決這個問題。

時間是由政府的實驗室中的高精度時鐘來決定的，這個時間的數(shù)值的廣播也是需要使用特定的協(xié)議，例如雷達(dá)協(xié)議（Spanner中GPS就是扮演雷達(dá)廣播的角色，接受高精度時鐘的正確時間然后通過GPS衛(wèi)星發(fā)送給google機房中的GPS接收器），還有一些比較新的協(xié)議NTP協(xié)議（基于網(wǎng)絡(luò)的一個時間協(xié)議）

如圖演示了服務(wù)器獲取時間的原理圖，UTC是指政府實驗室中定義的高精度時間，政府實驗室通過GPS衛(wèi)星將時間進(jìn)行廣播給GPS接收器。每個數(shù)據(jù)中心都會有一個GPS接收器，它可以對GPS信號中的時間戳進(jìn)行解密并修正各種傳播延遲帶來的偏差，讓時間值保持是正確的，但是這個誤差的修正顯然不是絕對準(zhǔn)確的，修正后的時間和真實的時間還是存在微小的偏差。這個GPS接收器會和數(shù)據(jù)中心中的time master進(jìn)行連接，由于整個數(shù)據(jù)中心的時間戳都由這time master來決定，避免唯一故障點發(fā)生故障的嚴(yán)重事故，time master也將會有多個存在，提高可用性。

每個數(shù)據(jù)中心的數(shù)百臺服務(wù)器，部分作為spanner server，部分作為spanner client，它們都會定期向這些time master獲取正確的時間，這里spanner機器和time master的交互也會讓引入新的時間誤差，time master在獲取時間值后回復(fù)給spanner機器，回復(fù)過程是存在延遲的，這個延遲相比上面的延遲是巨大的。因此，誤差始終存在，始終是無法獲取絕對精準(zhǔn)的時間，這些誤差都是毫秒級的，是十分嚴(yán)重的。

此外，spanner機器是每隔一定時間向time master獲取正確的時間，但是間隔期間的時間值是通過本地時鐘來計算時間，這種方式帶來的結(jié)果也是十分糟糕，誤差很大。

True Time方案

因此，時間的不準(zhǔn)確性是必然存在的，如果解決這個問題，Spanner使用了True Time方案。當(dāng)機器向time master詢問時間時，并不會返回一個時間值，而是返回一直TT區(qū)間的值，這個區(qū)間由一個earliest time和latest time組成，精準(zhǔn)的時間必然處在這個TT區(qū)間內(nèi)。

上面，我們提及到的只讀型事務(wù)被分配偏小的時間戳導(dǎo)致外部一致性被破壞的問題，通過兩條規(guī)則來解決了，分別為Start Rule和Commit Wait Rule。

Start Rule：為事務(wù)分配時間戳就是返回的TT區(qū)間中的latest time來賦值，用TT.now().latest賦值，這確保事務(wù)被賦值的時間戳是比真實的時間要大一些。對于只讀型事務(wù)而言，時間戳應(yīng)該在開始的時候就賦予；對于讀寫型事務(wù)而言，時間戳應(yīng)該在提交的時候再賦予。

Commit Wait Rule：這個規(guī)則只針對于讀寫型事務(wù)，由于事務(wù)被分配的時間戳為TT區(qū)間中的latest，實際是要大于真實時間的，后續(xù)則需要等待真實時間大于這個時間戳后才能提交該讀寫型事務(wù)。這確保了讀寫型事務(wù)被提交的那個時間的數(shù)值是比被分配的時間戳要大。

后續(xù)的等待如何判斷真實時間已經(jīng)大于這個時間戳了

服務(wù)器僅需循環(huán)調(diào)用TT.now()獲取真實時間的情況，當(dāng)獲取的TT區(qū)間的earliest time都大于這個時間戳了，表明真實時間必然已經(jīng)大于這個時間戳了。

我們需要解決的情況是，只讀型事務(wù)被分配了相對于真實時間較小的時間戳，導(dǎo)致了只讀型事務(wù)讀取到的數(shù)據(jù)是過時的。而只讀型事務(wù)被分配相對于真實時間較大的時間戳的情況，僅需等待一段時間，仍然會返回新版本的數(shù)據(jù)。因此，我們需要避免只讀型事務(wù)被分配較小的時間戳。

Start Rule確保每個事務(wù)被分配的時間戳相對于真實時間都是偏大的，這確保只讀型事務(wù)被分配了較大的時間戳。

但是Start Rule也使得讀寫型事務(wù)也被分配了較大的時間戳，因此Commit Wait Rule發(fā)揮了作用，它使得讀寫型事務(wù)即使被分配了時間戳也不能提交，需要等待一段時間，確保真實時間大于這個時間戳后再提交，這使得讀寫型事務(wù)的時間戳是小于提交時的真實時間，實際上是被分配了一個相對于真實時間較小的值。

讀寫型事務(wù)被分配相對于真實時間較小的時間戳，只讀型事務(wù)被分配相對于真實時間較大的時間戳，那么就只會發(fā)生時鐘不同步會發(fā)生的兩種情況章節(jié)中的第一種情況，那種情況基本就是會導(dǎo)致只讀型事務(wù)需要因為安全時間機制進(jìn)行等待，但是只讀型事務(wù)讀取到的數(shù)值絕對是最新版本，正確的。

總結(jié)

Spanner能夠使得在世界范圍內(nèi)分布的數(shù)據(jù)中心實現(xiàn)了分布式事務(wù)的操作，并且性能也是可以忍受的，這真的十分神奇，而這神奇之處的關(guān)鍵就在于文章中的快照隔離和時間戳機制了。

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機房具備T級流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級服務(wù)器適合批量采購，新人活動首月15元起，快前往官網(wǎng)查看詳情吧

名稱欄目：6.824：Spanner詳解-創(chuàng)新互聯(lián)
文章源于：http://www.chinadenli.net/article20/dshjjo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、動態(tài)網(wǎng)站、App設(shè)計、企業(yè)建站、商城網(wǎng)站、網(wǎng)站導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)