來自GitHub的基礎(chǔ)設(shè)施工程師Micheal Haggerty發(fā)表了一篇博文，解釋他們是如何使用Spokes進行跨數(shù)據(jù)中心復(fù)制的。包括如何減少網(wǎng)絡(luò)往返次數(shù)、引入三階段提交、優(yōu)化參考更新的性能以及其他各種調(diào)優(yōu)。
Haggerty解釋說，GitHub通過跨數(shù)據(jù)中心復(fù)制代碼倉庫來最大化彈性和降低延遲。一旦數(shù)據(jù)中心發(fā)生故障，需要由另一個區(qū)域的副本接替工作，為了得到最好的性能，需要為用戶提供距離最近的副本。
Spokes用于復(fù)制用戶的代碼倉庫，確保代碼倉庫之間是同步的。它就像代理一樣，在應(yīng)用層面透明地執(zhí)行復(fù)制任務(wù)。Haggerty說，以前只有距離很近的代碼倉庫之間才能進行復(fù)制作業(yè)，后來通過降低延遲和優(yōu)化參考更新性能等方式解決了這個問題。
之前在進行復(fù)制時延遲會不斷增加，阻礙了Spokes進行參考更新的速度。雖然這對大多數(shù)用戶來說并不是大問題，但有些Git工作流在這方面有很高的要求：
大部分用戶不會經(jīng)常提交代碼，但GitHub托管著將近7000萬個代碼倉庫，有些用戶的工作流你根本無法預(yù)測到。我們努力讓GitHub能夠應(yīng)付所以場景，也非常關(guān)注一些極端情況。Haggerty也解釋了GitHub內(nèi)部是如何處理參考更新的。GitHub基于內(nèi)部的測試來決定是否合并或rebase一個PR。如果某個分支有多個PR，每個PR都需要通過測試。
減少網(wǎng)絡(luò)往返次數(shù)可以有效降低延遲。GitHub使用三階段提交協(xié)議來更新副本，同時使用分布式鎖來保證更新次序。不過這樣需要四個網(wǎng)絡(luò)往返，成本有點高。他們也在努力確保在等待網(wǎng)絡(luò)調(diào)用結(jié)束之前先完成其他的任務(wù)。
GitHub的工程師也參與了Git項目，包括處理參考更新的事務(wù)機制，該機制基于副本是否有能力執(zhí)行參考更新來決定是提交還是回滾事務(wù)。還有其他一些與參考更新操作相關(guān)的改進。
Spokes使用自定義的校驗和來比較副本，如果校驗和相同，說明它們包含相同的內(nèi)容。校驗和是通過增量的方式算出來的，并不是每次都從頭開始算。
內(nèi)務(wù)（book keep）操作被合并到少量的事務(wù)當中，因為有些單次提交操作會造成數(shù)百次內(nèi)務(wù)更新，需要耗費三分之一秒的時間。
點擊鏈接閱讀博客全文，了解更多細節(jié)。
查看英文原文：How GitHub Uses Spokes for Cross Data-Center Replication
京公網(wǎng)安備 11010502049343號