Facebook應用Mercurial經驗談

banq發表於2014-01-08


Facebook的主要原始碼庫是巨大的 - 甚至比Linux核心還要大，一週有成千上萬犯跨越成百上千的檔案的提交。

兩年前Facebook還是使用Subversion+Git，很快成為瓶頸，Facebook程式碼庫已經成長為內部依賴關係是非常複雜。需要花很多時間使之更模組化，才能適合一般的原始碼管理工具，但是Facebook認為也有他們這樣使用單個儲存庫的好處。他們的特點是一個不斷分裂變大的單一原始碼庫，現有的大部分原始碼管理工具透過限制程式碼結構的方式並不適合他們。

Facebook開始自己尋找新的方案，考慮到程式設計師都習慣Git介面，花了很長時間提升Git，但是很難看到提高的工作規模。想來想去，Facebook得出的結論是：Git是不適合內部一個巨大專案的。

最後，他們選擇了Mercurial。

Mercurial(水銀)是一個類似於Git的分散式原始碼管理系統。它主要是使用清晰的模組化的Python 編寫，使其成為易於擴充套件。當Facebook開始使用水銀，發現它比Git在幾個顯著的領域慢。為了縮小這種差距，Facebook在過去一年半的時間已經貢獻了超過500補丁。

對於大到象Facebook這樣的的儲存庫，一個主要的瓶頸是簡單地找出哪些檔案發生了變化。 Git是檢查每個檔案，自然地隨著檔案數量的增加變得越來越慢，而Perforce的“秘籍” ，迫使使用者告訴它他們將編輯的檔案。Git的方法不具有擴充套件，Perforce的方法也並不友好。Facebook 透過監控檔案系統更改解決這個問題。

Facebook讓Watchman守望者的整合取得了Mercurial的命令狀態比Git的狀態命令更快，超過5倍。

提交率和歷史資料的龐大規模也帶來了挑戰。Facebook每一天有成千上萬的提交，儲存庫變大使得clone和Poll等操作變得越來越痛苦。Faceook建立了remotefilelog擴充套件水銀，改變了clone和pull命令,只下載提交的後設資料，而忽略了佔下載大頭的所有檔案的變化。再透過使用memcache作為基礎設施，在中央Mercurial伺服器的前面設定一個快取層，這樣即使中央儲存庫出現故障， memcache將繼續提供許多檔案內容。啟用remotefilelog擴充套件後員工在Facebook已經實現Mercurial clone和poll要快10倍，從幾分鐘到幾秒鐘，這是因為remotefilelog儲存資料在本地磁碟上的方式。

水銀有幾個這種漂亮的抽象擴充套件。最值得注意的是filelog類。是一種資料結構，表示一個特定檔案的每個版本。每個版本的檔案是由一個唯一的雜湊標識。對於給定的一個雜湊時，filelog可以重建一個檔案的請求版本。remotefilelog擴充套件是替換其的另一種實現，具有filelog相同介面。它接受一個雜湊，但不是從本地資料檔案的版本重建，它從本地快取或遠端伺服器獲取該版本。當我們需要從伺服器請求大量的檔案，我們這樣大批次地做，以避免許多請求的開銷。

相關文章