隨筆檔案

前面我的一篇文章http://hi.baidu.com/knuthocean/blog/item/12bb9f3dea0e400abba1673c.html引用了對Google App Engine工程師關于Bigtable/Megastore replication的文章。當時留下了很多疑問，比如：為什么Google Bigtable 是按照column family級別而不是按行執行replication的？今天重新思考了Bigtable replication問題，有如下體會：

1. Bigtable/GFS的設計屬于分層設計，和文件系統/數據庫分層設計原理一致，通過系統隔離解決工程上的問題。這種分層設計帶來了兩個問題，一個是性能問題，另外一個就是Replication問題。由于存儲節點和服務節點可能不在一臺機器，理論上總是存在性能問題，這就要求我們在加載/遷移Bigtable子表(Bigtable tablet)的時候考慮本地化因素；另外，GFS有自己的replication機制保證存儲的可靠性，Bigtable通過分離服務節點和存儲節點獲得了很大的靈活性，且Bigtable的宕機恢復時間可以做到很短。對于很多對實時性要求不是特別高的應用Bigtable由于服務節點同時只有一個，既節約資源又避免了單點問題。然后，Bigtable tablet服務過于靈活導致replication做起來極其困難。比如，tablet的分裂和合并機制導致多個tablet(一個只寫，其它只讀)服務同一段范圍的數據變得幾乎不可能。

2. Google replication分為兩種機制，基于客戶端和基于Tablet Server。分述如下：

2-1). 基于客戶端的replication。這種機制比較簡單，實現如下：客戶端讀/寫操作均為異步操作，每個寫操作都嘗試寫兩個Bigtable集群，任何一個寫成功就返回用戶，客戶端維護一個retry list，不斷重試失敗的寫操作。讀操作發到兩個集群，任何一個集群讀取成功均可。然后，這樣做有兩個問題：

    a. 客戶端不可靠，可能因為各種問題，包括程序問題退出，retry list丟失導致兩個集群的數據不一致；

    b. 多個客戶端并發操作時無法保證順序性。集群A收到的寫操作可能是"DEL item; PUT item"；集群B的可能是"PUT item; DEL item"。

2-2). 基于Tablet Server的replication。這種機制實現較為復雜，目的是為了保證讀服務，寫操作的延時仍然可能比較長。兩個集群，一個為主集群，提供讀/寫服務；一個為slave集群，提供只讀服務，兩個集群維持最終一致性。對于一般的讀操作，盡量讀取主集群，如果主集群不可以訪問則讀取slave集群；對于寫操作，首先將寫操作提交到主集群的Tablet Server，主集群的Tablet Server維護slave集群的元數據信息，并維護一個后臺線程不斷地將積攢的用戶表格寫操作提交到slave集群進行日志回放(group commit)。對于一般的tablet遷移，操作邏輯和Bigtable論文中的完全一致；主集群如果發生了機器宕機，則除了回放commit log外，還需要完成宕機的Tablet Server遺留的后臺備份任務。之所以要按照column family級別而不是按行復制，是為了提高壓縮率從而提高備份效率。如果主集群寫操作日志的壓縮率大于備份數據的壓縮率，則可能出現備份不及時，待備份數據越來越多的問題。

假設集群A為主集群，集群B是集群A的備份，集群切換時先停止集群A的寫服務，將集群A余下的備份任務備份到集群B后切換到集群B；如果集群A不可訪問的時間不可預知，可以選擇直接切換到集群B，這樣會帶來一致性問題。且由于Bigtable是按列復制的，最后寫入的一些行的事務性無法保證。不過由于寫操作數據還是保存在集群A的，所以用戶可以知道丟了哪些數據，很多應用可以通過重新執行A集群遺留的寫操作進行災難恢復。Google的App Engine也提供了這種查詢及重做丟失的寫操作的工具。

想法不成熟，有問題聯系：knuthocean@163.com