BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Andrew Morgan 关注 3 他的粉丝 ,译者 薛命灯 关注 24 他的粉丝 发布于 2017年10月24日. 估计阅读时间: 2 分钟 | ArchSummit北京2018 共同探讨机器学习、信息安全、微服务治理的关键点

来自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)操作被合并到少量的事务当中,因为有些单次提交操作会造成数百次内务更新,需要耗费三分之一秒的时间。

点击链接阅读博客全文,了解更多细节。

查看英文原文How GitHub Uses Spokes for Cross Data-Center Replication

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT