GitHub使用Spokes进行跨数据中心复制

   <p style="text-align: center;"><a href="/misc/goto?guid=4958986207227852489" title="github"><img alt="GitHub使用Spokes进行跨数据中心复制" src="https://simg.open-open.com/show/6a8dd9147ee3d646e9ccfef8f071d6d9.png" /></a></p>    <p> </p>    <p>来自 GitHub 的基础设施工程师 Micheal Haggerty 发表了一篇博文，解释他们是如何使用 <a href="/misc/goto?guid=4959011407722827004">Spokes</a> 进行跨数据中心复制的。包括如何减少网络往返次数、引入<a href="/misc/goto?guid=4959011407831336753">三阶段提交</a>、优化参考更新的性能以及其他各种调优。</p>    <p>Haggerty 解释说，GitHub 通过跨数据中心复制代码仓库来最大化弹性和降低延迟。一旦数据中心发生故障，需要由另一个区域的副本接替工作，为了得到最好的性能，需要为用户提供距离最近的副本。</p>    <p>Spokes 用于复制用户的代码仓库，确保代码仓库之间是同步的。它就像代理一样，在应用层面透明地执行复制任务。Haggerty 说，以前只有距离很近的代码仓库之间才能进行复制作业，后来通过降低延迟和优化参考更新性能等方式解决了这个问题。</p>    <p>之前在进行复制时延迟会不断增加，阻碍了 Spokes 进行参考更新的速度。虽然这对大多数用户来说并不是大问题，但有些 Git 工作流在这方面有很高的要求：</p>    <blockquote>    大部分用户不会经常提交代码，但 GitHub 托管着将近 7000 万个代码仓库，有些用户的工作流你根本无法预测到。我们努力让 GitHub 能够应付所以场景，也非常关注一些极端情况。   </blockquote>    <p>Haggerty 也解释了 GitHub 内部是如何处理参考更新的。GitHub 基于内部的测试来决定是否合并或 rebase 一个 PR。如果某个分支有多个 PR，每个 PR 都需要通过测试。</p>    <p>减少网络往返次数可以有效降低延迟。GitHub 使用三阶段提交协议来更新副本，同时使用分布式锁来保证更新次序。不过这样需要四个网络往返，成本有点高。他们也在努力确保在等待网络调用结束之前先完成其他的任务。</p>    <p>GitHub 的工程师也参与了 Git 项目，包括处理参考更新的事务机制，该机制基于副本是否有能力执行参考更新来决定是提交还是回滚事务。还有其他一些与参考更新操作相关的改进。</p>    <p>Spokes 使用自定义的校验和来比较副本，如果校验和相同，说明它们包含相同的内容。校验和是通过增量的方式算出来的，并不是每次都从头开始算。</p>    <p>内务（book keep）操作被合并到少量的事务当中，因为有些单次提交操作会造成数百次内务更新，需要耗费三分之一秒的时间。</p>    <p> </p>    <p>来自: <a href="/misc/goto?guid=4959011407927792442" id="link_source2">InfoQ</a></p>