Google Megastore介紹

• • 概述
  • 策略對比
  • • 異步主從 Asynchronous Master/Slave
    • 同步主從 Synchronous Master/Slave
    • 樂觀復制 Optimistic Replication
    • Megastore的選擇
  • Megastore系統架構
  • 實體組EG
  • 并發控制（事務）
  • • 讀事務
    • 寫事務
  • 索引
  • 協調者
  • 讀寫流程
  • • 讀流程
    • 寫流程
  • Megastore總結

---

概述

Megastore是在Bigtable的基礎上提供了友好的數據庫功能支持。是介于關系型數據庫（RDBMS）和NoSQL之間的存儲技術。其引入了實體組（Entity Group EG）的概念，每一個用戶的所有數據構成一個實體組。每個EG中可能會有多張表。多數情況下同一個EG只有一個子表，分布在一臺bigtable TabletServe上，如果EG比較大，導致子表分裂，會分布到多臺機器上。同一個EG內保證強一致性，多EG之間只保證最終一致性

Megastore研發的目的是為了支撐谷歌每天30億次的寫請求和200億次的讀請求，并且要支撐PB級別的跨可用區數據規模

策略對比

論文開頭作者就對比了分布式系統各種共識方案：

異步主從 Asynchronous Master/Slave

通過一致性協議選主并復制日志，WAL日志至少要寫到一個slave上去。這種方式master可以做到很快的ACID事務，但是節點發生變動或者leader變化的時候會導致有一定的時間不可服務，并且由于各節點的副本狀態不是強一致，其丟數據的風險要比一般的強一致系統要大。

同步主從 Synchronous Master/Slave

主將數據復制到所有的從節點后操作才算完成。需要有外部服務及時檢測各個節點的狀態（節點下線、路由變更、修復）。由于使用強同步協議，丟數據的風險大大降低，隨之而來的是延遲的增大

樂觀復制 Optimistic Replication

wiki中定義為：

Optimistic replication, also known as lazy replication,is a strategy for replication, in which replicas are allowed to diverge.
Traditional pessimistic replication systems try to guarantee from the beginning that all of the replicas are identical to each other, as if there was only a single copy of the data all along. Optimistic replication does away with this in favor of eventual consistency, meaning that replicas are guaranteed to converge only when the system has been quiesced for a period of time. As a result, there is no longer a need to wait for all of the copies to be synchronized when updating data, which helps concurrency and parallelism. The trade-off is that different replicas may require explicit reconciliation later on, which might then prove difficult or even insoluble.

個人理解意味副本中的內容只保證最終一致性，如果各個副本中內容不一致，需要有額外的機制去解決沖突。這種模型意味著可用性和延遲都是最好的，但是就別想做事務了

Megastore的選擇

不能丟數據并且要支持ACID事務

不要外部的master服務去監控節點運行狀態，這種檢測故障、修復的failover機制通常會帶來用戶可以感知到的高延遲，并且會增加系統的復雜程度

所以最后的方案系統中并沒有master節點，并且使用paxos協議復制數據，并在集群中增加協調者處理、優化讀寫請求。

Megastore系統架構

AppServer：客戶端庫，Megastore的大部分功能集中在客戶端，包括映射Megastore操作到bigtable，事物及并發控制，基于Paxos的復制，將請求發送給各個復制服務器，通過協調者實現快速讀等。

ReplicationServer：復制服務器，接受客戶端請求并寫入對應的bigtable實例。

Coordinator：協調者，存儲每個機房EG是否處于最新狀態，用于實現快速讀。

megastore的功能主要分為以下三部分：

映射Megastore數據模型到Bigtable

事務及并發控制

跨機房數據復制及讀寫優化

實體組EG

每個EG內的操作日志采用paxos協議進行復制到多個機房，保證強一致性(strong consistency)，并且提供序列化（serializable）隔離級別的ACID特性的事務

在EG內，通過REDO日志實現事務，客戶端寫完REDO日志后，事務操作成功，然后在回放REDO日志進行寫入，這里的REDO日志就相當于WAL日志

如果REDO日志回放失敗（比如發生了宕機），后面的讀需要先回放REDO日志，才能保證讀取到最新的數據

EG之間通過分布式隊列的方式（推薦使用這種方式）保證最終一致性，或者2PC的方式實現布式事務

如果要實現分布式事務（強一致性），就只能用2PC加鎖協調了。

replication server有定時掃描線程，發現沒有完成的寫操作，并通過paxos發送no-op給其他no-op，用來打平版本

并發控制（事務）

讀事務

Megastore提供了三種讀取模式：

最新讀取（current read）：讀取最新的版本（必須applied）

快照讀取（snapshot read）：也是讀取最新版本，但有可能讀到transaction完成但是沒有applied的日志

非一致性讀（inconsistentread）：不考慮redolog的狀態直接讀，有可能讀到不完整的事務

寫事務

Megasttore的所有寫操作都要先寫redo log，然后采用paxos復制到集群中。流程大概如下：

讀取：獲取最后一次提交事務的時間戳和日志位置

應用邏輯：從Bigtable讀取并將寫操作聚合到日志緩沖區中

提交：將緩沖區中的操作日志追加到多個機房的Bigtable集群中，通過paxos保證一致性

生效：apply redo log。更新eg和索引

清理：刪除不再需要的數據

由于Megastore從上層應用的角度設計出了EG的概念：同一時間多個客戶端對統一EG發出修改請求的概率較低。所以事務沖突概率較低。

Each Megastore entity group functions as a mini-database that provides serializable ACID semantics. A transaction writes its mutations into the entity group’s write-ahead log, then the mutations are applied to the data.

索引

megaStore主要提供以下2類索引

局部索引（local index）：單個EG內部的索引

全局索引（global index）：橫跨多個EG

協調者

MegaStore的一大兩件就是在集群中引入了協調者的概念，引入協調者后：

快速讀：協調者可以記錄當前節點存儲的某個EG的數據是否是最新的，從而用local read加速讀取。免去了每次讀都要走paxos協議的繁瑣過程。當EG有更新操作時，需要首先將協調者記錄的EG狀態更新為無效。如果某個機房的Bigtable寫入失敗，需要首先失效對應的協調者，才能返回客戶端。

協調者的可用性：由于每次寫操作都要涉及協調者，因此協調者出現故障會導致集群不可用。Megastore使用chubby提供的鎖服務。協調者啟動時在chubby獲取鎖，如果協調者失效，那么鎖會失效（類似zookeeper的connection lost事件），這時寫操作可以忽略協調者。當然，這里面肯定會涉及到一個失效的超時時間的問題。從協調者不可用到鎖失效有幾秒鐘的時間。這期間的寫操作都會失敗。

競爭：對于協調者的協議必須滿足一些列條件，失效總是安全的，但是生效必須謹慎對待。在異步網絡環境中，消息可能亂序到達協調者，所以每條生效和失效操作都必須攜帶日志信息，如果協調者先收到較晚的失效操作再收到焦躁的生效操作，生效操作會被忽略。

讀寫流程

讀流程

• 讀流程首先檢查協調者，查看是否本地EG處于最新狀態
  • 如果本地最新，可以直接使用local read
    • 如果本地不是最新，需要對讀操作應用paxos協議，做一個majority read
    • 追趕：讀取最新EG后，需要通過獲取最新redo log，然后apply redo log到本地的方式將本地EG更新，并通知協調者

寫流程

寫流程就是對paxos組寫入。對某個EG執行paxos協議，不再贅述。

Megastore總結

分布式存儲系統有兩個目標：一個是可擴展性，最終目標是線性可擴展，另一個是功能，最終目標是支持全功能SQL。Megastore是一個介于傳統關系型數據庫和分布式NoSQL系統之間的存儲系統。融合了SQL和NoSQL兩者的優勢。

Megastore的是構建與Bigtable之上的系統，其創新點主要包括：

提出了EG的數據模型，通過EG劃分數據，EG內維持關系型數據庫的ACID特性，EG之間維持類似NoSQL的弱一致性。有效的融合了SQL和NoSQL兩者的優勢。

使用paxos做到了較好的Availability和Consistency，并且通過協調者優化了讀寫性能。

繼承了Bigtable的有點和缺點。

總結

以上是生活随笔為你收集整理的Google Megastore介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。