CN106326372A - Git central warehouse management system and control method - Google Patents
Git central warehouse management system and control method Download PDFInfo
- Publication number
- CN106326372A CN106326372A CN201610665962.8A CN201610665962A CN106326372A CN 106326372 A CN106326372 A CN 106326372A CN 201610665962 A CN201610665962 A CN 201610665962A CN 106326372 A CN106326372 A CN 106326372A
- Authority
- CN
- China
- Prior art keywords
- warehouse
- center
- git
- rear end
- centers
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/176—Support for shared access to files; File sharing support
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/544—Remote
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention provides a Git central warehouse management system and a method. The Git central warehouse management system comprises a plurality of rear ends, a front end and a synchronous module, wherein the plurality of rear ends comprise a local rear end and other remote rear ends and are used for storing warehouses; the front end is used for accessing the warehouses at the rear ends by remote calling; the synchronous module is used for enabling the warehouses stored at the plurality of rear ends to be synchronized.
Description
Technical field
The present invention relates to field of computer technology, manage system particularly to a kind of distributed multicenter Git central repository
And control method.
Background technology
Popular along with distributed source code management instrument Git, occur in that GitHub, GitLab, OSC, Coding,
The central repository management software of the Git such as GitCoffee.Central repository manages owing to store substantial amounts of code storehouse, so to solve
The problem that the certainly extendible problem of memory capacity, and multiple research and development centres cross-region accesses.
Existing central repository management system, with Gitlab as representative, major part all employ distributed file system
(DFS) as the means of warehouse capacity extension.Distributed file system can with dynamic expansion capacity, but, due to Git warehouse by
Large amount of small documents forms, and distributed file system is unsuitable for the scene of substantial amounts of small documents storage, so storage efficiency is low,
IO readwrite performance is poor.Therefore, the application of distributed file system causes huge limit to the performance of central repository management system
System (seeing Fig. 1).
It addition, during the management of existing central repository is, with GitHub as representative, employ the mode of AM/BAM far call
Carry out extension storage capacity.This mode solves capacity dynamic expansion, but GitHub employs before rear end RT-PRC realizes
The far call (seeing Fig. 2) of rear end.
Rear end RT-RPC uses Erlang, by self-defining serializing mode, it is possible to achieve multiple object oriented language
Object serialization, it is possible to realize the far call of Ruby.But, this needs programmer oneself to define service interface and Ruby
Object map, which increases the complexity of distributed back-end realization and maintenance.
It addition, whether Gitlab, or Github, the most do not solve the problem that multiple research and development centres cross-region accesses.
And, in the case of there is multiple research and development centre in a company, if central repository is located in one of research and development centre, then other
Research and development centre accesses owing to network delay can be caused relatively big through wide area network, and network traffics increase severely.
Summary of the invention
For problem above, it is an object of the invention to provide a kind of read and write abruption, multiple research and development centres can visit in strange land
The distributed multicenter Git central repository management system asked.
For realizing object above, the present invention provides techniques below scheme:
A kind of Git central repository management system, comprising: multiple rear end, it includes local rear end and other remote back-end,
The plurality of rear end is used for storage repository；Front end, it for accessing the warehouse on rear end by far call；And synchronization mould
Block, it synchronizes for making the warehouse of storage on the plurality of rear end.
The beneficial effects of the present invention is:
The present invention uses dRuby to achieve the Ruby remote access in Git warehouse, solves capacity dynamic in Git warehouse
The problem that scaling problem and multiple research and development centres cross-regions access, is greatly improved read or write speed simultaneously, reduce based on
The complexity in Ruby program exploitation distribution Git warehouse, and improve systematic function；The invention also achieves multicenter Git storehouse
The synchronization in storehouse, reaches read and write abruption, improves multiple research and development centre and accesses the network speed of central warehouse.
Accompanying drawing explanation
Fig. 1 is that existing employing DFS mode is to realize the schematic diagram of capacity extension.
Fig. 2 is that existing employing is distributed calls the schematic diagram realizing capacity extension.
Fig. 3 is the schematic diagram of the distributed multicenter Git central repository management system of the present invention.
Fig. 4 is the schematic flow sheet of the Git far call based on dRuby of the present invention.
Fig. 5 is the figure describing the control method for controlling Git central repository.
Detailed description of the invention
Below, referring to the drawings the specific embodiment of the present invention is described further, it is noted that, following example are to this
Bright it is merely an illustrative, and is in no way intended to limit the scope of the present invention.
As it is shown in figure 1, realize the schematic diagram of capacity extension for existing employing distributed file system (DFS) mode.
Wherein, shared resource resides in each Shared Folders on multiple servers, and DFS mode is not suitable for substantial amounts of little literary composition simultaneously
The scene of part storage.
As in figure 2 it is shown, call, for existing employing is distributed, the schematic diagram realizing capacity extension.Wherein, GitHub makes
Carry out extension storage capacity by the mode of AM/BAM far call, it use rear end RT-PRC and remotely adjust to realize AM/BAM
With, this needs programmer oneself to define service interface and Ruby object map, adds distributed back-end realization and maintenance
Complexity.
For Ruby language, after 1.9.3 version, inside it, achieve dRuby module, it is achieved distributed remote is adjusted
With, dRuby uses the agreement oneself defined, it is not necessary to any external protocol can be achieved with coding so that far call program is more
Easily write and safeguard.The proxy mechanism of dRuby employs caching to greatest extent simultaneously, improves systematic function.
Therefore, the present invention directly uses dRuby to realize far call so that systemic-function and performance have and carry the most greatly
High.
Below with reference to Fig. 3, the most distributed multicenter Git central repository management system is described
10.The schematic diagram of the distributed multicenter Git central repository management system 10 of the present invention is shown such as Fig. 3.Wherein, the present invention
Distributed multicenter Git central repository management system 10 includes multiple rear end 101, and it is used as data burner storehouse, such as, store
Code.The plurality of rear end 101 is distributed in multiple center.The embodiment of Fig. 3 has Liang Ge center, the most main center 100
With branch center 110.It should be readily apparent to one skilled in the art that the distributed multicenter Git central repository management system of the present embodiment
10 centers can with more than two.And main center and branch center are the most not restrictive, and the status at multiple centers can
To be equality.Illustrate as a example by main center 100 and branch center 110 below.
Shown in Fig. 3, main center 100 and branch center 110 carry out communication by wide area network.But those skilled in the art are easy
Understand, the invention is not restricted to this.Wired or wireless personal area network (PAN), office such as can be passed through in main center 100 and branch center 110
Territory net (LAN), Metropolitan Area Network (MAN) (MAN), etc. carry out communication.
According to a preferred embodiment, main center 100 and branch center 110 include the rear end 101 of equal number, the most all wrap
Include rear end BE1, BE2 and BE3.The rear end at main center is the most corresponding.Rear end BE1, BE2 and BE3 of such as branch center 110 are respectively
The mirror image of rear end BE1, BE2, the BE3 at Shi Zhu center.
In the embodiment of Fig. 3, main center 100 also includes front end (FE) 102, and branch center 110 also includes front end 112.Front end
102 and 112 users being available for main center 100 and branch center 110 respectively access nearby.Due to the rear end at main center and branch center
Rear end stores the mirror image of data or data respectively, and therefore user can access the front end of locality nearby, reduces network delay
And network traffics, it is greatly improved user and reads the speed in warehouse.
User can also be accessed and carry out scope check by front end 102,112, such as, confirm whether user has this center
Carry out the authority of read and/or write, and carry out next step operation, such as refusal user visit according to the result of scope check
Ask, or be written and read operating to rear end according to the request of user.
In distributed multicenter Git central repository management system 10 in Fig. 3 embodiment, main center 100 may also include road
By module 103, branch center 110 may also comprise routing module 113.Routing module 103 and 113 has corresponding front end 102,112 to adjust
With, the rear end of code needed for have user according to the storage of routing rule location.It should be readily apparent to one skilled in the art that for master
Center 100 and branch center 110, routing module is the most not necessarily.Such as front end 102 and 112 can be respectively provided with query function, root
Corresponding rear end is inquired according to user's input.But when amount of storage is big, rear end number is many when, it is preferred for having routing module
, because arranging the routing rule of optimization, it is possible to reduce inquire about, position required time cost, improve user experience quality.
In distributed multicenter Git central repository management system 10 in Fig. 3 embodiment, main center 100 also includes synchronizing
Module 104, branch center 110 also includes synchronization module 114.
It will be appreciated by those skilled in the art that the distributed multicenter Git central repository management system 10 of the present embodiment also can be wrapped
Include a unified synchronization module, rather than include single synchronization module in the heart in each.Wrap respectively with each center below
Illustrate as a example by including respective synchronization module.
Synchronization module 104 and 114 is for synchronizing storage data and the operation of the rear end of main center 100 and branch center 110.Its
In, the synchronization module 104 at main center 100 is by state synchronized service creation synchronization job；The synchronization module 114 of branch center 110
Serviced by state synchronized and synchronize the main synchronization job being centrally generated, and update synchronous regime.Such as when main center 100
When rear end BE1 receives write operation, synchronization module 104 and 114 can carry out data syn-chronization, updates the rear end of branch center 110
The data of BE1.Equally, when the rear end BE2 of branch center 110 receives write operation, synchronization module 104 and 114 can be carried out
Data syn-chronization, updates the data of the rear end BE2 at main center 110.The Git of standard can be used between synchronization module 104 and 114
Agreement.Therebetween synchronization can be real-time, such as when the Back end data of in main center 100 and branch center 110
When being updated, automatically trigger synchronization.Therebetween synchronization can also be non real-time, and such as timing updates.Can also basis
Real needs and set certain synchronization rules.
At each center, user can be accessed and carry out scope check by front end, when confirming that user has the read-write power of correspondence
In limited time, routing module is called.Routing module, according to routing rule, finds the rear end at place, warehouse, then to use RPC far call
This rear end, such user can access the warehouse content being positioned at this rear end.
It addition, according to a preferred embodiment of the present invention, the front end 112 of branch center 110 can access main center 100
Rear end.Otherwise, the front end 102 at main center 100 can also access the rear end of branch center 110.The most such as main center 100 and point
When not yet synchronizing between center 110, it is also possible to ensure that user can access up-to-date data.The most main center 100 and point
Center 110 is equipped with synchronous regime labelling, such as, can be " synchronizing " or " synchronization ".Such as behind main center 100
In the case of end has been updated, producing simultaneously operating by front end, be sent to state synchronized module, state synchronized module is led to
Cross state synchronized service creation synchronization job, and point out synchronize this synchronization job to all branch centers；Simultaneously by all points
The synchronous regime at center is set to not synchronize.
Main center described separately below and the read/write operation of branch center.
When user performs write operation at main center, first, user sends Git write operation order, and this order is sent to
Lacal Head End.Secondly, routing module is called in front end, and routing module, according to routing rule, searches warehouse in the rear end residing for this locality；
Then front end uses this rear end of RPC far call, and content is write rear end.Then, front end produces simultaneously operating, is sent to state
Synchronization module, state synchronized module is passed through state synchronized service creation synchronization job, and is pointed out synchronize to all branch centers
This synchronization job；It is set to not synchronize by the synchronous regime of all branch centers simultaneously.Finally, each branch center state synchronized module
By Git agreement, synchronize the Git storehouse at main center.After each branch center completes to synchronize, the synchronous regime of self is set to
Synchronize.In described far call, in addition to dRuby, it is also possible to use the far call agreements such as xmlrpc, thrift.
Then, when user performs read operation in branch center, first, user sends Git write-read order, this order quilt
It is sent to Lacal Head End.Then, the synchronous regime at this center is checked in front end, checks that synchronous regime is to have synchronized or do not synchronized.
If state is to have synchronized, then routing module is called in front end, and routing module, according to routing rule, searches warehouse residing for this locality
Rear end；Then front end uses RPC far call to access the warehouse content on rear end, returns to client.If state is not synchronize,
Then routing module is called in front end, and routing module, according to routing rule, searches warehouse in the rear end residing for main center；Then front end makes
Access the warehouse content on rear end with RPC far call, return to client.In described far call, in addition to dRuby,
The far call agreements such as xmlrpc, thrift can also be used.
So, when the user of branch center reads warehouse, front end, branch center first checks synchronous regime.If synchronous regime is
Synchronize, then access local rear end.If synchronous regime is not for synchronize, then access main center back end.Hereby it is achieved that complete in this locality
Read operation, alleviates network delay significantly.
When user performs write operation in branch center, performing write operation similarly with at main center, first, user sends
Git write operation order, this order is sent to Lacal Head End.Secondly, routing module is called in front end, and routing module is according to route rule
Then, searching the rear end at place, warehouse, then front end uses this rear end of RPC far call, and content is write rear end.Then, front end
Produce simultaneously operating, be sent to state synchronized module, state synchronized module pass through state synchronized service creation synchronization job, and to
Main center points out synchronize this synchronization job.Finally, main center situation synchronization module passes through Git agreement, synchronizes branch center
Git storehouse.In described far call, in addition to dRuby, it is also possible to use the far call agreements such as xmlrpc, thrift.
When user performs read operation at main center, first, user sends Git write-read order, and this order is sent to
Lacal Head End.Secondly, routing module is called in front end, and routing module, according to routing rule, searches warehouse after residing for main center
End.Then, front end uses RPC far call to access the warehouse content on rear end, returns to client.In described far call,
In addition to dRuby, it is also possible to use the far call agreements such as xmlrpc, thrift.
Wherein, when user performs write operation in branch center, write operation can be write the rear end of multiple branch center together,
As such, it is possible to perform read-write operation in multiple branch centers, it is achieved polycentric read and write abruption.Such as, user is a branch center
When performing write operation, it can write multiple branch center together, then, user can in the plurality of branch center any one
Person performs read-write operation, thus reaches read and write abruption.
From above content, at any time, when user submits code to (when performing write operation), all can be written into
To main center.It is positioned at the content in all warehouses of each rear end, at the center of its correspondence, has a full backup.
Below, as a example by before and after the web access realizing Git warehouse based on dRuby, platform separates, long-range to the present invention
The process called illustrates.
As shown in Figure 4, for the schematic flow sheet of Git far call based on dRuby of the present invention.Wherein, in one
The heart, user is accessed and carries out scope check, after confirming that user is authorized to, call routing module, according to routing rule, sends out by front end
The rear end at existing place, warehouse, then uses RPC far call to access the warehouse content being positioned on rear end.Web logic uses Ruby
Language development, for Git warehouse, encapsulates corresponding RubyGitObject to access Git depot data.
In order to realize remotely accessing the Git warehouse on other-end, first, place, Git warehouse main frame (rear end) starts to be made
First a group interface is provided as DrbClient, DrbServer for DrbServer, Web logic place main frame (front end), it is allowed to
DrbClient, according to the title in warehouse, accesses the content of opposite depot.DrbServer according to the feature of RubyGitObject,
Return two kinds of Object.A kind of object for Re front end rence type, the object of this type return to client
After, as an agency, the DrbObject of agency to server side, method call, is all once to remotely access the most every time.
Another kind is the object of Value type, and the object of this type returns RubyGitObjects, wherein comprises required Git
Depot data.
Feature according to RubyGitObjects, it is achieved for having of Re front end rence type: repository, blame,
MergeRepo、OnlineEdit.Be embodied as Value type has blob, commit, tree, diff, tag.DrbInterface
Object by the Front Object as Server, uses Ruby's as the object of a Re front end rence type
Method_missing mechanism, provides other all GitObject to map between client and server.
It addition, in order to realize multicenter read and write abruption, present invention employs state synchronized module, state synchronized module is passed through
Use state synchronized services, it is achieved state and the synchronization of operation, and is achieved in read and write abruption.
Below, the detailed process realizing operation and state synchronized between multiple centers of the present invention is specifically introduced.
First, routing data structure is introduced.Wherein, each center uses and shares Redis and store all of warehouse, rear end
Warehouse route and Synchronization Status Message.
Warehouse route preserves location and backendCluster at place, warehouse.In redis, exist entitled
The Hash table of repoMap preserves all of warehouse route.The Key of this Hash table is the path (username/repo) of repo,
It is worth the rear end group (locationName_backendClusterName, e.g.BJ_backendCluster1) for its storage.
Status data preserves the Synchronization Status Message of the rear end at place, warehouse.The state of the rear end at each place, warehouse, uses
The Hash table of entitled repoPath_syncStatus preserves.The key of this Hash table is IP, is worth for " state&time ".Its
In, when the current value of State is 0, represents and do not synchronize；Value is to represent when 1 to synchronize.
When the system is initiated, routing iinformation is empty, when establishment of item, generates routing iinformation.The status information of project
Generate when establishment of item, and the status information of project only can change according to write state, but will not disappear.
Rear end in the group of group set record each rear end, rear end: use and collect incompatible preservation, set entitled
LocationName_backendClusterName_hosts, is worth the IP for rear end.
The Maser member of rear end group be effective time be the character string of 5 seconds (can configure), key form is,
LocationName_backendClusterName_master, value is the IP of master.
The existing state of rear end group membership is had expired time (can configure) integer value to represent by one, and key is IP_alive,
Value is 1.If there is then representing alive, there is not expression and do not live.
Rear end group resource is respectively as follows:
location_backendCluser1_storageFree:integer
location_backendCluser1_cpuIdle:integer
location_backendCluser1_memFree:integer。
Rear end member resource is respectively as follows:
ip1_cpuIdle:integer；
ip1_memFree:integer；
ip1_storageFree:integer。
Rear end membership synchronization's queue is ip1_queue:tasks.
Below, describing the process in warehouse new for generation/import/Fork, it comprises the following steps:
A) according to the resource service condition of in the heart each backendCluster in master, selects one backendCluster guarantor
Deposit this project.
B) front end is by generating project on gitlab_git_client to main rear end.
C) warehouse route is generated.
D) corresponding in backendCluster main rear end and from rear end.For main rear end (the most main center back end), generate
Warehouse state data for synchronizing+time at that time.For from rear end (i.e. rear end, branch center), it is not same for generating warehouse state data
Step+time at that time.
E), after project generates successfully, front end adds synchronous task all of from rear end (regardless of existing state), it is desirable to
From rear end from main backend synchronization project.
F) synchronized process from rear end reads the synchronous task from rear end, completes to synchronize, more New Warehouse shape after completing
State data for synchronizing+time at that time.
Below, the process in page amendment warehouse is described, comprising: front end (gitlab_git_client) searches route letter
Breath, searches the backendCluster at place, warehouse.Obtain the master of this backendCluster.Gitlab_ is passed through in front end
Git_client to master write operation.After having write, the hooks function on master, it is responsible for all of from rear end
Middle interpolation synchronous task, it is desirable to from rear end from main backend synchronization project, is set to all of synchronous regime from node not simultaneously
Synchronization+timestamp.Synchronized process from rear end reads the synchronous task from rear end, completes to synchronize, more New Warehouse after completing
Status data for synchronizing+time at that time.
When the page reads warehouse, front end (gitlab_git_client) searches routing iinformation, searches place, warehouse
backendCluster.The state of each rear end according to backendCluster, selects one to read rear end.Front end is passed through
Gitlab_git_client is to read operation on the rear end selected.
During backend synchronization, each rear end all being run multiple synchronized process (can configure), synchronized process monitors location_
Task on backendCluser1_ip1_queue:tasks, completes the synchronization in warehouse according to task.Each task includes:
The warehouse that synchronization is to be synchronized, generates the time of synchronous task.If this storehouse synchronous regime has been to synchronize, the most it is not synchronization behaviour
Making, task completes.Execution simultaneously operating is successful, if the time generating synchronous task more than or equal in warehouse state data is
The time synchronized, then mark state is for synchronize+current time, synchronously completes.Execution simultaneously operating failure, then this task weight
Newly inserted task queue.
It addition, all run resource on each rear end to check that finger daemon, this process interval (can be defaulted as 1 day) report
This rear end storeage free, cpu idle, mem free, and periodically (can be defaulted as 5 seconds) updates this rear end
Alive state, rushes to register oneself for maser simultaneously.
After having reported the resource service condition of this rear end, update the resource service condition of this rear end, place, rear end group every time:
Update the storage Free of this rear end group, for the storageFree of rear end minimum in this group.Update the rear end of all work
The meansigma methods of CPU Idle.Update the meansigma methods of the MeM Free of the rear end of all work.
The existing state of this rear end of Daemon regular update, rear end in each rear end, and compete become Master.Former
Then go up Master and keep stable, compete successful rear end and can remain Master for a long time, (the hardware event until breaking down in this rear end
Barrier, network failure etc.) or the switching of Master just can occur when the active switching of operation maintenance personnel, shutdown.The principle of switching
It is when the Key of previous Master crosses after date in Redis, and first is by the SETNX operation setting oneself of Redis
The rear end of Master can operate successfully, and failure can be rushed to register because key assignments exists in remaining rear end.
After Master handover success, the synchronous regime in oneself all storehouse should be set to (only synchronize by new Master
Synchronous regime in Redis is set, is not real GIT and synchronizes).In order to ensure reliability, during synchronous regime is set, newly
The presence of oneself node should temporarily be arranged " rolling off the production line " by Master, and (SSH is straight to refuse all write operations during this period of time
Connect and disconnect, during Web display is safeguarded).After the synchronous regime completing all storehouses is provided with, online by Master node
State is set to " reaching the standard grade ".
Describe in accordance with another embodiment of the present invention for controlling the control method of Git central repository below with reference to Fig. 5
500.This control method involves how to synchrodata (example between the distributed Git central repository including center, multiple warehouse
Such as computer software code) method.
As it is shown in figure 5, in step 501, first receive from user to a warehouse in the minds of in the plurality of warehouse
Center performs the instruction updated.This renewal instruct such as computer software code amendment, delete, add, merging etc..
After receiving this user instruction, it is alternatively possible to carry out user identity or authorization check.If verification is logical
Cross, then proceed following steps.
It follows that in step 502, according to this user instruction, update center, one warehouse.Such as revise, delete, add
Add, joint account machine software code.
It follows that in step 503, according to step 502, other centers, warehouse in the minds of in the plurality of warehouse are performed same
Step operation so that other centers, warehouse described and this warehouse central synchronous, keeps the concordance of data between each center, warehouse.
A deformation according to this embodiment, performs simultaneously operating to other centers, warehouse in the minds of in the plurality of warehouse
, the synchronous regime labelling at other centers, warehouse described is set to " synchronization " before, and to center, the plurality of warehouse
In other centers, warehouse perform after simultaneously operating, the synchronous regime labelling at other centers, warehouse described is set to " with
Step ".
A deformation according to this embodiment, uses standard Git agreement to perform described simultaneously operating.
A deformation according to this embodiment, also includes: when receive user to the plurality of warehouse in the minds of one
When center, warehouse performs to read instruction, if the synchronous regime at center, one warehouse is labeled as " synchronization ", then read other
Synchronous regime be labeled as the data at center, warehouse of " synchronizing ".
Use the present invention, if user has multiple research and development centre, then can realize warehouse easily in each research and development centre
Backup.Ensure that the user being positioned at same research and development centre, reading warehouse when, uses in this research and development centre network simultaneously
Warehouse backup.Which greatly enhances user and read the speed in warehouse, decrease network delay and network traffics.It addition, based on
The Git far call of dRuby so that remote invocation performance and maintainability are greatly improved, makes system more stable.
Although with reference to exemplary embodiment, invention has been described, but it is to be understood that the invention is not restricted to institute public
The exemplary embodiment opened.Scope of the following claims should be given the widest explanation, so that it contains all these change
Type example and the 26S Proteasome Structure and Function of equivalent.
Claims (16)
1. a Git central repository management system, comprising:
Center, multiple warehouse, in the plurality of warehouse in the minds of center, each warehouse be respectively provided with one or more rear end；
Synchronization module, in the plurality of warehouse in the minds of the rear end at center, warehouse when being updated, described synchronization module with
Step updates the rear end at other centers, warehouse in the minds of in the plurality of warehouse.
Git central repository the most according to claim 1 management system, wherein, in the plurality of warehouse in the minds of each storehouse
Center, storehouse include front end, described front end be used for providing a user with access interface and can access described rear end read carrying out and/or
Write operation.
Git central repository the most according to claim 2 management system, wherein, in the plurality of warehouse in the minds of described in
When the rear end at center, one warehouse is updated, the front end at center, one warehouse is called described synchronization module and is synchronized institute to update
State the rear end at other centers, warehouse.
4. manage system, wherein, center, the plurality of warehouse according to the Git central repository according to any one of claim 1-3
In one or more routing modules that also include, described routing module is called by described front end, for according to routing rule position
Storage has the rear end of code needed for user.
5. manage system, wherein, center, described each warehouse according to the Git central repository according to any one of claim 1-4
All there is described synchronization module, between the synchronization module at center, warehouse, use standard Git protocol.
6. manage system, wherein, center, the plurality of warehouse according to the Git central repository according to any one of claim 1-5
In the front end at center, a warehouse can access the rear end at other centers, warehouse in the minds of in the plurality of warehouse.
7. manage system, wherein, center, described each warehouse according to the Git central repository according to any one of claim 1-6
There is synchronous regime labelling to reflect the more new state at this center, warehouse.
Git central repository the most according to claim 7 management system, wherein, when the rear end quilt at center, one warehouse
During renewal, the synchronous regime labelling at other centers, warehouse described is set to " the most more by the synchronization module at center, one warehouse
Newly ".
Git central repository the most according to claim 8 management system, wherein, when the rear end quilt at other centers, warehouse described
After renewal, the synchronous regime labelling at other centers, warehouse described is set to " updating ".
10. manage system according to the Git central repository according to any one of claim 1-6, wherein, when to one warehouse
When center performs write operation, the front end at center, one warehouse produces the simultaneously operating of described write operation and synchronizes behaviour by described
Being sent to the synchronization module at center, one warehouse, the described synchronization module at center, one warehouse is to other storehouses described
Warehouse on the rear end at center, storehouse performs described simultaneously operating so that the warehouse on the rear end at other centers, warehouse described and this storehouse
Storehouse synchronizes.
11. manage system according to the Git central repository according to any one of claim 1-10, and wherein, described front end uses
DRuby far call agreement.
12. manage system according to the Git central repository according to any one of claim 2-11, and wherein, described front end is to user
Access carries out scope check.
13. 1 kinds of control methods for Git central repository, described Git central repository includes center, multiple warehouse, described method
Including:
Receive the instruction that center, the warehouse execution in the minds of in the plurality of warehouse is updated from user；
Update center, one warehouse；
Other centers, warehouse in the minds of in the plurality of warehouse are performed simultaneously operating so that other centers, warehouse described are with described
One warehouse central synchronous.
14. methods according to claim 13, also include: to other centers, warehouse described in the minds of in the plurality of warehouse
Before performing simultaneously operating, the synchronous regime labelling at other centers, warehouse described is set to " synchronization ", and to described
After other centers, warehouse described in the minds of in multiple warehouses perform simultaneously operating, by the synchronous regime at other centers, warehouse described
Labelling is set to " synchronizing "..
15. according to the method according to any one of claim 13-14, wherein, uses standard Git agreement to perform described synchronization
Operation.
16. according to the method according to any one of claim 13-15, also include: when receiving user to the plurality of warehouse
When center, a warehouse in the minds of in performs the instruction read, if the synchronous regime at center, one warehouse is labeled as " not same
Step ", then read the data that synchronous regime is labeled as the center, warehouse of " synchronizing ".
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610665962.8A CN106326372A (en) | 2016-08-12 | 2016-08-12 | Git central warehouse management system and control method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610665962.8A CN106326372A (en) | 2016-08-12 | 2016-08-12 | Git central warehouse management system and control method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN106326372A true CN106326372A (en) | 2017-01-11 |
Family
ID=57739346
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610665962.8A Pending CN106326372A (en) | 2016-08-12 | 2016-08-12 | Git central warehouse management system and control method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106326372A (en) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106899588A (en) * | 2017-02-22 | 2017-06-27 | 郑州云海信息技术有限公司 | It is a kind of to be applied to the program adaptive environment that multiterminal coexist and build system |
| CN109815646A (en) * | 2019-01-30 | 2019-05-28 | 上海易点时空网络有限公司 | Code administration method and device |
| CN111309369A (en) * | 2018-12-12 | 2020-06-19 | 北京奇虎科技有限公司 | Code management method and device based on Git code warehouse |
| CN111666045A (en) * | 2020-05-15 | 2020-09-15 | 深圳市大富网络技术有限公司 | Data processing method, system, equipment and storage medium based on Git system |
| CN112966065A (en) * | 2021-05-10 | 2021-06-15 | 炬星科技（深圳）有限公司 | Navigation map data management method, navigation map data management device, and storage medium |
| CN114466013A (en) * | 2021-12-22 | 2022-05-10 | 天翼云科技有限公司 | Code management method, system, device and storage medium based on Git |
| CN117454856A (en) * | 2023-12-22 | 2024-01-26 | 达州爱迦飞诗特科技有限公司 | Medical diagnosis data editing method and system based on-line point-to-point mode |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103729195A (en) * | 2014-01-15 | 2014-04-16 | 北京奇虎科技有限公司 | Control method and system for software version |
| CN104899047A (en) * | 2015-06-25 | 2015-09-09 | 广州杰赛科技股份有限公司 | Webpage frame deployment method and system |
-
2016
- 2016-08-12 CN CN201610665962.8A patent/CN106326372A/en active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103729195A (en) * | 2014-01-15 | 2014-04-16 | 北京奇虎科技有限公司 | Control method and system for software version |
| CN104899047A (en) * | 2015-06-25 | 2015-09-09 | 广州杰赛科技股份有限公司 | Webpage frame deployment method and system |
Non-Patent Citations (1)
| Title |
|---|
| 王文龙: ""分布式软件开发平台的设计与实施"", 《中国优秀硕士学位论文全文数据库 信息科技辑》 * |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106899588A (en) * | 2017-02-22 | 2017-06-27 | 郑州云海信息技术有限公司 | It is a kind of to be applied to the program adaptive environment that multiterminal coexist and build system |
| CN111309369A (en) * | 2018-12-12 | 2020-06-19 | 北京奇虎科技有限公司 | Code management method and device based on Git code warehouse |
| CN111309369B (en) * | 2018-12-12 | 2024-03-29 | 北京奇虎科技有限公司 | Code management method and device based on Git code warehouse |
| CN109815646A (en) * | 2019-01-30 | 2019-05-28 | 上海易点时空网络有限公司 | Code administration method and device |
| CN111666045A (en) * | 2020-05-15 | 2020-09-15 | 深圳市大富网络技术有限公司 | Data processing method, system, equipment and storage medium based on Git system |
| CN112966065A (en) * | 2021-05-10 | 2021-06-15 | 炬星科技（深圳）有限公司 | Navigation map data management method, navigation map data management device, and storage medium |
| CN114466013A (en) * | 2021-12-22 | 2022-05-10 | 天翼云科技有限公司 | Code management method, system, device and storage medium based on Git |
| CN117454856A (en) * | 2023-12-22 | 2024-01-26 | 达州爱迦飞诗特科技有限公司 | Medical diagnosis data editing method and system based on-line point-to-point mode |
| CN117454856B (en) * | 2023-12-22 | 2024-04-16 | 达州爱迦飞诗特科技有限公司 | Medical diagnosis data editing method and system based on-line point-to-point mode |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106326372A (en) | Git central warehouse management system and control method | |
| CN101741911B (en) | Multi-copy collaboration-based write operation method, system and node | |
| CN104539681B (en) | The processing method of distributed GIS acceleration systems and GIS service | |
| CN101019105B (en) | Method and apparatus for data storage using striping | |
| CN102244685B (en) | Distributed type dynamic cache expanding method and system for supporting load balancing | |
| CN102693324B (en) | Distributed database synchronization system, synchronization method and node management method | |
| CN106713391B (en) | Session information sharing method and sharing system | |
| CN104935634B (en) | Mobile device data sharing method based on Distributed shared memory | |
| CN103473696A (en) | Method and system for collecting, analyzing and distributing internet business information | |
| TW200400444A (en) | System and method for accessing different types of back end data stores | |
| JPS6170654A (en) | Resource control system of decentralized processing system | |
| CN102855239A (en) | Distributed geographical file system | |
| CN102780724A (en) | Sending method, sending system and sending device for category information | |
| CN102866998A (en) | Centralized password management method and centralized password management system in synchronous system | |
| CN101317375A (en) | Network management data synchronous refreshing method, and client terminal and server terminal | |
| CN109684273A (en) | A kind of snapshot management method, apparatus, equipment and readable storage medium storing program for executing | |
| CN102207978A (en) | Database access method and system | |
| CN103533023A (en) | Cloud service application cluster synchronization system and synchronization method based on cloud service characteristics | |
| WO2016082594A1 (en) | Data update processing method and apparatus | |
| CN104281980A (en) | Remote diagnosis method and system for thermal generator set based on distributed calculation | |
| CN103491137A (en) | Data synchronizing system and data synchronizing method | |
| Panigrahi et al. | DATALET: An approach to manage big volume of data in cyber foraged environment | |
| CN102624932A (en) | Index-based remote cloud data synchronizing method | |
| CN117118742B (en) | Government affair data operation method and system based on access frequency monitoring | |
| CN204926097U (en) | Memory system is kept apart to data |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20190308 Address after: Room 205A, 2nd floor, No. 10 Jiuxianqiao Road, Chaoyang District, Beijing 100015 Applicant after: Beijing Innovation Lezhi Network Technology Co., Ltd. Address before: 10102 8th Floor, Building 6, 33 Guangshun North Street, Chaoyang District, Beijing Applicant before: Beijing Innovation Information Technology Co., Ltd. |
|
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20170111 |