CN116414579B - Method for realizing data consistency among multiple copies based on distributed group communication - Google Patents
Method for realizing data consistency among multiple copies based on distributed group communication Download PDFInfo
- Publication number
- CN116414579B CN116414579B CN202310140766.9A CN202310140766A CN116414579B CN 116414579 B CN116414579 B CN 116414579B CN 202310140766 A CN202310140766 A CN 202310140766A CN 116414579 B CN116414579 B CN 116414579B
- Authority
- CN
- China
- Prior art keywords
- data
- copy
- group
- version
- group communication
- 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.)
- Active
Links
- 238000004891 communication Methods 0.000 title claims abstract description 94
- 238000000034 method Methods 0.000 title claims abstract description 50
- 230000007246 mechanism Effects 0.000 claims abstract description 33
- 238000003860 storage Methods 0.000 claims abstract description 31
- 230000004044 response Effects 0.000 claims abstract description 14
- 230000008569 process Effects 0.000 claims description 14
- 238000004590 computer program Methods 0.000 claims description 13
- 238000005304 joining Methods 0.000 claims description 9
- 238000010586 diagram Methods 0.000 description 12
- 230000006870 function Effects 0.000 description 7
- 230000003287 optical effect Effects 0.000 description 4
- 238000005192 partition Methods 0.000 description 4
- 230000010076 replication Effects 0.000 description 4
- 238000009499 grossing Methods 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000001680 brushing effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Classifications
-
- 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/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Computing Systems (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Embodiments of the present application provide methods, apparatus, devices, and computer-readable storage media for data consistency among multiple copies based on distributed group communication. The method comprises the steps of receiving a data update request sent by a client and sending the update request to a distributed message middleware group communication interface; receiving an update request from a distributed message middleware group communication interface; based on a distributed message middleware group communication mechanism, the update request is sent to all members of a replica group where the replica group members are located, and the consistency of the data update requests received by all the group members is ensured by utilizing the characteristic of distributed message middleware group communication; updating the update data corresponding to the update request to the local hard disk, and simultaneously sending an update success response message to the client. In this way, the number of response requests per second for a distributed application requiring data consistency is greatly increased.
Description
Technical Field
Embodiments of the present application relate to the field of data sharing, and in particular, to a method, an apparatus, a device, and a computer readable storage medium for implementing data consistency among multiple copies by using distributed message middleware.
Background
Based on the distributed CAP theory, any network-based data sharing system can be obtained, and at most, only two elements of data consistency (Consistency), availability (Availability) and partition tolerance (Partition tolerance) can be met.
The expression of CAP theory serves its purpose well, i.e., opens the idea of a designer to design a diversified system under a diversified trade-off scheme.
For a distributed system, P (partition tolerance) must be considered, and under the condition that a (availability) and C (consistency) cannot be considered at the same time, only a trade-off can be made between a and C, so that services are basically available, and data are finally consistent.
In summary, how to process the data consistency of the partition and restore the copy, so as to achieve reasonable balance between consistency and usability, is a problem that needs to be solved at present.
Disclosure of Invention
According to the embodiment of the application, a scheme for realizing data consistency among multiple copies based on distributed group communication is provided.
In a first aspect of the application, a method for implementing data consistency among multiple copies based on distributed group communication is provided. The method comprises the following steps:
Receiving a data updating request sent by a client, and sending the updating request to a distributed message middleware group communication interface;
receiving an update request from a distributed message middleware group communication interface; the update request is obtained by: after the distributed message middleware group communication interface receives the update request, the update request is sent to all members of a copy group where the members of the copy group are located based on a distributed message middleware group communication mechanism;
Updating the update data corresponding to the update request to the local hard disk, and simultaneously sending an update success response message to the client.
Further, before receiving the data update request sent by the client, the method further includes:
when a copy group member starts, acquiring data update version numbers of other members in the group based on a distributed message middleware group communication mechanism;
if the version number of the data update is different from that of the copy group member and is higher than that of the copy group member, copying and flattening the data from the high-version group member;
if the data updating requests are the same, the data updating requests sent by the client are directly received.
Further, the obtaining the data update version number of other members in the group based on the distributed message middleware group communication mechanism includes:
when the copy group member is started, carrying out local initialization to obtain a local data updating version number;
Registering the version number and the initialized state into a distributed storage system of a distributed message middleware;
Based on an event notification mechanism of the distributed message middleware, a version number of each copy group member is obtained from the distributed storage system.
Further, the method further comprises the following steps:
If the copy group member of the low version performs data copying and smoothening, and other copy group members receive the data updating request sent by the client, the updating request sent by the distributed message middleware group communication interface is stored in the redolog file, and the updating request in redolog is played back after the data is smoothened.
Further, the method further comprises the following steps:
when the low-version copy member monitors that the high-version copy group member enters the running state of providing service externally, the high-version copy group member can be added into the group where the high-version copy group member is located through a group communication mechanism of the distributed message middleware.
Further, the group communication mechanism through the distributed message middleware, adding to the group where the high-version copy group member is located, includes:
Based on a group communication mechanism of the distributed message middleware, sending a new member joining event to a coordinator in a group where the high-version copy group member is located;
After receiving the event, the coordinator packages the current self data updating version number into a data packet, and transmits the data packet to a low-version copy member through a group communication callback mechanism;
And after receiving the data packet, the low-version copy member takes the version number of the low-version copy member as a start version number, takes the version number in the data packet as a stop version number, sends a data copy request to the high-version copy group member, and updates the data fed back by the high-version copy group member to the local disk.
Further, the method further comprises the following steps:
If a new forwarded data update request exists in the copy group in the process of playback redolog, a new redolog file is established, the data update request is stored in a new redolog file, when 1 data update request is played back redolog, the completion time and the number of the processed data update requests are counted, if any one of the two indexes is smaller than a threshold value, a redolog file is not newly built any more, and the data update request is stopped being read from a group communication interface;
After the playback processing of the last redolog is completed, the state of the device is switched to be the running state, and a data update request is obtained from the group communication interface and is directly updated to the local disk.
In a second aspect of the application, an apparatus for implementing data consistency among multiple copies based on distributed group communication is provided. The device comprises:
The first receiving module is used for receiving a data updating request sent by a client and sending the updating request to the distributed message middleware group communication interface;
The second receiving module is used for receiving an update request from the distributed message middleware group communication interface; the update request is obtained by: after the distributed message middleware group communication interface receives the update request, the update request is sent to all members of a copy group where the members of the copy group are located based on a distributed message middleware group communication mechanism;
And the updating module is used for updating the updating data corresponding to the updating request to the local hard disk and sending an updating success response message to the client.
In a third aspect of the application, an electronic device is provided. The electronic device includes: a memory and a processor, the memory having stored thereon a computer program, the processor implementing the method as described above when executing the program.
In a fourth aspect of the application, there is provided a computer readable storage medium having stored thereon a computer program which when executed by a processor implements a method as according to the first aspect of the application.
The method for realizing the data consistency among multiple copies based on the distributed group communication provided by the embodiment of the application is characterized by receiving a data update request sent by a client and sending the update request to a distributed message middleware group communication interface; receiving an update request from a distributed message middleware group communication interface; the update request is obtained by: after the distributed message middleware group communication interface receives the update request, the update request is sent to all members of a copy group where the members of the copy group are located based on a distributed message middleware group communication mechanism; updating the update data corresponding to the update request to a local hard disk, and simultaneously sending an update success response message to the client, thereby greatly improving the response request number per second of the distributed application requiring data consistency.
It should be understood that the description in this summary is not intended to limit the critical or essential features of the embodiments of the application, nor is it intended to limit the scope of the application. Other features of the present application will become apparent from the description that follows.
Drawings
The above and other features, advantages and aspects of embodiments of the present application will become more apparent by reference to the following detailed description when taken in conjunction with the accompanying drawings. In the drawings, wherein like or similar reference numerals denote like or similar elements, in which:
FIG. 1 illustrates a system architecture diagram involved in a method provided by an embodiment of the present application;
FIG. 2 illustrates a flow chart of a method of data consistency among multiple copies of a distributed group communication-based implementation in accordance with an embodiment of the present application;
FIG. 3 illustrates a data consistency implementation at all copy reboots in accordance with an embodiment of the application;
FIG. 4 illustrates a get group coordinator version schematic according to an embodiment of the present application;
FIG. 5 shows a schematic diagram of a process in which client production data and replication data coexist according to an embodiment of the application;
FIG. 6 illustrates a schematic representation of data consistency at online replica data update, according to an embodiment of the present application;
FIG. 7 illustrates a schematic representation of data consistency at a restart of a downed copy, according to an embodiment of the application;
FIG. 8 illustrates a block diagram of an apparatus for multi-copy data consistency based on a distributed group communication implementation in accordance with an embodiment of the present application;
fig. 9 shows a schematic diagram of a structure of a terminal device or server suitable for implementing an embodiment of the application.
Detailed Description
For the purposes of making the objects, technical solutions and advantages of the embodiments of the present disclosure more apparent, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present disclosure, and it is apparent that the described embodiments are some embodiments of the present disclosure, but not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments in this disclosure without inventive faculty, are intended to be within the scope of this disclosure.
In addition, the term "and/or" herein is merely an association relationship describing an association object, and means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.
The method for realizing the data consistency among multiple copies based on the distributed group communication is a communication middleware which is based on the distributed message middleware and has the advantages of efficient and reliable data transmission and exchange among multiple components, complex event processing and distributed coordination in the distributed network environment.
The group communication technique of the distributed message middleware is responsible for delivering messaging of group members, and message reception and delivery of messages to group members, in addition to event notifications and latest member views generated by member joining and exiting to group members.
Distributed message-middleware group communication has the following 2 technical characteristics:
1) For a group message, the information received by the group members is consistent (both received and not received), and the situation that some members receive and other members cannot receive does not exist;
2) The order of the group messages received by all members is exactly the same.
FIG. 1 illustrates a system architecture diagram, i.e., a functional architecture diagram of a distributed file system in relation to data consistency, in which embodiments methods of the present disclosure can be implemented. Including clients, distributed message middleware systems (astronomical flow control systems), and storage services.
The client is used for accessing the client application of the file system, and accessing the distributed file system through the distributed middleware communication interface and the file system interface;
The distributed message middleware system is used for publishing, subscribing and group communication of messages and the like. The message publishing and subscribing functions are mainly used for sending requests and request responses between the client and the server; the server-side copies data from the high-version copy in the process of starting the offline copy through the publishing/subscribing function of the message; the group communication of the distributed message middleware is to receive a copy of the client data update request and forward the client data update request to the copy group, so that online copies in all the copy groups receive the data update request, which is an important means for realizing the final consistency of data in the present disclosure.
The storage service can be divided into two modules, namely a client request processing module and a data access processing module, and is used for receiving and replying a client read-write request through interfaces such as message publishing/subscribing of the distributed message middleware and the like, and realizing the final consistency of data among copies through interfaces such as group communication of the distributed message middleware and the like; while also being used for storage and reading of local data
Fig. 2 illustrates a flow chart of a method of data consistency among multiple copies based on a distributed group communication implementation in accordance with an embodiment of the present disclosure. The method comprises the following steps:
s210, receiving a data update request sent by a client, and sending the update request to a distributed message middleware group communication interface.
In some embodiments, through the group communication mechanism of the distributed message middleware, the started replica (replica group member) will obtain the data update version numbers of the other replicas, thereby determining whether data copying and leveling from the other replicas is required. After the group is added, if the data is copied and smoothed, copying and smoothing the data are carried out from other copies (copy group members with high version numbers); otherwise, the operation state is directly switched to and the client request is received.
Further, in the process of data copying and flattening, the started copy may receive the data update request of the client from other online copies, and at this time, the data update request forwarded from the group communication interface needs to be temporarily stored in the redolog file, and the update request in redolog is played back after the data is flattened. After completing the data replication and the topdressing and the playback redolog, the final data consistency between the replicas is completed, the replicas can mark themselves as running status and notify the online client to start accepting the client request.
In some embodiments, in all copy starting processes, it is necessary to ensure that all copy data is consistent before the service can be provided to the outside. Considering that the reason that the copies are stopped may be caused by abnormal factors such as power failure, etc., the data of each copy in the disk cannot be guaranteed to be completely consistent, so when each copy is started, version information of all other copies (other copy group members in the group) needs to be acquired, a copy with a high version is found, difference data is further copied from the copy with the high version, and the difference data is updated to the local disk. I.e. to ensure data consistency when all copies are restarted.
Specifically, referring to fig. 3, when each copy is started, after the local initialization is completed to obtain the local data update version number, the version number and the state of the copy initialization are registered in the distributed storage system of the distributed message middleware, and the distributed storage system of the distributed message middleware is used for ensuring that when the copy is offline or down, the state registration information is deleted. Meanwhile, when the version number and the state in the database are updated by using an event notification mechanism of the distributed message middleware, the distributed message middleware notifies all copies including own copies of the version number and the copy state change concerned, and each copy can acquire the version numbers and the copy states of other copies. Therefore, the data difference among the copies can be judged, and preparation is made for the copy difference data of the copies.
Further, after all the copies register own copy version numbers and states in the distributed storage system, since each copy can obtain the version numbers of all other copies, if the own version of the copy is the highest version number (a plurality of copies may have the highest version number) at the time of starting, the running state which can provide services to the outside can be directly entered, and the copy states in the registration information in the distributed storage system are modified to be the running state; the data is marked as a synchronous state when the data is required to be copied and smoothed, and the data synchronization processing of the subsequent data copying and smoothing is performed.
In some embodiments, when the copy with low version monitors that the copy with high version enters the running state of providing services externally, the copy with low version can be added into the copy group through the group communication mechanism of the distributed message middleware.
Specifically, as shown in FIG. 4, updated versions of data that are other online copies at the point of joining are obtained. In a distributed message-middleware group, which has the role of a coordinator, the enrollees need to resort to a distributed message-middleware group communication mechanism that will notify the coordinator (a copy of the online copy, typically the first one to join the group) of new members joining the group in an event-wise manner and ask the coordinator to return a custom data packet to the enrollees. When the coordinator receives the event notification, the coordinator needs to finish processing the last message in the group message queue (the group messages are all data update requests), then encapsulates the last data update version number of the coordinator into a data packet, and transmits the data packet to the joiner just joining the copy group through a group communication callback mechanism. At this time, the last data update version number obtained by the coordinator is the key of ensuring data consistency between the copies, so before the coordinator obtains the version number, all requests of the data update caches before the point of joining the group need to be ensured to be processed completely, and one data brushing operation is ensured to be executed.
It should be noted that, before the new member joins the group, the group interface transmits a blocking signal, and the group member cannot transmit a request message to the group interface; after the coordinator sends the version number to the new member and updates the group view to all the intra-group copies, the new member successfully enters the group, the group interface sends a blocking notification, and normal group communication of the group is restored.
In some embodiments, after the enrollee obtains the version number transferred by the coordinator, the enrollee uses the version number of its own copy as a start version number and uses the version number of the coordinator as a stop version number, sends a data copy request to the high-version copy, and then updates the received data to the local disk.
Since the data to be copied may be large, it is necessary to continue to send a data copy request to a copy of a higher version with the version number of the copy itself as the start version number and the version number of the coordinator as the end version number, and update the local disk until the version number of the copy itself is equal to the version number provided by the coordinator. That is, the data copying may be performed a plurality of times.
S220, receiving an update request from a distributed message middleware group communication interface; the update request is obtained by: and after the distributed message middleware group communication interface receives the update request, the update request is sent to all members of the replica group where the members of the replica group are located based on a distributed message middleware group communication mechanism.
In some embodiments, the update request sent through the distributed message broker group communication interface is transferred to redolog files. When a certain copy in the group determines that the copy is the copy with the highest version number in the starting process, the copy enters an operating state capable of providing read-write service to the outside.
Further, receiving copies of the client data update requests forwards the data update requests to the copy groups, so that each copy in the joining group receives the data update requests. The copy still in the startup cannot be directly processed when the update request group messages are received, and the update request group messages need to be temporarily stored in redolog files, and the update request in redolog can be processed after the data is copied from the high-version copy and the update local disk processing is finished.
In some embodiments, if the low-version copy group member performs data copying and leveling, and the other copy group members receive the data update request sent by the client, the update request sent by the distributed message middleware group communication interface is stored in the redolog file, and the update request in redolog is played back after the data is leveled. After completing the data replication and smoothing and playback redolog, the final data consistency between the replicas is completed so far, the replicas (low version replica group members) can mark themselves as running status and notify the online client to start receiving client requests.
Specifically, referring to FIG. 5, a scenario is shown in FIG. 5 where both a copy needs to make a data copy and a copy accepts a client data update request. The copy 1 in the node 1 and the copy 2 in the node 2 have the same version number after being started and are higher than the copy 3, so that the copy 1 and the copy 2 can enter an operating state of providing services to the outside after being initialized, and the client can send a data update request. After receiving the data update request from the client, the copy 1 forwards the update request to the copy group, which is shown as a group communication interface groupcomm. And after the copy 1 and the copy 2 receive the update request from the group, the disc dropping processing can be performed. But copy 3, because it is doing the data replication and updating the local disk, forwards the received group message to redelog after copy 3 joins the group. Copy 3, after completing the process of copying data and updating the local disk, needs to play back the data update request in redolog. During playback redolog, new redolog files need to be created and these data update requests stored in new redolog, as there may be new data update requests forwarded from the replica group. When 1 piece of redolog is played back, counting the completion time and the number of processed data update requests, if any one of the two indexes is smaller than a specific threshold value, not newly creating redolog files, stopping reading the data update requests from the group communication interface, and switching the state of the device to an operation state after the playback processing of the last redolog is completed. And then the data updating request is obtained from the group communication interface and directly updated to the local disk.
After the file playback of redolog is completed, the copy 3 can switch the state to an operation state in which the service can be provided to the outside.
In conclusion, the consistency of the data when all the copies are restarted is realized.
In some embodiments, as shown in FIG. 6, data consistency at the time of online replica data update is ensured by:
The copies of the client and the server are performed through a publish/subscribe communication mechanism of the distributed message middleware. Each copy subscribes to a unique topic associated with only a certain copy number before completing the start-up and switching to run state; when the client starts, one online copy is randomly selected as a target for publishing the message. In the following interaction process between the client and the server copy, copy switching is not performed unless the target copy is offline. Based on the above settings, it can be ensured that read and write requests sent by any client are handled by the same copy.
When receiving the read-write request of the client, the copy can be treated differently according to different requests. If the read request is the read request, directly providing a service by a copy of the read request of the receiving client, reading data and replying to the processing of the client;
If the data updating request is received, the copy of the client request is received, the local disk is not directly updated, and the updating request is forwarded to the copy group, so that all members added to the copy group can be guaranteed to uniformly receive the updating request (either received or not received), namely, the data consistency among online copies is guaranteed based on a data consistency mechanism of the distributed message middleware.
After receiving the data updating request from the copy group, the copy analyzes the operation and data in the request, allocates a version number for each operation, and stores the operation and data in the local disk. Each copy maintains its own data update version number, starting with 1, and the version number assigned to each operation is incremented by 1 based on the last version number. That is, each version number corresponds to a request for a data update, with the version number of each request for a data update being incremented by 1.
After each copy updates the data to the local disk, the topic monitored by the client is found from the request message, and then the updating result is replied to the client.
In some embodiments, when one or more copies are in a running state, data consistency at the time of copy restart is ensured by:
As shown in fig. 7, when the replica node starts, after the local initialization is completed to obtain the local data update version number, the version number and the state of the replica initialization are registered in the distributed storage system of the distributed message middleware, and the distributed storage system of the distributed message middleware can ensure that if the replica is offline or down (the process exits), the state registration information can be automatically deleted. Meanwhile, by using an event notification mechanism of the distributed message middleware, when the version number and the state in the database are updated by the copies, the distributed message middleware notifies all copies including the own copies of the version number and the copy state changes concerned, so that each copy can obtain the version numbers and the copy states of other copies.
If there are other copies in the running state, the next processing is directly performed without determining whether the version numbers of the other copies are greater than the version numbers of the other copies, i.e. adding the copy group (refer to the corresponding steps described above and are not repeated here). Because there are online copies in a normal running state, the started copy can be directly added to the copy group.
And S230, updating the update data corresponding to the update request to the local hard disk, and simultaneously sending an update success response message to the client.
In some embodiments, all online copies, including copies forwarding update requests to the group, receive the group update requests forwarded by the group communication interface. Each copy is responsible for updating data to the local disk and then each copy sends a successful update response message to the client. Considering the extreme case of extremely large network delay, there may be a phenomenon that the client cannot receive the response message of any one copy, and the data update request sent by the client is overtime, at this time, the client may consider that the data update request fails, and the client and the server that the server succeeds in making the data update request are inconsistent. To avoid this, the client needs to resend the same data update request, while each copy of the server needs to introduce an idempotent mechanism to ensure that the data update request of the same client will only be processed once. The final consistency of the numbers among the online copies is completed through a message forwarding mechanism of the group communication interface.
The consumed time for completing the data consistency of each online copy mainly depends on network communication delay and performances of a CPU, a memory, a disk IO and the like, and when the system only receives one request (only one request sent by a client), the consumed time for completing one data update is in the ms level (within 5 ms).
According to the embodiment of the disclosure, the following technical effects are achieved:
by the method, the correctness and complexity of the data communication of the bottom layer are not required to be concerned at all, and only various logic processes of the distributed application are focused, so that the realization of the distributed application is simpler and more convenient, and the stability of the system is improved.
Meanwhile, the method realizes the final consistency of the data among the online copies, the cost of the final consistency time of the data among the online copies is low, the time consumption for completing one-time data updating under the single request condition is within 1-3 ms, and the response request number (TPS) of each second of the distributed application requiring the data consistency is greatly improved.
It should be noted that, for simplicity of description, the foregoing method embodiments are all described as a series of acts, but it should be understood by those skilled in the art that the present application is not limited by the order of acts described, as some steps may be performed in other orders or concurrently in accordance with the present application. Further, those skilled in the art will also appreciate that the embodiments described in the specification are alternative embodiments, and that the acts and modules referred to are not necessarily required for the present application.
The above description of the method embodiments further describes the solution of the present application by means of device embodiments.
Fig. 8 illustrates a block diagram of an apparatus 800 for distributed group communication-based implementation of data consistency among multiple copies, as illustrated in fig. 8, the apparatus 800 comprising:
a first receiving module 810, configured to receive a data update request sent by a client, and send the update request to a distributed message middleware group communication interface;
A second receiving module 820, configured to receive an update request from the distributed message middleware group communication interface; the update request is obtained by: after the distributed message middleware group communication interface receives the update request, the update request is sent to all members of a copy group where the members of the copy group are located based on a distributed message middleware group communication mechanism;
And the updating module 830 is configured to update the update data corresponding to the update request to the local hard disk, and send an update success response message to the client.
It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the described modules may refer to corresponding procedures in the foregoing method embodiments, which are not described herein again.
Fig. 9 shows a schematic diagram of a structure of a terminal device or server suitable for implementing an embodiment of the application.
As shown in fig. 9, the terminal device or the server 900 includes a Central Processing Unit (CPU) 901, which can execute various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM) 902 or a program loaded from a storage section 908 into a Random Access Memory (RAM) 903. In the RAM 903, various programs and data necessary for the operation of the system 900 are also stored. The CPU 901, ROM 902, and RAM 903 are connected to each other through a bus 904. An input/output (I/O) interface 905 is also connected to the bus 904.
The following components are connected to the I/O interface 905: an input section 906 including a keyboard, a mouse, and the like; an output portion 907 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage portion 908 including a hard disk or the like; and a communication section 909 including a network interface card such as a LAN card, a modem, or the like. The communication section 909 performs communication processing via a network such as the internet. The drive 910 is also connected to the I/O interface 905 as needed. A removable medium 911 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is installed as needed on the drive 910 so that a computer program read out therefrom is installed into the storage section 908 as needed.
In particular, the above method flow steps may be implemented as a computer software program according to an embodiment of the application. For example, embodiments of the application include a computer program product comprising a computer program embodied on a machine-readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from the network via the communication portion 909 and/or installed from the removable medium 911. The above-described functions defined in the system of the present application are performed when the computer program is executed by a Central Processing Unit (CPU) 901.
The computer readable medium shown in the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units or modules involved in the embodiments of the present application may be implemented in software or in hardware. The described units or modules may also be provided in a processor. Wherein the names of the units or modules do not in some cases constitute a limitation of the units or modules themselves.
As another aspect, the present application also provides a computer-readable storage medium that may be contained in the electronic device described in the above embodiment; or may be present alone without being incorporated into the electronic device. The computer-readable storage medium stores one or more programs that when executed by one or more processors perform the methods described herein.
The above description is only illustrative of the preferred embodiments of the present application and of the principles of the technology employed. It will be appreciated by persons skilled in the art that the scope of the application is not limited to the specific combinations of the features described above, but also covers other embodiments which may be formed by any combination of the features described above or their equivalents without departing from the spirit of the application. Such as the above-mentioned features and the technical features having similar functions (but not limited to) applied for in the present application are replaced with each other.
Claims (4)
1. A method for implementing data consistency among multiple copies based on distributed group communication, applied to copy group members, comprising the steps of:
Receiving a data updating request sent by a client, and sending the updating request to a distributed message middleware group communication interface;
receiving an update request from a distributed message middleware group communication interface; the update request is obtained by: after the distributed message middleware group communication interface receives the update request, the update request is sent to all members of a copy group where the members of the copy group are located based on a distributed message middleware group communication mechanism;
Updating the update data corresponding to the update request to a local hard disk, and simultaneously sending an update success response message to the client;
Before receiving the data update request sent by the client, the method further comprises: when the copy group member is started, carrying out local initialization based on a distributed message middleware group communication mechanism to obtain a local data updating version number;
Registering the version number and the initialized state into a distributed storage system of a distributed message middleware;
based on an event notification mechanism of the distributed message middleware, acquiring a version number of each copy group member from the distributed storage system;
If the version number of the data update is different from that of the copy group member and is higher than that of the copy group member, copying and flattening the data from the high-version group member; if the data updating requests are the same, directly receiving the data updating requests sent by the client;
If the copy group member with the low version performs data copying and smoothening, and other copy group members receive the data updating request sent by the client, storing the updating request sent by the distributed message middleware group communication interface in redolog files, and replaying the updating request in redolog after the data smoothening;
When the low-version copy member monitors that the high-version copy group member enters an operation state for providing service to the outside, a new member joining event is sent to a coordinator in a group where the high-version copy group member is located based on a group communication mechanism of the distributed message middleware; after receiving the event, the coordinator packages the current self data updating version number into a data packet, and transmits the data packet to a low-version copy member through a group communication callback mechanism; after receiving the data packet, the low-version copy member takes the version number of the low-version copy member as a start version number, takes the version number in the data packet as a stop version number, sends a data copy request to the high-version copy group member, and updates the data fed back by the high-version copy group member to a local disk;
If a new forwarded data update request exists in the copy group in the process of playback redolog, a new redolog file is established, the data update request is stored in a new redolog file, when 1 data update request is played back redolog, the completion time and the number of the processed data update requests are counted, if any one of the two indexes is smaller than a threshold value, a redolog file is not newly built any more, and the data update request is stopped being read from a group communication interface; after the playback processing of the last redolog is completed, the state of the device is switched to be the running state, and a data update request is obtained from the group communication interface and is directly updated to the local disk.
2. An apparatus for implementing data consistency among multiple copies based on distributed group communication, comprising: the first receiving module is used for receiving a data updating request sent by a client and sending the updating request to the distributed message middleware group communication interface; the second receiving module is used for receiving an update request from the distributed message middleware group communication interface; the update request is obtained by: after the distributed message middleware group communication interface receives the update request, the update request is sent to all members of a copy group where the members of the copy group are located based on a distributed message middleware group communication mechanism; the updating module is used for updating the updating data corresponding to the updating request to the local hard disk and sending an updating success response message to the client;
the updating module is also used for carrying out local initialization based on a distributed message middleware group communication mechanism when the copy group member is started to obtain a local data updating version number;
Registering the version number and the initialized state into a distributed storage system of a distributed message middleware;
based on an event notification mechanism of the distributed message middleware, acquiring a version number of each copy group member from the distributed storage system;
If the version number of the data update is different from that of the copy group member and is higher than that of the copy group member, copying and flattening the data from the high-version group member; if the data updating requests are the same, directly receiving the data updating requests sent by the client;
If the copy group member with the low version performs data copying and smoothening, and other copy group members receive the data updating request sent by the client, storing the updating request sent by the distributed message middleware group communication interface in redolog files, and replaying the updating request in redolog after the data smoothening;
When the low-version copy member monitors that the high-version copy group member enters an operation state for providing service to the outside, a new member joining event is sent to a coordinator in a group where the high-version copy group member is located based on a group communication mechanism of the distributed message middleware; after receiving the event, the coordinator packages the current self data updating version number into a data packet, and transmits the data packet to a low-version copy member through a group communication callback mechanism; after receiving the data packet, the low-version copy member takes the version number of the low-version copy member as a start version number, takes the version number in the data packet as a stop version number, sends a data copy request to the high-version copy group member, and updates the data fed back by the high-version copy group member to a local disk;
If a new forwarded data update request exists in the copy group in the process of playback redolog, a new redolog file is established, the data update request is stored in a new redolog file, when 1 data update request is played back redolog, the completion time and the number of the processed data update requests are counted, if any one of the two indexes is smaller than a threshold value, a redolog file is not newly built any more, and the data update request is stopped being read from a group communication interface; after the playback processing of the last redolog is completed, the state of the device is switched to be the running state, and a data update request is obtained from the group communication interface and is directly updated to the local disk.
3. An electronic device comprising a memory and a processor, the memory having stored thereon a computer program, wherein the processor implements the method of claim 1 when executing the computer program.
4. A computer readable storage medium, on which a computer program is stored, which computer program, when being executed by a processor, implements the method according to claim 1.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310140766.9A CN116414579B (en) | 2023-02-21 | 2023-02-21 | Method for realizing data consistency among multiple copies based on distributed group communication |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310140766.9A CN116414579B (en) | 2023-02-21 | 2023-02-21 | Method for realizing data consistency among multiple copies based on distributed group communication |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116414579A CN116414579A (en) | 2023-07-11 |
| CN116414579B true CN116414579B (en) | 2024-05-10 |
Family
ID=87052254
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310140766.9A Active CN116414579B (en) | 2023-02-21 | 2023-02-21 | Method for realizing data consistency among multiple copies based on distributed group communication |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116414579B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109165261A (en) * | 2018-10-10 | 2019-01-08 | 深圳市欧瑞博科技有限公司 | Method of data synchronization, device, server and computer storage medium |
| CN109933597A (en) * | 2013-03-15 | 2019-06-25 | 亚马逊科技公司 | With database engine and the Database Systems for being independently distributed formula storage service |
| CN111147352A (en) * | 2019-12-23 | 2020-05-12 | 杭州米络星科技(集团)有限公司 | Distributed data synchronization method |
| CN112073300A (en) * | 2020-08-28 | 2020-12-11 | 北京五八信息技术有限公司 | Group data synchronization method and device |
| CN112084258A (en) * | 2020-08-18 | 2020-12-15 | 腾讯科技（深圳）有限公司 | Data synchronization method and device |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9805056B2 (en) * | 2014-06-24 | 2017-10-31 | Panzura, Inc. | Synchronizing file updates between two cloud controllers of a distributed filesystem |
| CN113595850B (en) * | 2020-04-30 | 2022-11-25 | 北京字节跳动网络技术有限公司 | Information interaction method, device, server, system and storage medium |
-
2023
- 2023-02-21 CN CN202310140766.9A patent/CN116414579B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109933597A (en) * | 2013-03-15 | 2019-06-25 | 亚马逊科技公司 | With database engine and the Database Systems for being independently distributed formula storage service |
| CN109165261A (en) * | 2018-10-10 | 2019-01-08 | 深圳市欧瑞博科技有限公司 | Method of data synchronization, device, server and computer storage medium |
| CN111147352A (en) * | 2019-12-23 | 2020-05-12 | 杭州米络星科技(集团)有限公司 | Distributed data synchronization method |
| CN112084258A (en) * | 2020-08-18 | 2020-12-15 | 腾讯科技（深圳）有限公司 | Data synchronization method and device |
| CN112073300A (en) * | 2020-08-28 | 2020-12-11 | 北京五八信息技术有限公司 | Group data synchronization method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116414579A (en) | 2023-07-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11687555B2 (en) | Conditional master election in distributed databases | |
| US6823355B1 (en) | Synchronous replication of transactions in a distributed system | |
| US20040230670A1 (en) | Method and system for representing, configuring and deploying distributed applications | |
| US6542929B1 (en) | Relaxed quorum determination for a quorum based operation | |
| KR20110050424A (en) | Instaled game software sharing via peer-to-peer network | |
| US6487678B1 (en) | Recovery procedure for a dynamically reconfigured quorum group of processors in a distributed computing system | |
| US20140282468A1 (en) | Local store data versioning | |
| CN110888858B (en) | Database operation method and device, storage medium and electronic device | |
| JP2001109726A (en) | Method and system for reconstructing processors in distributed computer system, and storage device | |
| CN109173270B (en) | Game service system and implementation method | |
| KR20150111952A (en) | Method and system for using a recursive event listener on a node in hierarchical data structure | |
| CN111064626B (en) | Configuration updating method, device, server and readable storage medium | |
| CN112148798A (en) | Data processing method and device applied to distributed system | |
| CN106708842B (en) | Method for loading data by application system, database and application system | |
| CN113656087A (en) | Applet starting method, device, equipment and storage medium | |
| JP3846852B2 (en) | Method, system, and program product for managing processing groups in a distributed computing environment | |
| WO2018036255A1 (en) | Method and device for resetting network device to factory settings, and network device | |
| CN114327799A (en) | Distributed transaction processing method and device, electronic equipment and storage medium | |
| CN114130035A (en) | User matching method, device, equipment and storage medium | |
| CN116414579B (en) | Method for realizing data consistency among multiple copies based on distributed group communication | |
| CN111240760B (en) | Application publishing method, system, storage medium and equipment based on registry | |
| CN110325980B (en) | Expansion method of user interface back-end cluster for database binding type application | |
| CN114979234A (en) | Session control sharing method and system in distributed cluster system | |
| CN110661857B (en) | Data synchronization method and device | |
| US20080034053A1 (en) | Mail Server Clustering |
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 |