CN115002121A - Method for realizing one-master multi-slave Git cluster based on preemption lock - Google Patents
Method for realizing one-master multi-slave Git cluster based on preemption lock Download PDFInfo
- Publication number
- CN115002121A CN115002121A CN202210924652.9A CN202210924652A CN115002121A CN 115002121 A CN115002121 A CN 115002121A CN 202210924652 A CN202210924652 A CN 202210924652A CN 115002121 A CN115002121 A CN 115002121A
- Authority
- CN
- China
- Prior art keywords
- node
- git
- follower
- leader
- cluster
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- 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/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/526—Mutual exclusion algorithms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Hardware Redundancy (AREA)
Abstract
The invention discloses a method for realizing a Git cluster with one master and multiple slaves based on a preemption lock, which comprises the following steps: s1, determining a working mode by nodes in the cluster through preemption lock; s2, updating the follower registry in the public storage at intervals of fixed time by the follower nodes, and cleaning the follower registry in the public storage at intervals of fixed time by all nodes in the cluster; s3, utilizing the leader node to actually process all the modification requests, and informing the follower node to keep version synchronization with the leader node in time; s4, actually processing a Git pull request initiated by an external node by using a follower node; wherein the cluster comprises a leader node and a follower node. The distributed Git cluster provided by the invention solves the problem of high availability, and after one node is down, the whole cluster can normally work, so that the problems of Git file loss, cluster unavailability and the like are avoided.
Description
Technical Field
The invention relates to the field of product development and delivery integration (DevOps), in particular to a method for realizing a Git distributed cluster with one master and multiple slaves based on a preemption lock.
Background
With the continuous Development of the digital transformation of the telecom operators, the business agility increasingly depends on the rapid iteration of the application, and the enterprise is helped to build a continuous delivery pipeline by introducing the concept of Development (combination of Development and Operations) to realize rapid value delivery. Configuration management is an important link in the DevOps process, configuration information is very important in production and test environments, and a configuration management server cluster is required to have no single-point problem, so that data cannot be lost and service can be quickly recovered when partial servers are down. The configuration can be rapidly and frequently modified, a large number of service hosts need to be rapidly synchronized after modification, and the server cluster needs to rapidly process highly concurrent pull requests.
Chinese patent with publication number CN109104333B discloses a distributed cluster synchronization method and apparatus based on GIT, which satisfy the high availability requirement of GIT nodes, but have the following disadvantages:
1. after the host is updated, the next updating operation can be processed only when all the standby machines are updated; one node is slow to update, which affects the processing speed of the whole cluster, and leads to the failure of timely processing of the update operation.
2. After the host is updated, the external machine synchronization is opened only when all the standby machines are updated; if the host needs frequent updating, the time window for updating the external machine is very small, which is not favorable for timely updating the external machine.
3. The standby machine node only exists as a standby machine and does not provide services to the outside. The method has low resource utilization efficiency, the cluster has performance bottleneck, and the concurrent pulling processing capacity of the cluster cannot be improved by increasing nodes.
An effective solution to the problems in the related art has not been proposed yet.
Disclosure of Invention
Aiming at the problems in the related art, the invention provides a method for realizing a Git cluster with one master and multiple slaves based on a preemption lock, so as to overcome the technical problems in the prior related art.
Therefore, the invention adopts the following specific technical scheme:
a method for realizing a Git cluster with one master and multiple slaves based on a preemption lock comprises the following steps:
s1, determining a working mode by nodes in the cluster through a preemption lock;
s2, updating the follower registry in the public storage at intervals of fixed time by the follower nodes, and cleaning the follower registry in the public storage at intervals of fixed time by all nodes in the cluster;
s3, utilizing the leader node to actually process all the modification requests, and informing the follower node to keep version synchronization with the leader node in time;
s4, actually processing a Git pull request initiated by an external node by using a follower node;
wherein the cluster comprises a leader node and a follower node.
Further, the step of determining the working mode of the nodes in the cluster through the preemption lock comprises the following steps:
s101: acquiring a distributed lock at fixed time intervals;
s102: judging the working mode of the current node, if the working mode is the leader mode, updating the effective time of the leader registration information, and entering S106; if yes, the follower node enters S103;
s103: detecting whether the registration information of the leader is valid, and if so, entering S106; if the result is invalid, the operation goes to S104;
s104: detecting whether the current node is qualified to become a leader, if so, entering S105, and if not, entering S106;
if the latest version submission time of the Git of the current node is equal to the latest version submission time of the cluster, the current node is qualified as a leader;
s105: converting the current node into a leader mode, updating leader registration information in public storage, and sending a broadcast message;
s106: the distributed lock is released.
Further, updating the follower registry in the common storage by the follower nodes at fixed time intervals comprises:
the key of the follower registry in the public storage is a node identifier;
the registry value contains a refresh time field.
Further, the cleaning up the follower registry in the public storage by using all nodes in the cluster at fixed time intervals comprises:
the cluster nodes comprise leader nodes and follower nodes;
traversing key value pairs in a follower registry by cluster nodes at intervals of fixed time;
and if the difference value between the refreshing time and the current date of the key value pair is larger than the preset value, deleting the key value from the registry.
Further, the step of actually processing all the modification requests by using the leader node and informing the follower node of keeping version synchronization with the leader node in time comprises the following steps:
the leader node receives the modification request, modifies the work area file according to the modification request, submits the Git library, updates the latest Git version information to the public storage and sends a broadcast message;
the follower node receives the broadcast notification and initiates a gitpull request to the leader node;
the follower node receives the modification request and forwards the modification request to the leader node for processing.
Further, the leader node receives the modification request, modifies the workspace file according to the modification request, submits the Git library, updates the latest Git version information to the public storage and sends the broadcast message, including the following steps:
extracting a modified file path and file content from the modification request;
updating the Git workspace file according to the modified file path and the modified content, and executing Git Add and Git Commit operations;
obtaining latest version information of Git;
updating the version information to leader registration information;
sending a broadcast message to inform a follower node;
replying to the caller;
wherein the version information includes a Git version number and a version commit time.
Further, the follower node receiving the broadcast notification and initiating a Git pull request to the leader node comprises the steps of:
receiving a broadcast notification;
acquiring the address of the current leader node from public storage;
adding a specific request header for the Git pull request, wherein the specific request header is used for identifying the request forwarded by the internal node of the cluster;
and initiating a Git pull request to the leader node, wherein the Git pull request pulls the latest version of the leader node and realizes version synchronization with the leader node.
Further, the following node receives the modification request and forwards the modification request to the leader node for processing, and the following steps are included:
receiving a modification request;
acquiring a current leader node address from public storage;
forwarding the modification request to a leader node for processing;
receiving a response message of the leader node;
and replying the modification result.
Further, the actual processing of the Git pull request initiated by the external node by the follower node comprises the following steps:
the leader node receives the Git pull request and determines a processing mode according to whether a specific request head is included;
the follower node receives the Git pull request, processes it directly, and does not need to forward it.
Further, the leader node receives the Git pull request, and determines a processing mode according to whether a specific request header is included, including the following steps:
step one, judging whether a specific request head is included, if the specific request head is included, the source is a follower node, entering step two, and if not, entering step three;
step two, processing the pulling request, and entering step six;
step three, the request source is an external node, a follower node list is obtained from public storage, and a node is selected by using a load balancing algorithm;
step four, forwarding the request to the selected follower node for processing;
step five, receiving the return of the follower node;
step six, replying the caller.
The invention has the beneficial effects that:
1. the distributed Git cluster provided by the invention solves the problem of high availability, and after one node is down, the whole cluster can normally work, so that the problems of Git file loss, cluster unavailability and the like are avoided.
2. Compared with the existing method for constructing the Git cluster, the method has the advantages that after the host is updated, the next updating operation can be processed only after all the standby machines are updated; one node is slow to update, which affects the processing speed of the whole cluster, and leads to the failure of timely processing of the update operation. The invention adopts the final consistency thought, and the leader node can immediately process the next updating request after updating the Git library, thereby having high updating efficiency and being capable of processing frequent updating requests.
3. The distributed Git cluster provided by the invention can process the pulling request of the external machine at any time, the pulling request of the external machine cannot be processed in the time window for executing the updating operation by the existing public Git cluster construction method, and the distributed Git cluster provided by the invention can process the pulling request of the external machine at any time and has stronger processing capability.
4. The distributed Git cluster provided by the invention can process highly concurrent pulling requests, and the standby nodes do not process the pulling requests in the existing public Git cluster construction method, so that the performance bottleneck exists; the follower nodes in the invention are specially used for processing the pull request, and the cluster processing capacity of high concurrent pull requests can be linearly improved by increasing the number of the follower nodes.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings needed in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.
FIG. 1 is a schematic block diagram of a method for implementing a Master-Multi-Slave Git cluster based on a preemption lock, according to an embodiment of the present invention;
FIG. 2 is a block diagram of a scenario of a method for implementing a Master-Multi-Slave Git cluster based on a preemption lock, according to an embodiment of the present invention;
FIG. 3 is a block diagram of node functional modules for a method for implementing a Master Multi-Slave Git Cluster based on preemption locks, according to an embodiment of the present invention;
FIG. 4 is a workflow diagram of the master preemption function of a method to implement a Master Multi-Slave Git cluster based on preemption locks in accordance with an embodiment of the present invention;
FIG. 5 is a workflow diagram of an HTTP message processing module of a method for implementing a Master Multi-Slave Git Cluster based on preemption locks to process modification requests according to an embodiment of the present invention;
FIG. 6 is a workflow diagram of an HTTP message processing module of a method for implementing a Master Multi-Slave Git Cluster based on preemption locks to process a Git pull request according to an embodiment of the present invention;
fig. 7 is a flowchart of the operation of a broadcast message processing module of a method for implementing a master-multi-slave Git cluster based on a preemption lock in accordance with an embodiment of the present invention.
Detailed Description
For further explanation of the various embodiments, the drawings which form a part of the disclosure and which are incorporated in and constitute a part of this specification, illustrate embodiments and, together with the description, serve to explain the principles of operation of the embodiments, and to enable others of ordinary skill in the art to understand the various embodiments and advantages of the invention, and, by reference to these figures, reference is made to the accompanying drawings, which are not to scale and wherein like reference numerals generally refer to like elements.
According to an embodiment of the invention, a method for realizing a Git cluster with one master and multiple slaves based on a preemption lock is provided.
Referring now to the drawings and the detailed description, in accordance with an embodiment of the present invention, a method for implementing a master-multiple-slave Git cluster based on preemption locks, as shown in fig. 1-3, includes the following steps:
s1, determining a working mode by nodes in the cluster through preemption lock;
s2, updating the follower registry in the public storage at intervals of fixed time by the follower nodes, and cleaning the follower registry in the public storage at intervals of fixed time by all nodes in the cluster;
s3, utilizing the leader node to actually process all the modification requests, and informing the follower node to keep version synchronization with the leader node in time;
s4, utilizing a follower node to actually process a Git pull request initiated by an external node;
wherein the cluster comprises a leader node and a follower node.
The method comprises the following steps that a leader node and a plurality of follower nodes form a Git cluster with one master and a plurality of slaves; the interface initiates a configuration file modification request, wherein the request comprises a configuration file path to be modified and configuration file content; the method comprises the steps that a Git cluster firstly modifies a configuration file at a leader node, and then broadcasts to inform a follower node to execute Git pull operation; the service host actively initiates a Git pull request, which is routed to the follower node for processing. The public storage is used for storing registration information, latest Git version information and distributed lock information of the nodes, Redis or Zookeeper can be selected, and Redis is selected in the embodiment.
Wherein, a Git library is arranged on the Git node, and other modules operate the Git library through a Jgit three-party bag.
The master selecting module is responsible for determining the working mode of the node and maintaining the registration information of the node, and the master preempting function determines the working mode of the node through preempting the lock: leader mode and follower mode, the follower registration and cleanup function is responsible for maintaining follower registration information.
The HTTP message processing module is responsible for processing various HTTP messages according to message types; the broadcast message processing module is responsible for processing broadcast messages in the cluster.
In one embodiment, as shown in fig. 4, the determining the operation mode by preempting the lock by the nodes in the cluster includes the following steps:
s101: acquiring a distributed lock at fixed time intervals;
the main selecting module depends on the distributed locks, the distributed locks provided by Redisson are adopted in the embodiment, the distributed locks depend on Redis, the functions are stable, and the requirements of the embodiment can be better met;
s102: judging the working mode of the current node, if the working mode is the leader mode, updating the effective time of the leader registration information, and entering S106; if yes, the follower node enters S103;
the leader registration information is stored in Redis, and the key value is as follows: LEADER KEY, data object fields are interpreted as follows:
examples are as follows:
s103: detecting whether the registration information of the leader is valid, and if so, entering S106; if the result is invalid, the operation goes to S104;
it is effective to satisfy the following conditions:
the LEADER KEY object is not empty in S102, and:
renewTime + leaseDurationSeconds > current time;
s104: detecting whether the current node is qualified to become a leader, if so, entering S105, and if not, entering S106;
if the latest version submission time of the Git of the current node is equal to the latest version submission time of the cluster, the current node is qualified as a leader;
obtaining Commit log of the current node Git library through an API provided by Jgit, wherein the Commit log has the submission time of the latest version;
the lastgitlog. commit time field of the LEADER KEY object is the latest version commit time of the cluster;
s105: converting the current node into a leader mode, updating leader registration information in public storage, and sending a broadcast message;
updating the field value of the data corresponding to the LEADER KEY in the Redis, as shown in the following table:
broadcast notification can be sent through a pub/sub mechanism of Redis to notify a follower node to initiate a Git pull request to a leader, so that Git version synchronization is realized.
S106: the distributed lock is released.
In one embodiment, updating the follower registry in the common store by the follower nodes at fixed intervals comprises:
the key of the follower registry in the public storage is a node identifier;
the registry value contains a refresh time field.
In one embodiment, the cleaning up the follower registry in the common storage at regular intervals by all nodes in the cluster comprises:
the cluster nodes comprise leader nodes and follower nodes;
traversing key value pairs in a follower registry by cluster nodes at intervals of fixed time;
and if the difference value between the refreshing time and the current date of the key value pair is larger than the preset value, deleting the key value from the registry.
The follower registration and cleaning function maintains a KEY-value pair list corresponding to FOLLOW _ KEY in Redis, and the follower node updates a value corresponding to the node IP at fixed time intervals; and traversing the key value pairs by all the nodes at fixed time intervals, and cleaning keys which are not updated for a long time.
An example of key-value pair information is as follows:
in one embodiment, the step of utilizing the leader node to actually process all modification requests and inform the follower node to maintain version synchronization with the leader node in time comprises the steps of:
the leader node receives the modification request, modifies the work area file according to the modification request, submits the Git library, updates the latest Git version information to the public storage and sends a broadcast message;
the follower node receives the broadcast notification and initiates a gitpull request to the leader node;
the follower node receives the modification request and forwards the modification request to the leader node for processing.
In one embodiment, as shown in FIG. 5, the leader node receiving the modification request, modifying the workspace file according to the modification request, and submitting the library of gits, updating the latest Git version information to the public storage, and sending the broadcast message comprises the steps of:
extracting a modified file path and file contents from the modification request;
the structure of the content contained in the modification request is as follows:
updating the Git workspace file according to the modified file path and the modified content, and executing Git Add and Git Commit operations;
wherein, the Git add and Git commit operations can be realized by calling the API of Jgit.
Obtaining latest version information of Git;
the latest version information of the Git library can be obtained by calling Jgit API, such as:
updating the version information to leader registration information;
updating version information to a lastGitLog field of data corresponding to LEADER _ KEY in Redis;
sending a broadcast message to inform a follower node;
the broadcast message can be sent through a pub/sub mechanism of Redis;
replying to the caller;
wherein the version information includes a Git version number and a version commit time.
In one embodiment, as shown in FIG. 7, the follower node receiving the broadcast notification and initiating a Git pull request to the leader node comprises the steps of:
receiving a broadcast notification;
acquiring the address of the current leader node from public storage;
the address of the current LEADER node is a KEY field of data corresponding to LEADER _ KEY in Redis;
adding a specific request header for the Git pull request, wherein the specific request header is used for identifying the request forwarded by the internal node of the cluster;
the method comprises the following steps that a specific request header can be added to a Git pull request through a TransportConfigCallback interface provided by a Jgit open source packet;
and initiating a Git pull request to the leader node, wherein the Git pull request pulls the latest version of the leader node and realizes version synchronization with the leader node.
In one embodiment, as shown in FIG. 6, the receiving and forwarding of the modification request by the follower node to the leader node comprises the steps of:
receiving a modification request, and acquiring the address of the current leader node from public storage;
the address of the current LEADER node is a KEY field of data corresponding to LEADER _ KEY in Redis;
forwarding the modification request to a leader node for processing;
the request forwarding can be realized by an open source HTTP forwarding three-party packet;
and replying the modification result.
After receiving the Git pull request, the HTTP message processing module determines the working mode of the current node, and processes the request according to the working mode:
the Git pull request may comprise two HTTP requests, the first request is a version confirmation request for confirming whether the versions of the server and the client are consistent, and if so, the second HTTP request is not sent; the second HTTP request is a version synchronization request, which is used to implement version synchronization between the client and the server, and Nginx needs to ensure that two HTTP requests included in the same Git pull are forwarded to the same node.
In one embodiment, the actual processing of the Git pull request initiated by the external node by the follower node comprises the following steps:
the leader node receives the Git pull request and determines a processing mode according to whether a specific request head is included;
the follower node receives the Git pull request, processes it directly without forwarding.
In one embodiment, the leader node receives a Git pull request, and the decision processing method according to whether a specific request header is included comprises the following steps:
step one, judging whether a specific request head is included, if the specific request head is included, the source is a follower node, entering step two, and if not, entering step three;
the Git pull request adopts an HTTP protocol, and the requests from different sources can be distinguished by adding a special request header; the example identifies a GIT pulling REQUEST initiated by an internal node of the cluster by adding a GIT _ REQUEST _ FROM = Server REQUEST head, and is separated FROM the GIT pulling REQUEST initiated by a service host;
step two, processing the pulling request, and entering step six;
wherein, the server side: the Git pull request compares Git versions of the client and the service area, and generates a response packet according to version difference, wherein the response packet comprises an incremental version which needs to be updated by the client;
wherein, the client: updating the incremental version in the response packet, and synchronizing the incremental version with the server version;
step three, the request source is an external node, a follower node list is obtained from public storage, and a node is selected by using a load balancing algorithm;
acquiring a follower node list according to a KEY value pair list stored by FOLLOW _ KEY in Redis;
acquiring a client IP from the request, acquiring a hash value (hashCode) of the client IP, and selecting one follower node by taking a modulus of the number of the follower nodes by using the hash value;
step four, forwarding the request to the selected follower node for processing;
the request forwarding can be realized by an open source HTTP forwarding three-party packet;
step five, receiving the return of the follower node;
step six, replying the caller.
The following explains the english and the terminology appearing in the text:
DevOps: DevOps (a combination of Development and Operations) is a collective term for a set of processes, methods and systems for facilitating communication, collaboration and integration between Development (application/software engineering), technical Operations and Quality Assurance (QA) departments.
Git: the system is an open-source distributed version management system, and can conveniently and efficiently finish project version management. Is the mainstream project version management tool at present.
Gitadd: adding the modified files from the current directory to the scratch pad tells the git system which files we want to commit, and then can commit using the git commit command.
Git commit: and submitting the changes in the temporary storage area to a local version library. Each time the git commit command is used, a 40-bit hash value is generated in the local version library, which is also called commit-id, and the submitted detailed information can be obtained through the commit-id: submitting user, date of submission, etc
The ratio of Git pull: the updating of a certain branch of the remote Git library is retrieved and then merged with the local appointed branch; the usual effect is to synchronize the modification of the remote Git library to local.
JGit: is an open source three-party package implemented in the Java language for executing Git operations through APIs.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like that fall within the spirit and principle of the present invention are intended to be included therein.
Claims (10)
1. A method for realizing a Git cluster with one master and multiple slaves based on a preemption lock, which is characterized by comprising the following steps:
s1, determining a working mode by nodes in the cluster through preemption lock;
s2, updating the follower registry in the public storage at intervals of fixed time by the follower nodes, and cleaning the follower registry in the public storage at intervals of fixed time by all nodes in the cluster;
s3, utilizing the leader node to actually process all the modification requests, and informing the follower node to keep version synchronization with the leader node in time;
s4, actually processing a Git pull request initiated by an external node by using a follower node;
wherein the cluster comprises a leader node and a follower node.
2. The method for implementing a master-multi-slave Git cluster based on preemption lock as claimed in claim 1 wherein the node in the cluster determining the mode of operation by preemption lock comprises the steps of:
s101: acquiring a distributed lock at fixed time intervals;
s102: judging the working mode of the current node, if the working mode is the leader mode, updating the effective time of the leader registration information, and entering S106; if yes, the follower node enters S103;
s103: detecting whether the registration information of the leader is valid, and if so, entering S106; if not, entering S104;
s104: detecting whether the current node is qualified to become a leader, if so, entering S105, and if not, entering S106;
if the latest version submission time of the Git of the current node is equal to the latest version submission time of the cluster, the current node is qualified as a leader;
s105: converting the current node into a leader mode, updating leader registration information in public storage, and sending a broadcast message;
s106: the distributed lock is released.
3. The method of preemptive-lock-based implementation of a master-multiple-slave Git cluster according to claim 1, wherein updating a follower registry in the common store by follower nodes at fixed time intervals comprises:
the key of the follower registry in the public storage is a node identifier;
the registry value contains a refresh time field.
4. The method of claim 1, wherein the using all nodes within a cluster to clean up follower registries in common storage at regular intervals comprises:
the cluster nodes comprise leader nodes and follower nodes;
traversing key value pairs in a follower registry by cluster nodes at intervals of fixed time;
and if the difference value between the refreshing time and the current date of the key value pair is larger than the preset value, deleting the key value from the registry.
5. The method for realizing a master-multi-slave Git cluster based on preemption lock as claimed in claim 1, wherein the step of utilizing the leader node to actually process all modification requests and to inform the follower node to keep version synchronization with the leader node in time comprises the steps of:
the leader node receives the modification request, modifies the working area file according to the modification request, submits the Git library, updates the latest Git version information to the public storage and sends a broadcast message;
the follower node receives the broadcast notification and initiates a gitpull request to the leader node;
the follower node receives the modification request and forwards the modification request to the leader node for processing.
6. The method for realizing a master-multi-slave Git cluster based on preemption lock as claimed in claim 5, wherein the leader node receives a modification request, modifies the workspace file according to the modification request, and submits a Git library, updates the latest Git version information to the public storage and sends a broadcast message comprising the steps of:
extracting a modified file path and file content from the modification request;
updating the Git workspace file according to the modified file path and the modified content, and executing Git Add and Git Commit operations;
obtaining latest version information of Git;
updating the version information to leader registration information;
sending a broadcast message to inform a follower node;
replying to the caller;
wherein the version information includes a Git version number and a version commit time.
7. The method for implementing a master-multi-slave Git cluster based on preemption locks as claimed in claim 5 wherein the follower node receiving a broadcast notification and initiating a Git pull request to the leader node comprises the steps of:
receiving a broadcast notification;
acquiring the address of the current leader node from public storage;
adding a specific request header for the Git pull request, wherein the specific request header is used for identifying the request forwarded by the internal node of the cluster;
and initiating a Git pull request to the leader node, wherein the Git pull request pulls the latest version of the leader node and realizes version synchronization with the leader node.
8. The method for realizing a master-multi-slave Git cluster based on preemption lock as claimed in claim 5, wherein the follower node receiving a modification request and forwarding to the leader node for processing comprises the steps of:
receiving a modification request;
acquiring the address of the current leader node from public storage;
forwarding the modification request to a leader node for processing;
receiving a response message of the leader node;
and replying the modification result.
9. The method for realizing a master-multi-slave Git cluster based on preemption lock as claimed in claim 1, wherein the actual processing of Git pull requests initiated by external nodes by follower nodes comprises the steps of:
the leader node receives the Git pull request and determines a processing mode according to whether a specific request head is included;
the follower node receives the Git pull request, processes it directly without forwarding.
10. The method for realizing a Git cluster with one master and multiple slaves based on preemption lock as claimed in claim 9, wherein the leader node receives Git pull requests and decides the processing mode according to whether to include a specific request header or not comprising the steps of:
step one, judging whether a specific request head is included, if the specific request head is included, the source is a follower node, entering step two, and if not, entering step three;
step two, processing the pulling request, and entering step six;
step three, the request source is an external node, a follower node list is obtained from public storage, and a node is selected by using a load balancing algorithm;
step four, forwarding the request to the selected follower node for processing;
step five, receiving the return of the follower node;
step six, replying the caller.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210924652.9A CN115002121B (en) | 2022-08-03 | 2022-08-03 | Method for realizing one-master multi-slave Git cluster based on preemption lock |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210924652.9A CN115002121B (en) | 2022-08-03 | 2022-08-03 | Method for realizing one-master multi-slave Git cluster based on preemption lock |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115002121A true CN115002121A (en) | 2022-09-02 |
| CN115002121B CN115002121B (en) | 2022-11-11 |
Family
ID=83022222
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210924652.9A Active CN115002121B (en) | 2022-08-03 | 2022-08-03 | Method for realizing one-master multi-slave Git cluster based on preemption lock |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115002121B (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120180070A1 (en) * | 2011-01-11 | 2012-07-12 | Ibm Corporation | Single point, scalable data synchronization for management of a virtual input/output server cluster |
| CN109104333A (en) * | 2018-08-21 | 2018-12-28 | 杭州安恒信息技术股份有限公司 | The synchronous method and device of distributed type assemblies based on GIT |
| CN110933137A (en) * | 2019-10-31 | 2020-03-27 | 北京浪潮数据技术有限公司 | Data synchronization method, system, equipment and readable storage medium |
| CN113660350A (en) * | 2021-10-18 | 2021-11-16 | 恒生电子股份有限公司 | Distributed lock coordination method, device, equipment and storage medium |
| CN113868184A (en) * | 2021-09-23 | 2021-12-31 | 猪八戒股份有限公司 | Configuration method and system of master-slave architecture cache-based configuration center |
| CN114064113A (en) * | 2021-11-26 | 2022-02-18 | 中国工商银行股份有限公司 | Host version control method and device |
-
2022
- 2022-08-03 CN CN202210924652.9A patent/CN115002121B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120180070A1 (en) * | 2011-01-11 | 2012-07-12 | Ibm Corporation | Single point, scalable data synchronization for management of a virtual input/output server cluster |
| CN109104333A (en) * | 2018-08-21 | 2018-12-28 | 杭州安恒信息技术股份有限公司 | The synchronous method and device of distributed type assemblies based on GIT |
| CN110933137A (en) * | 2019-10-31 | 2020-03-27 | 北京浪潮数据技术有限公司 | Data synchronization method, system, equipment and readable storage medium |
| CN113868184A (en) * | 2021-09-23 | 2021-12-31 | 猪八戒股份有限公司 | Configuration method and system of master-slave architecture cache-based configuration center |
| CN113660350A (en) * | 2021-10-18 | 2021-11-16 | 恒生电子股份有限公司 | Distributed lock coordination method, device, equipment and storage medium |
| CN114064113A (en) * | 2021-11-26 | 2022-02-18 | 中国工商银行股份有限公司 | Host version control method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115002121B (en) | 2022-11-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107465767B (en) | Data synchronization method and system | |
| US6336134B1 (en) | Dynamic clients, dynamic partitions, locking, and migration capability for distributed server for real-time collaboration | |
| US8386577B2 (en) | Selection of communication protocol for message transfer based on quality of service requirements | |
| US8788565B2 (en) | Dynamic and distributed queueing and processing system | |
| EP0795242B1 (en) | Routing in data communications network | |
| US8255359B2 (en) | System and methods for asynchronous synchronization | |
| US20020064126A1 (en) | Recovery following process or system failure | |
| KR101150146B1 (en) | System and method for managing cached objects using notification bonds | |
| US6487581B1 (en) | Apparatus and method for a multi-client event server | |
| RU2357283C2 (en) | Scheme for refreshing connection with network printing device for clients of printer device | |
| US20030135556A1 (en) | Selection of communication strategies for message brokers or publish/subscribe communications | |
| US20050097569A1 (en) | Event notification in a clustered computing environments | |
| EP3817338B1 (en) | Method and apparatus for acquiring rpc member information, electronic device and storage medium | |
| US20150256504A1 (en) | Distributed synchronization data in a message management service | |
| JP6405255B2 (en) | COMMUNICATION SYSTEM, QUEUE MANAGEMENT SERVER, AND COMMUNICATION METHOD | |
| US10013293B2 (en) | Queueing messages related by affinity set | |
| US7788330B2 (en) | System and method for processing data associated with a transmission in a data communication system | |
| US9069632B2 (en) | Message processing | |
| US8230086B2 (en) | Hidden group membership in clustered computer system | |
| US9513980B2 (en) | Transparent distribution and decoupling of modules using asynchronous communication and scopes | |
| CN115002121B (en) | Method for realizing one-master multi-slave Git cluster based on preemption lock | |
| CN115189931A (en) | Distributed key management method, device, equipment and storage medium | |
| CN112182003A (en) | Data synchronization method and device | |
| CN116361016B (en) | Message processing method and system of network controller | |
| CN110784532B (en) | Bidirectional data synchronization method and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |