本發(fā)明涉及計算機技術(shù)領(lǐng)域，特別涉及一種分布式多中心Git中央倉庫管理系統(tǒng)及控制方法。

背景技術(shù)：

隨著分布式源碼管理工具Git的流行，出現(xiàn)了GitHub、GitLab、OSC、Coding、GitCoffee等Git的中央倉庫管理軟件。中央倉庫管理由于要存儲大量的代碼倉，所以要解決存儲容量可擴展的問題，以及多個研發(fā)中心跨地域訪問的問題。

現(xiàn)有的中央倉庫管理系統(tǒng)，以Gitlab為代表，大部分都使用了分布式文件系統(tǒng)(DFS)作為倉庫容量擴展的手段。分布式文件系統(tǒng)可以動態(tài)擴展容量，然而，由于Git倉庫由大量小文件組成，而分布式文件系統(tǒng)都不適合大量的小文件存儲的場景，所以存儲效率低，IO讀寫性能差。因此，分布式文件系統(tǒng)的應(yīng)用給中央倉庫管理系統(tǒng)的性能造成了巨大的限制(參見圖1)。

另外，現(xiàn)有的中央倉庫管理系中，以GitHub為代表，使用了前后臺遠程調(diào)用的方式來擴展存儲容量。這種方式解決了容量動態(tài)擴展，但是GitHub使用了后端RT-PRC來實現(xiàn)前后端的遠程調(diào)用(參見圖2)。

后端RT-RPC使用Erlang，通過自定義的序列化方式，可以實現(xiàn)多種面向?qū)ο笳Z言的對象序列化，能夠?qū)崿F(xiàn)Ruby的遠程調(diào)用。然而，這需要程序員自己定義好服務(wù)接口和Ruby對象映射，這增加了分布式后端實現(xiàn)和維護的復雜程度。

另外，不論是Gitlab，還是Github，都沒有解決多個研發(fā)中心跨地域訪問的問題。而且，在一個公司有多個研發(fā)中心的情況下，如果中央倉庫位于其中一個研發(fā)中心，則其它研發(fā)中心訪問由于要經(jīng)過廣域網(wǎng)，會造成網(wǎng)絡(luò)延遲較大，網(wǎng)絡(luò)流量劇增。

技術(shù)實現(xiàn)要素：

針對以上問題，本發(fā)明的目的在于提供一種讀寫分離的、多個研發(fā)中心可異地訪問的分布式多中心Git中央倉庫管理系統(tǒng)。

為實現(xiàn)以上目的，本發(fā)明提供以下技術(shù)方案：

一種Git中央倉庫管理系統(tǒng)，其包括：多個后端，其包括本地后端和其他遠程后端，所述多個后端用于存儲倉庫；前端，其用于通過遠程調(diào)用來訪問后端上的倉庫；以及同步模塊，其用于使所述多個后端上存儲的倉庫同步。

本發(fā)明的有益效果在于：

本發(fā)明使用dRuby實現(xiàn)了Git倉庫的Ruby遠程訪問，解決了Git倉庫的容量的動態(tài)擴展問題以及多個研發(fā)中心跨地域訪問的問題，同時大大提升了讀寫速度，降低了基于Ruby程序開發(fā)分布Git倉庫的復雜度，并且提升了系統(tǒng)性能；本發(fā)明還實現(xiàn)了多中心Git倉庫的同步，達到讀寫分離，提升了多個研發(fā)中心訪問中心倉庫的網(wǎng)絡(luò)速度。

附圖說明

圖1為現(xiàn)有的采用DFS方式來實現(xiàn)容量擴展的示意圖。

圖2為現(xiàn)有的采用分布式調(diào)用來實現(xiàn)容量擴展的示意圖。

圖3為本發(fā)明的分布式多中心Git中央倉庫管理系統(tǒng)的示意圖。

圖4為本發(fā)明的基于dRuby的Git遠程調(diào)用的流程示意圖。

圖5是描述用于控制Git中央倉庫的控制方法的圖。

具體實施方式

下面，參照附圖對本發(fā)明的具體實施例做進一步說明，請注意，以下實施例對本發(fā)明僅僅是例示性的，并且決不旨在限制本發(fā)明的范圍。

如圖1所示，為現(xiàn)有的采用分布式文件系統(tǒng)(DFS)方式來實現(xiàn)容量擴展的示意圖。其中，共享資源駐留在多臺服務(wù)器上的各個共享文件夾中，同時DFS方式不適合大量的小文件存儲的場景。

如圖2所示，為現(xiàn)有的采用分布式調(diào)用來實現(xiàn)容量擴展的示意圖。其中，GitHub使用了前后臺遠程調(diào)用的方式來擴展存儲容量，其使用了后端RT-PRC來實現(xiàn)前后臺遠程調(diào)用，這需要程序員自己定義好服務(wù)接口和Ruby對象映射，增加了分布式后端實現(xiàn)和維護的復雜程度。

對于Ruby語言，自從1.9.3版本之后，其內(nèi)部實現(xiàn)了dRuby模塊，實現(xiàn)分布式遠程調(diào)用，dRuby使用自己定義的協(xié)議，不需要任何外部協(xié)議就能實現(xiàn)編碼，使得遠程調(diào)用程序更容易編寫和維護。同時dRuby的proxy機制最大限度地使用了緩存，提高了系統(tǒng)性能。

因此，本發(fā)明直接采用dRuby來實現(xiàn)遠程調(diào)用，使得系統(tǒng)功能和性能都有很大提高。

下面參考圖3描述根據(jù)本發(fā)明一個實施例的分布式多中心Git中央倉庫管理系統(tǒng)10。如圖3示出了本發(fā)明的分布式多中心Git中央倉庫管理系統(tǒng)10的示意圖。其中，本發(fā)明的分布式多中心Git中央倉庫管理系統(tǒng)10包括多個后端101，其用作數(shù)據(jù)存儲倉庫，例如存儲代碼。所述多個后端101分布在多個中心。圖3的實施例中具有兩個中心，分別為主中心100和分中心110。本領(lǐng)域技術(shù)人員容易理解，本實施例的分布式多中心Git中央倉庫管理系統(tǒng)10可以具有多于兩個的中心。并且主中心和分中心也并非是限制性的，多個中心的地位可以是平等的。以下以主中心100和分中心110為例進行說明。

圖3中示出主中心100和分中心110通過廣域網(wǎng)進行通訊。但本領(lǐng)域技術(shù)人員容易理解，本發(fā)明不限于此。主中心100和分中心110例如可通過有線或無線個人域網(wǎng)(PAN)、局域網(wǎng)(LAN)、城域網(wǎng)(MAN)、等等進行通訊。

根據(jù)一個優(yōu)選實施例，主中心100和分中心110包括相同數(shù)量的后端101，例如均包括后端BE1、BE2和BE3。主中心的后端分別相對應(yīng)。例如分中心110的后端BE1、BE2和BE3分別是主中心的后端BE1、BE2、BE3的鏡像。

圖3的實施例中，主中心100還包括前端(FE)102，分中心110也 包括前端112。前端102和112分別可供主中心100和分中心110的用戶就近訪問。由于主中心的后端和分中心的后端分別存儲有數(shù)據(jù)或者數(shù)據(jù)的鏡像，因此用戶可以就近訪問當?shù)氐那岸?，減少網(wǎng)絡(luò)延遲和網(wǎng)絡(luò)流量，大大提高用戶讀取倉庫的速度。

前端102、112還可以對用戶訪問進行權(quán)限檢查，例如確認用戶是否具有對該中心進行讀和/或?qū)懖僮鞯臋?quán)限，并且根據(jù)權(quán)限檢查的結(jié)果進行下一步操作，例如拒絕用戶訪問，或按照用戶的請求對后端進行讀寫操作。

圖3實施例中的分布式多中心Git中央倉庫管理系統(tǒng)10中，主中心100還可包括路由模塊103，分中心110也可包括路由模塊113。路由模塊103和113有相應(yīng)的前端102、112調(diào)用，用于根據(jù)路由規(guī)則定位存儲有用戶所需代碼的后端。本領(lǐng)域技術(shù)人員容易理解，對于主中心100和分中心110，路由模塊都不是必須的。例如前端102和112可分別具有查詢功能，根據(jù)用戶輸入而查詢到相應(yīng)的后端。但當存儲量大、后端數(shù)目多的時候，具有路由模塊是優(yōu)選的，因為設(shè)置優(yōu)化的路由規(guī)則，可以減少查詢、定位所需的時間成本，提高用戶體驗質(zhì)量。

圖3實施例中的分布式多中心Git中央倉庫管理系統(tǒng)10中，主中心100還包括同步模塊104，分中心110也包括同步模塊114。

本領(lǐng)域技術(shù)人員理解，本實施例的分布式多中心Git中央倉庫管理系統(tǒng)10也可包括一個統(tǒng)一的同步模塊，而非在各個中心中包括單獨的同步模塊。以下以各個中心分別包括各自的同步模塊為例進行說明。

同步模塊104和114用于同步主中心100和分中心110的后端的存儲數(shù)據(jù)和作業(yè)。其中，主中心100的同步模塊104通過狀態(tài)同步服務(wù)生成同步作業(yè)；分中心110的同步模塊114通過狀態(tài)同步服務(wù)來同步主中心生成的同步作業(yè)，并且更新同步狀態(tài)。例如當主中心100的后端BE1接受了寫入操作時，同步模塊104和114可以進行數(shù)據(jù)同步，更新分中心110的后端BE1的數(shù)據(jù)。同樣，當分中心110的后端BE2接受了寫入操作時，同步模塊104和114可以進行數(shù)據(jù)同步，更新主中心110的后 端BE2的數(shù)據(jù)。同步模塊104和114之間可以使用標準的Git協(xié)議。二者之間的同步可以是實時的，例如當主中心100和分中心110中的一個的后端數(shù)據(jù)被更新時，自動觸發(fā)同步。二者之間的同步也可以是非實時的，例如定時更新。也可以根據(jù)具體需求而設(shè)定一定的同步規(guī)則。

在各個中心，前端可以對用戶訪問進行權(quán)限檢查，當確認用戶具有對應(yīng)的讀寫權(quán)限時，調(diào)用路由模塊。路由模塊根據(jù)路由規(guī)則，發(fā)現(xiàn)倉庫所在的后端，然后使用RPC遠程調(diào)用該后端，這樣用戶可以訪問位于該后端的倉庫內(nèi)容。

另外，根據(jù)本發(fā)明的一個優(yōu)選實施例，分中心110的前端112可以訪問主中心100的后端。反之，主中心100的前端102也可以訪問分中心110的后端。這樣例如在主中心100和分中心110之間尚未進行同步時，也能夠保證用戶可以訪問最新的數(shù)據(jù)。例如主中心100和分中心110均設(shè)有同步狀態(tài)標記，例如可以為“已同步”或者“未同步”。例如在主中心100的后端已經(jīng)進行更新的情況下，通過前端產(chǎn)生同步操作，發(fā)送給狀態(tài)同步模塊，狀態(tài)同步模塊通過狀態(tài)同步服務(wù)生成同步作業(yè)，并向所有分中心指出應(yīng)該同步該同步作業(yè)；同時將所有分中心的同步狀態(tài)設(shè)置為未同步。

以下分別描述主中心和分中心的讀/寫操作。

當用戶在主中心執(zhí)行寫操作時，首先，用戶發(fā)出Git寫操作命令，該命令被發(fā)送到本地前端。其次，前端調(diào)用路由模塊，路由模塊根據(jù)路由規(guī)則，查找倉庫在本地所處的后端；然后前端使用RPC遠程調(diào)用該后端，將內(nèi)容寫入后端。然后，前端產(chǎn)生同步操作，發(fā)送給狀態(tài)同步模塊，狀態(tài)同步模塊通過狀態(tài)同步服務(wù)生成同步作業(yè)，并向所有分中心指出應(yīng)該同步該同步作業(yè)；同時將所有分中心的同步狀態(tài)設(shè)置為未同步。最后，各個分中心狀態(tài)同步模塊通過Git協(xié)議，同步主中心的Git倉。各個分中心完成同步之后，把自身的同步狀態(tài)設(shè)置為已同步。在所述遠程調(diào)用中，除了dRuby之外，還可以使用xmlrpc、thrift等遠程調(diào)用協(xié)議。

然后，當用戶在分中心執(zhí)行讀操作時，首先，用戶發(fā)出Git寫讀作命 令，該命令被發(fā)送到本地前端。然后，前端查看本中心的同步狀態(tài)，查看同步狀態(tài)是已同步還是未同步。如果狀態(tài)是已同步，則前端調(diào)用路由模塊，路由模塊根據(jù)路由規(guī)則，查找倉庫在本地所處的后端；然后前端使用RPC遠程調(diào)用訪問后端上的倉庫內(nèi)容，返回給客戶。如果狀態(tài)是未同步，則前端調(diào)用路由模塊，路由模塊根據(jù)路由規(guī)則，查找倉庫在主中心所處的后端；然后前端使用RPC遠程調(diào)用訪問后端上的倉庫內(nèi)容，返回給客戶。在所述遠程調(diào)用中，除了dRuby之外，還可以使用xmlrpc、thrift等遠程調(diào)用協(xié)議。

這樣，當分中心的用戶讀倉庫時，分中心前端先檢查同步狀態(tài)。如果同步狀態(tài)為已同步，則訪問本地后端。如果同步狀態(tài)為未同步，則訪問主中心后端。由此，實現(xiàn)在本地完成讀操作，大大緩解網(wǎng)絡(luò)延遲。

當用戶在分中心執(zhí)行寫操作時，與在主中心執(zhí)行寫操作類似地，首先，用戶發(fā)出Git寫操作命令，該命令被發(fā)送到本地前端。其次，前端調(diào)用路由模塊，路由模塊根據(jù)路由規(guī)則，查找倉庫所在的后端，然后前端使用RPC遠程調(diào)用該后端，將內(nèi)容寫入后端。然后，前端產(chǎn)生同步操作，發(fā)送給狀態(tài)同步模塊，狀態(tài)同步模塊通過狀態(tài)同步服務(wù)生成同步作業(yè)，并向主中心指出應(yīng)該同步該同步作業(yè)。最后，主中心狀態(tài)同步模塊通過Git協(xié)議，同步分中心的Git倉。在所述遠程調(diào)用中，除了dRuby之外，還可以使用xmlrpc、thrift等遠程調(diào)用協(xié)議。

當用戶在主中心執(zhí)行讀操作時，首先，用戶發(fā)出Git寫讀作命令，該命令被發(fā)送到本地前端。其次，前端調(diào)用路由模塊，路由模塊根據(jù)路由規(guī)則，查找倉庫在主中心所處的后端。然后，前端使用RPC遠程調(diào)用訪問后端上的倉庫內(nèi)容，返回給客戶。在所述遠程調(diào)用中，除了dRuby之外，還可以使用xmlrpc、thrift等遠程調(diào)用協(xié)議。

其中，當用戶在分中心執(zhí)行寫操作時，可以將寫操作一起寫入多個分中心的后端，這樣，可以在多個分中心執(zhí)行讀寫操作，實現(xiàn)多中心的讀寫分離。例如，用戶在一個分中心執(zhí)行寫操作時，可以將其一起寫入多個分中心，然后，用戶可以在該多個分中心中的任何一者中執(zhí)行讀寫 操作，由此達到讀寫分離。

由以上內(nèi)容可知，在任何時候，當用戶提交代碼時(即執(zhí)行寫操作時)，都會被寫入到主中心。位于各個后端的所有倉庫的內(nèi)容，在其對應(yīng)的中心，都有一份完整備份。

下面，以基于dRuby來實現(xiàn)Git倉庫的Web訪問的前后臺分離為例，對本發(fā)明的遠程調(diào)用的過程進行說明。

如圖4所示，為本發(fā)明的基于dRuby的Git遠程調(diào)用的流程示意圖。其中，在一個中心，前端對用戶訪問進行權(quán)限檢查，確認用戶被授權(quán)之后，調(diào)用路由模塊，根據(jù)路由規(guī)則，發(fā)現(xiàn)倉庫所在的后端，然后使用RPC遠程調(diào)用訪問位于后端上的倉庫內(nèi)容。Web邏輯使用Ruby語言開發(fā)，針對Git倉庫，封裝了相應(yīng)的RubyGitObject來訪問Git倉庫數(shù)據(jù)。

為了實現(xiàn)遠程訪問其他終端上的Git倉庫，首先，Git倉庫所在主機(后端)啟動作為DrbServer，Web邏輯所在主機(前端)作為DrbClient，DrbServer首先提供一組接口，允許DrbClient根據(jù)倉庫的名稱，訪問對應(yīng)倉庫的內(nèi)容。DrbServer根據(jù)RubyGitObject的特征，返回兩種類型的Object。一種為Re前端rence型的object，此種類型的object返回到client后，作為一個代理，代理到server側(cè)的DrbObject，以后每次方法調(diào)用，都是一次遠程訪問。另一種為Value型的object，此種類型的object返回RubyGitObjects，其中包含所需的Git倉庫數(shù)據(jù)。

根據(jù)RubyGitObjects的特點，實現(xiàn)為Re前端rence型的有：repository、blame、MergeRepo、OnlineEdit。實現(xiàn)為Value型的有blob、commit、tree、diff、tag。DrbInterface Object作為一個Re前端rence型的object被作為Server的Front Object，使用Ruby的method_missing機制，在client與server之間提供其他所有GitObject映射。

另外，為了實現(xiàn)多中心讀寫分離，本發(fā)明采用了狀態(tài)同步模塊，狀態(tài)同步模塊通過使用狀態(tài)同步服務(wù)，實現(xiàn)狀態(tài)和作業(yè)的同步，并由此實現(xiàn)讀寫分離。

下面，具體介紹本發(fā)明的多個中心之間實現(xiàn)作業(yè)和狀態(tài)同步的詳細 過程。

首先，介紹路由數(shù)據(jù)結(jié)構(gòu)。其中，各中心使用共享Redis來存儲所有的倉庫、后端的倉庫路由以及同步狀態(tài)信息。

倉庫路由保存?zhèn)}庫所在的location和backendCluster。在redis中，存在名為repoMap的哈希表來保存所有的倉庫路由。該哈希表的Key為repo的path(username/repo),值為其存儲的后端組(locationName_backendClusterName,e.g.BJ_backendCluster1)。

狀態(tài)數(shù)據(jù)保存?zhèn)}庫所在的后端的同步狀態(tài)信息。各個倉庫所在的后端的狀態(tài)，用名為repoPath_syncStatus的哈希表來保存。該哈希表的key為IP，值為“state&time”。其中，State當前取值為0時，表示未同步；取值為1時表示已同步。

當系統(tǒng)初始化時，路由信息為空，在項目創(chuàng)建時，生成路由信息。項目的狀態(tài)信息在項目創(chuàng)建時生成，并且項目的狀態(tài)信息只會根據(jù)寫狀態(tài)而改變，但不會消失。

后端組集合記錄每個后端組中的后端：使用集合來保存，集合的名稱為locationName_backendClusterName_hosts,值為后端的IP。

后端組的Maser成員為一個有效時間為5秒(可配置)的字符串，key格式為，locationName_backendClusterName_master,值是master的IP。

后端組成員的存活狀態(tài)由一個有過期時間(可配置)整數(shù)值表示，key為IP_alive,值為1。如果存在則表示活，不存在表示不活。

后端組資源分別為：

location_backendCluser1_storageFree:integer

location_backendCluser1_cpuIdle:integer

location_backendCluser1_memFree:integer。

后端成員資源分別為：

ip1_cpuIdle:integer；

ip1_memFree:integer；

ip1_storageFree:integer。

后端成員同步隊列為ip1_queue:tasks。

下面，描述生成/import/Fork新的倉庫的過程，其包括以下步驟：

a)根據(jù)主中心中各backendCluster的資源使用情況，選擇一個backendCluster保存此項目。

b)前端通過gitlab_git_client到主后端上生成項目。

c)生成倉庫路由。

d)backendCluster中對應(yīng)的主后端和從后端。對于主后端(即主中心后端)，生成倉庫狀態(tài)數(shù)據(jù)為已同步+當時時間。對于從后端(即分中心后端)，生成倉庫狀態(tài)數(shù)據(jù)為未同步+當時時間。

e)項目生成成功后，前端在所有的從后端(不管存活狀態(tài))中添加同步任務(wù)，要求從后端從主后端同步項目。

f)從后端中的同步進程讀取從后端中的同步任務(wù)，完成同步，完成后更新倉庫狀態(tài)數(shù)據(jù)為已同步+當時時間。

下面，描述頁面修改倉庫的過程，其包括：前端(gitlab_git_client)查找路由信息，查找倉庫所在的backendCluster。獲取本backendCluster的master。前端通過gitlab_git_client到master寫入操作。寫入完成后，master上的hooks函數(shù)，負責在所有的從后端中添加同步任務(wù)，要求從后端從主后端同步項目，同時把所有的從節(jié)點的同步狀態(tài)設(shè)為未同步+時間戳。從后端中的同步進程讀取從后端中的同步任務(wù)，完成同步，完成后更新倉庫狀態(tài)數(shù)據(jù)為已同步+當時時間。

頁面讀取倉庫時，前端(gitlab_git_client)查找路由信息，查找倉庫所在的backendCluster。根據(jù)backendCluster的各后端的狀態(tài)，選擇一個讀取后端。前端通過gitlab_git_client到選出的后端上讀操作。

后端同步時，各個后端上都運行多個同步進程(可配置)，同步進程監(jiān)聽location_backendCluser1_ip1_queue:tasks上的任務(wù)，根據(jù)任務(wù)完成倉庫的同步。每個任務(wù)都包括：同步要同步的倉庫，生成同步任務(wù)的時間。如果此倉同步狀態(tài)已經(jīng)為已同步，則不做同步操作，任務(wù)完成。執(zhí)行同步操作成功，如果生成同步任務(wù)的時間大于等于倉庫狀態(tài)數(shù)據(jù)中為 同步的時間，則標注狀態(tài)為已同步+當前時間，同步完成。執(zhí)行同步操作失敗，則把此任務(wù)重新插入任務(wù)隊列。

另外，各個后端上都運行有資源檢查守護進程，此進程間隔(可以默認為1天)上報本后端storeage free、cpu idle、mem free，并且定期(可以默認為5秒)更新本后端的alive狀態(tài)，同時搶注自己為maser。

每次上報完本后端的資源使用情況后，更新本后端所在后端組的資源使用情況：更新本后端組的storage Free，為本組中最小后端的storageFree。更新所有活的后端的CPU Idle的平均值。更新所有活的后端的MeM Free的平均值。

各個后端中的后端Daemon定期更新本后端的存活狀態(tài)，并且競爭成為Master。原則上Master保持穩(wěn)定，競爭成功的后端會長期保持為Master，直到該后端發(fā)生故障(硬件故障、網(wǎng)絡(luò)故障等等)或者運維人員的主動切換、關(guān)機時才會發(fā)生Master的切換。切換的原理是當前一個Master的Key在Redis中過期后，第一個通過Redis的SETNX操作設(shè)置自己為Master的后端會操作成功，其余的后端會因為鍵值已存在而搶注失敗。

在Master切換成功后，新Master應(yīng)將自己所有倉的同步狀態(tài)設(shè)置為已同步(僅僅設(shè)置Redis中的同步狀態(tài)，不做真正的GIT同步)。為了保證可靠性，在設(shè)置同步狀態(tài)期間，新Master應(yīng)將自己節(jié)點的在線狀態(tài)暫時設(shè)置“下線”，并且拒絕這段時間的所有寫操作(SSH直接斷開連接，Web顯示維護中)。當完成所有倉的同步狀態(tài)設(shè)置完成后，將Master節(jié)點的在線狀態(tài)設(shè)置為“上線”。

下面參考圖5描述根據(jù)本發(fā)明另一個實施例的用于控制Git中央倉庫的控制方法500。該控制方法涉及到如何在包括多個倉庫中心的分布式Git中央倉庫之間同步數(shù)據(jù)(例如計算機軟件代碼)的方法。

如圖5所示，在步驟501，首先接收來自用戶的對所述多個倉庫中心中的一個倉庫中心執(zhí)行更新的指令。該更新指令例如計算機軟件代碼的修改、刪除、添加、合并等等。

在接收到該用戶指令后，可選地，可以進行用戶身份或者權(quán)限校驗。如果校驗通過，則繼續(xù)進行以下步驟。

接下來，在步驟502，按照該用戶指令，更新所述一個倉庫中心。例如修改、刪除、添加、合并計算機軟件代碼。

接下來，在步驟503，根據(jù)步驟502，對所述多個倉庫中心中的其他倉庫中心執(zhí)行同步操作，使得所述其他倉庫中心與該倉庫中心同步，保持各個倉庫中心之間數(shù)據(jù)的一致性。

根據(jù)該實施例的一個變形，對所述多個倉庫中心中的其他倉庫中心執(zhí)行同步操作之前，將所述其他倉庫中心的同步狀態(tài)標記設(shè)置為“未同步”，并且在對所述多個倉庫中心中的其他倉庫中心執(zhí)行同步操作之后，將所述其他倉庫中心的同步狀態(tài)標記設(shè)置為“已同步”。

根據(jù)該實施例的一個變形，使用標準Git協(xié)議來執(zhí)行所述同步操作。

根據(jù)該實施例的一個變形，還包括：當接收到用戶對所述多個倉庫中心中的一個倉庫中心執(zhí)行讀取指令時，若所述一個倉庫中心的同步狀態(tài)標記為“未同步”，則讀取其他的同步狀態(tài)標記為“已同步”的倉庫中心的數(shù)據(jù)。

使用本發(fā)明，如果用戶有多個研發(fā)中心，則可以輕松的實現(xiàn)倉庫在各個研發(fā)中心的備份。同時保證位于同一個研發(fā)中心的用戶在讀倉庫的時候，使用在本研發(fā)中心網(wǎng)絡(luò)中的倉庫備份。這大大提高了用戶讀倉庫的速度，減少了網(wǎng)絡(luò)延遲和網(wǎng)絡(luò)流量。另外，基于dRuby的Git遠程調(diào)用，使得遠程調(diào)用性能和可維護性大大的提高，使系統(tǒng)更加穩(wěn)定。

雖然參照示例性實施例對本發(fā)明進行了描述，但是應(yīng)當理解，本發(fā)明不限于所公開的示例性實施例。應(yīng)當對所附權(quán)利要求的范圍給予最寬的解釋，以使其涵蓋所有這些變型例以及等同的結(jié)構(gòu)和功能。