CN112579620A - Message queue-based distributed system data final consistency method - Google Patents
Message queue-based distributed system data final consistency method Download PDFInfo
- Publication number
- CN112579620A CN112579620A CN202011537989.1A CN202011537989A CN112579620A CN 112579620 A CN112579620 A CN 112579620A CN 202011537989 A CN202011537989 A CN 202011537989A CN 112579620 A CN112579620 A CN 112579620A
- Authority
- CN
- China
- Prior art keywords
- message
- data
- service
- change request
- data change
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 33
- 238000012508 change request Methods 0.000 claims abstract description 45
- 238000012545 processing Methods 0.000 claims abstract description 45
- 230000008569 process Effects 0.000 claims abstract description 10
- 230000008859 change Effects 0.000 claims abstract description 8
- 238000012790 confirmation Methods 0.000 claims description 16
- 238000011084 recovery Methods 0.000 claims description 10
- 230000004048 modification Effects 0.000 claims description 8
- 238000012986 modification Methods 0.000 claims description 8
- 230000005540 biological transmission Effects 0.000 claims description 7
- 230000002159 abnormal effect Effects 0.000 claims description 5
- 238000005192 partition Methods 0.000 description 7
- 230000004044 response Effects 0.000 description 5
- 239000002253 acid Substances 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000008878 coupling Effects 0.000 description 2
- 238000010168 coupling process Methods 0.000 description 2
- 238000005859 coupling reaction Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000035945 sensitivity Effects 0.000 description 2
- 239000013256 coordination polymer Substances 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 230000001502 supplementing effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/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
-
- 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
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/547—Messaging middleware
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
Abstract
The invention relates to a final consistency method of distributed system data based on message queues, which is used for keeping the consistency of data among different microservices in a distributed system and comprises the following steps: s1: the distributed system acquires the operation of a user and a data change request corresponding to the operation; s2: recording the data change request to a database, and transmitting the data change request to a message queue serving as a middleware; s3: the data change request in the message queue is called by the micro service corresponding to the data to be modified to change the data, and the result is fed back according to the processing condition; s4: and judging whether the micro services corresponding to the data to be modified are successfully processed or not by inquiring the feedback result, if so, finishing the final consistency process of the data, and otherwise, returning to the step of 3. Compared with the prior art, the invention has the advantages of high reliability and the like.
Description
Technical Field
The invention relates to the field of data processing, in particular to a distributed system data final consistency method based on a message queue.
Background
A distributed database is a database in which not all storage devices are connected to a common Central Processing Unit (CPU). The distributed database may be stored in multiple computers at the same physical location, or may be dispersed across an interconnected network of computers at multiple physical locations. The location or site of the distributed system may be distributed over a large area or over a small area (e.g., a building or campus). The collection of data in a distributed database may also be distributed across multiple physical locations.
With the prevalence of micro service architecture, distributed transactions become a technical difficulty in most enterprise integration, and in the process of distributed transaction processing by an enterprise, ensuring the consistency of data copies of all transactions of the enterprise is the most important ring of distributed transactions of the enterprise.
Disclosure of Invention
The invention aims to overcome the defects of the prior art and provide a distributed system data final consistency method based on message queues with high reliability.
The purpose of the invention can be realized by the following technical scheme:
a final consistency method of distributed system data based on message queue is used for keeping consistency of data among different microservices in a distributed system, and comprises the following steps:
s1: the distributed system acquires the operation of a user and a data change request corresponding to the operation;
s2: recording the data change request to a database, and transmitting the data change request to a message queue serving as a middleware;
s3: the data change request in the message queue is called by the micro service corresponding to the data to be modified to change the data, and the result is fed back according to the processing condition;
s4: and judging whether the micro services corresponding to the data to be modified are successfully processed or not by inquiring the feedback result, if so, finishing the final consistency process of the data, and otherwise, returning to the step of 3.
Further, in the step S3, a globally unique identifier is set for each invocation of each micro service, and in the step S4, a feedback result corresponding to each invocation of each micro service is queried through the globally unique identifier.
Furthermore, the global unique identifier comprises a business document number, an operation serial number or an operation combination identifier.
Furthermore, the distributed system is a distributed system for processing order business, and the global unique identifier comprises an order number, a payment record serial number or a merchant number plus a merchant order number.
Further, in step S3, the step of performing data modification on the data modification request in the corresponding micro service invocation message queue specifically includes:
s31: the data change request in the corresponding micro service call message queue is sent to the real-time message server through the service processing service;
s32: the real-time message server records a data change request message;
s33: the service processing service judges whether the data change request is executed, if so, the real-time message server is controlled to cancel the sending of the data change request message, otherwise, the real-time message server is controlled to send the data change request message.
Further, the step S33 specifically includes:
s331: the service processing service inquires whether a repeated request exists according to the ID of the data change request, if so, executing step S332, otherwise, executing step S333;
s332: the service processing service sends a confirmation sending instruction to the real-time message server, and executes step S334;
s333: the service processing service sends a cancel sending instruction to the real-time message server, and executes step S334;
s334: the real-time message server receives the instruction of the business processing service, if the received instruction is the transmission confirmation instruction, the recorded data change request message is submitted, the corresponding micro-service performs data change, and if the received instruction is the transmission cancellation instruction, the transmission of the recorded data change request message is cancelled.
Further preferably, in step S3, the step of performing data modification on the data modification request in the corresponding microservice invocation message queue further includes:
s34: the message confirmation system regularly inquires confirmation and rollback conditions of messages sent by the real-time message server;
s35: if the message confirmation system inquires the unconfirmed or rolled back message, inquiring the message state from the service processing service;
s36: and the service server confirms whether the message is valid according to the message ID or the content.
Further, when any node is abnormal, the message is complemented by the message recovery system.
Further, the step of the message recovery system performing message replying specifically includes: the message recovery system polls the message list in the producer generating the data change request, inquires the message which is not confirmed after the set time, and repeatedly sends the message.
Further, in the step S4, the global service operation identifier is used to query the feedback result of the processing status of the operation execution.
Compared with the prior art, the invention has the following advantages:
1) according to the method and the device, the operation request is recorded, the corresponding data change request is recorded, an enough tracing mechanism and a sufficient order supplementing mechanism are provided, if the corresponding micro-service fails to be processed, the micro-service can still be processed again through repeated sending, the consistency of the same data of a plurality of micro-services in the distributed system is effectively guaranteed, and the reliability is improved.
2) The method has the advantages that the service result generated by repeatedly calling for many times is consistent with the service result called once, whether the operation exists or not can be inquired according to the message ID before formal submission, if the operation exists, the operation is executed, the result is directly returned, if the operation does not exist, the operation is executed, the idempotent is realized, the result cannot be influenced by repeated submission for many times, and the reliability is improved;
3) the message recovery system can mend the message when the abnormity occurs, the message data is independently stored, the flexibility is good, the coupling with the service system is reduced, the time sensitivity to the final consistency is higher, and the realization cost of the service passive party can be reduced.
Drawings
FIG. 1 is a schematic illustration of a process of the present invention;
FIG. 2 is a call chain diagram of the method of the present invention;
FIG. 3 is a block diagram of the overall process architecture of the method of the present invention;
FIG. 4 is a reference timing diagram of the method flow of the present invention.
Detailed Description
The invention is described in detail below with reference to the figures and specific embodiments. It is to be understood that the embodiments described are only a few embodiments of the present invention, and not all embodiments. All other embodiments, which can be obtained by a person skilled in the art without any inventive step based on the embodiments of the present invention, shall fall within the scope of protection of the present invention.
Examples
As shown in fig. 1, the present invention provides a method for maintaining data consistency between different microservices in a distributed system, which is based on a message queue, and comprises the following steps:
s1: the distributed system acquires the operation of a user and a data change request corresponding to the operation;
s2: recording the data change request to a database, and transmitting the data change request to a message queue serving as a middleware;
s3: the data change request in the message queue is called by the micro service corresponding to the data to be modified to change the data, and the result is fed back according to the processing condition;
the step of performing data modification on the data modification request in the corresponding micro-service invocation message queue specifically includes:
s31: the data change request in the corresponding micro service call message queue is sent to the real-time message server through the service processing service;
s32: the real-time message server records a data change request message;
s33: the service processing service judges whether the data change request is executed, if so, the real-time message server is controlled to cancel the sending of the data change request message, otherwise, the real-time message server is controlled to send the data change request message:
s331: the service processing service inquires whether a repeated request exists according to the ID of the data change request, if so, executing step S332, otherwise, executing step S333;
s332: the service processing service sends a confirmation sending instruction to the real-time message server, and executes step S334;
s333: the service processing service sends a cancel sending instruction to the real-time message server, and executes step S334;
s334: the real-time message server receives a command of a business processing service, if the received command is a command for confirming sending, the recorded data change request message is submitted, the corresponding micro-service carries out data change, and if the received command is a command for canceling sending, the recorded data change request message is canceled;
s34: the message confirmation system regularly inquires confirmation and rollback conditions of messages sent by the real-time message server;
s35: if the message confirmation system inquires the unconfirmed or rolled back message, inquiring the message state from the service processing service;
s36: and the service server confirms whether the message is valid according to the message ID or the content.
S4: and judging whether the micro services corresponding to the data to be modified are successfully processed or not by inquiring the feedback result, if so, finishing the final consistency process of the data, otherwise, returning to execute the step S3, specifically:
in order to ensure the operation is queriable, each invocation of each service needs to have a globally unique identifier, which may be a service document number (such as an order number), a system-assigned operation serial number (such as a payment record serial number), or a combined identifier using operation resources (such as a merchant number + a merchant order number). Besides, the time information of the operation is completely recorded. Global service operation identification can be used to query the results of the execution of the operation, particularly with respect to logic of the state in process. Therefore, in step S3, a globally unique identifier is set for each invocation of each microservice, and in step S4, a feedback result corresponding to each invocation of each microservice is queried through the globally unique identifier, where the globally unique identifier includes a service document number, an operation serial number, or an operation combination identifier, and the distributed system in this embodiment is a distributed system for processing order services, and the globally unique identifier includes an order number, a payment record serial number, or a merchant number + a merchant order number.
When any node in the above steps is abnormal, the message is complemented through the message recovery system, which specifically comprises: the message recovery system polls the message list in the producer generating the data change request, inquires the message which is not confirmed after the set time, and repeatedly sends the message.
The techniques used in the present invention include Base theory, CAP theory, queryable operation, idempotent operation, etc., and Base is an abbreviation for the three phrases basic Available, Soft state, and eventuality constraint. The BASE theory is the result of consistency and availability trade-offs in CAP, which derives from a summary of large-scale internet system distribution practices, which evolve gradually based on the CAP theorem. The core idea of the BASE theory is: even if strong consistency cannot be achieved, each application can adopt a proper mode to enable the system to achieve final consistency according to the service characteristics of the application. Next, see three elements in BASE:
1. is basically available
By substantially available is meant that the distributed system is allowed to lose part of its availability (not equivalent to the system being unavailable) when an unpredictable failure occurs, such as:
(1) loss in response time. Under normal conditions, one online search engine needs to return corresponding query results to a user within 0.5 second, but due to the fact that faults occur, the response time of the query results is increased by 1-2 seconds.
(2) Loss of system function: normally, when shopping on an e-commerce website, a consumer can complete each order smoothly, but in the case of a large shopping peak in festivals, some consumers may be guided to a degraded page in order to protect the stability of the shopping system due to the sharp increase of the shopping behavior of the consumer.
2. Soft state
Soft state refers to allowing data in the system to have an intermediate state, and considering that the presence of the intermediate state does not affect the overall availability of the system, i.e., there is a delay in the process of allowing the system to synchronize data between data copies of different nodes.
3. Final consistency
Final consistency emphasizes that all data copies eventually reach a consistent state after a period of synchronization. Therefore, the essence of final consistency is that the system is required to ensure that the final data can be consistent, and the strong consistency of the system data is not required to be ensured in real time.
In general, BASE theory is directed to large highly available scalable distributed systems, as opposed to the traditional transactional ACID nature, which is completely different from the strong consistency model of ACID, but rather gains availability by sacrificing strong consistency and allowing data to be inconsistent over time, but eventually reaching a consistent state. In other words, atomicity and persistence must be guaranteed fundamentally, with only reduced consistency and isolation requirements for availability, performance, and degraded service requirements.
4. Message queue
A "message queue" is a container that holds messages during their transmission.
For a shared data system, the CAP theory can only possess two of the CAP theories at most, and cannot give consideration to all. Any combination of the two has a service scenario, and the real service scenario should be a mixture of ACID and BASE.
1. Consistency
In a distributed environment, consistency refers to the characteristic of whether data can remain consistent across multiple copies. Under the requirement of consistency, after a system performs an update operation in a data consistency state, it should be ensured that the data of the system is still in a permanent state.
For a system in which data copies are distributed on different distributed nodes, if the data of a first node is updated and the update is successful, the data of a second node is not updated correspondingly, and then when the data of the second node is read, old data (or dirty data) is still obtained, which is a typical case of inconsistency of distributed data. In a distributed system, if all users can read the latest value after the update operation for a data item is successfully performed, the system is considered to have strong consistency.
2. Availability
Availability means that the services provided by the system must always be available, always being able to return results within a limited time for each operation request of the user. The emphasis here is "in limited time" and "return results".
By "limited time" it is meant that for an operation request from a user, the system must be able to return the corresponding processing results within a specified time, and if this time range is exceeded, the system is considered to be unavailable. In addition, "limited time" refers to the operation index designed at the beginning of the system design, and usually there is a large difference between different systems, and in any case, there must be a reasonable response time for the user to request, otherwise the user will feel disappointed with the system.
"Return results" is another very important indicator of availability, which requires the system to return a normal response after completing the processing of the user request. A normal response result can typically explicitly reflect the result of the dequeue request's processing, i.e., success or failure, rather than a returned result that is confusing to the user.
3. Partition fault tolerance
Partition fault tolerance constrains a distributed system to have the following characteristics: when a distributed system encounters a failure in any network partition, there is still a need to ensure that the service is provided to the outside for consistency and availability unless the entire network environment has failed.
The network partitioning refers to that in a distributed system, different nodes are distributed in different sub-networks (machine rooms or foreign networks), and due to some special reasons, the sub-networks are disconnected from each other, but the internal networks of the sub-networks are normal, so that the network environment of the whole system is divided into a plurality of isolated areas. It should be noted that each node that forms a distributed system joins and leaves can be considered as a special network partition. Description of selection:
CA: giving up partition fault tolerance, and enhancing consistency and availability, which is the choice of the traditional single-machine database;
AP: abandoning consistency (consistency here is strong consistency), pursuing partition fault tolerance and availability, which is a choice in many distributed system designs, such as many NoSQL systems;
and (3) CP: giving up availability, pursuing consistency and partition fault tolerance, basically no choice, network problems would directly make the entire system unusable.
A queryable operation: in order to ensure the operation is queriable, each invocation of each service needs to have a globally unique identifier, which may be a service document number (such as an order number), a system-assigned operation serial number (such as a payment record serial number), or a combined identifier using operation resources (such as a merchant number + a merchant order number). Besides, the time information of the operation is completely recorded. Global service operation identification can be used to query the results of the execution of the operation, particularly with respect to logic of the state in process.
Idempotent operation: idempotent: ff ((x)) ═ f (x); the service result generated by repeatedly calling for many times is consistent with the service result called once; idempotency may be achieved through the business operations themselves; or the system caches all the requests and processing results, and returns the previous processing results after detecting the repeated requests.
As shown in fig. 2-4, the core logic of the present invention is: the service processing service sends a message to the real-time message server before the service transaction is submitted, and the real-time message server only records message data but does not really send the message data; after the business processing service transaction is submitted, sending a command for confirming sending to the real-time message service; the real-time message service really sends the message only after receiving the sending confirmation instruction. And after the service transaction rolls back, the service processing service sends a cancel sending instruction to the real-time message. The message confirmation system regularly finds the messages which are not confirmed or are sent in a rolling way, inquires the message state of the service processing server, and the service server confirms whether the messages are effective or not according to the message ID or the content. The processing result of the passive side does not influence the processing result of the active side, and the message processing operation of the passive side is the operation supporting idempotent.
And (3) abnormal flow:
when any node is abnormal, the message recovery system can supplement the order of the message, can poll the message table in the producer, inquire the list which is not confirmed for a certain time, and repeatedly send the list. The message data are independently stored, the flexibility is good, and the coupling with a service system is reduced; the time sensitivity to the final consistency is higher, and the realization cost of the passive side of the service is reduced.
While the invention has been described with reference to specific embodiments, the invention is not limited thereto, and those skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope of the invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.
Claims (10)
1. A final consistency method of distributed system data based on message queues is used for keeping consistency of data among different micro services in a distributed system, and is characterized by comprising the following steps:
s1: the distributed system acquires the operation of a user and a data change request corresponding to the operation;
s2: recording the data change request to a database, and transmitting the data change request to a message queue serving as a middleware;
s3: the data change request in the message queue is called by the micro service corresponding to the data to be modified to change the data, and the result is fed back according to the processing condition;
s4: and judging whether the micro services corresponding to the data to be modified are successfully processed or not by inquiring the feedback result, if so, finishing the final consistency process of the data, and otherwise, returning to the step of 3.
2. The method as claimed in claim 1, wherein in step S3, a globally unique id is set for each invocation of each microservice, and in step S4, the feedback result corresponding to each invocation of each microservice is queried through the globally unique id.
3. The method according to claim 2, wherein the globally unique identifier comprises a business document number, an operation flow number, or an operation combination identifier.
4. The method as claimed in claim 3, wherein the distributed system is a distributed system for processing order services, and the globally unique identifier includes an order number, a payment record serial number, or a merchant number plus a merchant order number.
5. The method according to claim 1, wherein in step S3, the step of the data modification request in the message queue called by the corresponding micro service specifically includes:
s31: the data change request in the corresponding micro service call message queue is sent to the real-time message server through the service processing service;
s32: the real-time message server records a data change request message;
s33: the service processing service judges whether the data change request is executed, if so, the real-time message server is controlled to cancel the sending of the data change request message, otherwise, the real-time message server is controlled to send the data change request message.
6. The method for finally consistency of distributed system data based on message queues as claimed in claim 5, wherein said step S33 specifically includes:
s331: the service processing service inquires whether a repeated request exists according to the ID of the data change request, if so, executing step S332, otherwise, executing step S333;
s332: the service processing service sends a confirmation sending instruction to the real-time message server, and executes step S334;
s333: the service processing service sends a cancel sending instruction to the real-time message server, and executes step S334;
s334: the real-time message server receives the instruction of the business processing service, if the received instruction is the transmission confirmation instruction, the recorded data change request message is submitted, the corresponding micro-service performs data change, and if the received instruction is the transmission cancellation instruction, the transmission of the recorded data change request message is cancelled.
7. The method for finally consistency of data in a distributed system based on message queues as claimed in claim 5, wherein in step S3, the step of the corresponding microservice invoking the data change request in the message queue to perform data change further comprises:
s34: the message confirmation system regularly inquires confirmation and rollback conditions of messages sent by the real-time message server;
s35: if the message confirmation system inquires the unconfirmed or rolled back message, inquiring the message state from the service processing service;
s36: and the service server confirms whether the message is valid according to the message ID or the content.
8. The distributed system data final consistency method based on message queue as claimed in any one of claims 5-7, characterized in that when any node is abnormal, the message is complemented by the message recovery system.
9. The method according to claim 8, wherein the step of the message recovery system performing message reordering specifically comprises: the message recovery system polls the message list in the producer generating the data change request, inquires the message which is not confirmed after the set time, and repeatedly sends the message.
10. The method for final consistency of data in a distributed system based on message queues as claimed in claim 1, wherein in step S4, the global service operation id is used to query the feedback result of the processing status of the operation execution.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011537989.1A CN112579620A (en) | 2020-12-23 | 2020-12-23 | Message queue-based distributed system data final consistency method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011537989.1A CN112579620A (en) | 2020-12-23 | 2020-12-23 | Message queue-based distributed system data final consistency method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112579620A true CN112579620A (en) | 2021-03-30 |
Family
ID=75139080
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011537989.1A Pending CN112579620A (en) | 2020-12-23 | 2020-12-23 | Message queue-based distributed system data final consistency method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112579620A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112862574A (en) * | 2021-04-08 | 2021-05-28 | 上海哔哩哔哩科技有限公司 | Distributed order number generation method and system |
| CN113191767A (en) * | 2021-05-10 | 2021-07-30 | 京东数字科技控股股份有限公司 | Data processing method of distributed system and related equipment |
| CN113259254A (en) * | 2021-05-31 | 2021-08-13 | 上海有孚智数云创数字科技有限公司 | Method, system, device, equipment and medium for processing micro-service message request |
| CN113467898A (en) * | 2021-09-02 | 2021-10-01 | 北京开科唯识技术股份有限公司 | Multi-party cooperative service processing method and system |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103297268A (en) * | 2013-05-13 | 2013-09-11 | 北京邮电大学 | P2P (peer to peer) technology based distributed data consistency maintaining system and method |
| CN105450618A (en) * | 2014-09-26 | 2016-03-30 | Tcl集团股份有限公司 | Operation method and operation system of big data process through API (Application Programming Interface) server |
| CN108681556A (en) * | 2018-04-08 | 2018-10-19 | 华中科技大学 | The access method and its system of distributed instruction numeric field data |
| CN111464628A (en) * | 2020-03-31 | 2020-07-28 | 中国工商银行股份有限公司 | Multiplexing asynchronous processing system and method |
| CN112019689A (en) * | 2019-05-29 | 2020-12-01 | 北京奇虎科技有限公司 | Incoming call show service processing system and method |
-
2020
- 2020-12-23 CN CN202011537989.1A patent/CN112579620A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103297268A (en) * | 2013-05-13 | 2013-09-11 | 北京邮电大学 | P2P (peer to peer) technology based distributed data consistency maintaining system and method |
| CN105450618A (en) * | 2014-09-26 | 2016-03-30 | Tcl集团股份有限公司 | Operation method and operation system of big data process through API (Application Programming Interface) server |
| CN108681556A (en) * | 2018-04-08 | 2018-10-19 | 华中科技大学 | The access method and its system of distributed instruction numeric field data |
| CN112019689A (en) * | 2019-05-29 | 2020-12-01 | 北京奇虎科技有限公司 | Incoming call show service processing system and method |
| CN111464628A (en) * | 2020-03-31 | 2020-07-28 | 中国工商银行股份有限公司 | Multiplexing asynchronous processing system and method |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112862574A (en) * | 2021-04-08 | 2021-05-28 | 上海哔哩哔哩科技有限公司 | Distributed order number generation method and system |
| CN113191767A (en) * | 2021-05-10 | 2021-07-30 | 京东数字科技控股股份有限公司 | Data processing method of distributed system and related equipment |
| CN113259254A (en) * | 2021-05-31 | 2021-08-13 | 上海有孚智数云创数字科技有限公司 | Method, system, device, equipment and medium for processing micro-service message request |
| CN113467898A (en) * | 2021-09-02 | 2021-10-01 | 北京开科唯识技术股份有限公司 | Multi-party cooperative service processing method and system |
| CN113467898B (en) * | 2021-09-02 | 2022-01-18 | 北京开科唯识技术股份有限公司 | Multi-party cooperative service processing method and system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112579620A (en) | Message queue-based distributed system data final consistency method | |
| US20120239620A1 (en) | Method and system for synchronization mechanism on multi-server reservation system | |
| JP6165729B2 (en) | Method and system for maintaining strong consistency of distributed replicated content in a client / server system | |
| CN1534514B (en) | Frame structure and system suitable for position sensing | |
| US20120221537A1 (en) | Solution method of in-doubt state in two-phase commit protocol of distributed transaction | |
| CN110163755B (en) | Block chain-based data compression and query method and device and electronic equipment | |
| JPH10187519A (en) | Method for preventing contention of distribution system | |
| CN113268471B (en) | Method, proxy connection pool, system, device and medium for processing distributed transaction | |
| CA2395282C (en) | Preserving consistency of passively-replicated non-deterministic objects | |
| KR20140047230A (en) | Method for optimizing distributed transaction in distributed system and distributed system with optimized distributed transaction | |
| CN113010549A (en) | Data processing method based on remote multi-active system, related equipment and storage medium | |
| EP1623293A2 (en) | Mediator-based recovery mechanism for multi-agent system | |
| CN110941622A (en) | Data processing method and device | |
| CN112632093A (en) | Work order processing method, device, system, storage medium and program product | |
| CN117056116B (en) | Flow management method and electronic equipment | |
| US7716523B2 (en) | End-to-end transactional protection for requests in a web application | |
| EP2777215B1 (en) | Method, apparatus and system for simultaneously transmitting or receiving multiple managed objects | |
| CN113254467B (en) | Method and blockchain node for performing transactions in blockchain system | |
| CN114519440A (en) | Passenger ticket data processing method, device, equipment and storage medium | |
| JP2017097791A (en) | Data processing device | |
| WO2017077643A1 (en) | Data management system | |
| JP4604032B2 (en) | One-stage commit in non-shared database system | |
| WO2023124431A1 (en) | Database processing method and related device | |
| US20140122417A1 (en) | Transaction processing method, program, and system | |
| CN110191141B (en) | Service calling information processing method and device and computer 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 |