來自GitHub的基礎設施工程師Micheal Haggerty發表了一篇博文，解釋他們是如何使用Spokes進行跨數據中心復制的。包括如何減少網絡往返次數、引入三階段提交、優化參考更新的性能以及其他各種調優。
Haggerty解釋說，GitHub通過跨數據中心復制代碼倉庫來最大化彈性和降低延遲。一旦數據中心發生故障，需要由另一個區域的副本接替工作，為了得到最好的性能，香港主機租用 香港高防服務器，需要為用戶提供距離最近的副本。
Spokes用于復制用戶的代碼倉庫，確保代碼倉庫之間是同步的。它就像代理一樣，在應用層面透明地執行復制任務。Haggerty說，韓國云服務器 美國云主機，以前只有距離很近的代碼倉庫之間才能進行復制作業，后來通過降低延遲和優化參考更新性能等方式解決了這個問題。
之前在進行復制時延遲會不斷增加，阻礙了Spokes進行參考更新的速度。雖然這對大多數用戶來說并不是大問題，但有些Git工作流在這方面有很高的要求：
大部分用戶不會經常提交代碼，但GitHub托管著將近7000萬個代碼倉庫，有些用戶的工作流你根本無法預測到。我們努力讓GitHub能夠應付所以場景，也非常關注一些極端情況。
Haggerty也解釋了GitHub內部是如何處理參考更新的。GitHub基于內部的測試來決定是否合并或rebase一個PR.如果某個分支有多個PR，每個PR都需要通過測試。
減少網絡往返次數可以有效降低延遲。GitHub使用三階段提交協議來更新副本，同時使用分布式鎖來保證更新次序。不過這樣需要四個網絡往返，成本有點高。他們也在努力確保在等待網絡調用結束之前先完成其他的任務。
GitHub的工程師也參與了Git項目，包括處理參考更新的事務機制，該機制基于副本是否有能力執行參考更新來決定是提交還是回滾事務。還有其他一些與參考更新操作相關的改進。
Spokes使用自定義的校驗和來比較副本，如果校驗和相同，說明它們包含相同的內容。校驗和是通過增量的方式算出來的，并不是每次都從頭開始算。
內務（book keep）操作被合并到少量的事務當中，因為有些單次提交操作會造成數百次內務更新，需要耗費三分之一秒的時間。
