CN103164219B - The distributing real time system system of polymorphic type copy is used in decentralization framework - Google Patents

Abstract

The invention discloses a distributed transaction processing system using multiple types of copies in a decentralized architecture, including a transaction interface module, a transaction processing module, and a transaction storage module. The transaction interface module includes an external interface submodule and a transaction preprocessing submodule. The transaction processing module includes multi-type copy sub-module, read transaction processing module, copy group transaction status sub-module, read request distribution sub-module, copy repair sub-module, MVCC read sub-module, local write transaction processing sub-module, local write transaction Paxos Copy consistency submodule, local write transaction submission submodule, global write transaction processing submodule, main subtransaction Paxos copy consistency submodule, secondary subtransaction Paxos copy consistency submodule and global write transaction submission submodule, the present invention can solve the current The specific read-write environment in the system is very limited, and the availability of read-write cannot be configured according to the application requirements, and global transactions rely on locking, which is expensive.

Description

A distributed transaction processing system using multiple types of replicas in a decentralized architecture

technical field

The invention belongs to the technical field of distributed storage, and more specifically relates to a distributed transaction processing system using multiple types of copies in a decentralized architecture.

Background technique

With the continuous development of Internet technology, the data in the Internet is rising at an incredible speed. How to store and process such large-scale data has become the research direction of today's big data era. Decentralized NoSQL is a large-scale data storage system with the following characteristics: high read and write performance, no single point of failure, high availability, and high scalability. For example, the Cassandra system uses a column family-oriented storage model to achieve high read and write performance, uses a decentralized architecture to avoid single points of failure and achieve high availability, and uses consistent hashing to achieve high scalability.

The distributed transaction processing systems in the existing decentralized architecture are as follows: Megastore system is a system completed by Google on the basis of Bigtable. This system uses a special data model EntityGroups, and then uses additional system modules Coordinator and replica servers to ensure consistency. Its commit algorithm is a variant of the Paxos algorithm and is used to maintain the consistency of synchronous replicas across multiple data centers. However, this method uses a fixed number of successful reads and writes, and cannot adjust availability for different applications. Its global transactions use expensive two-phase commits, which will cause blocking. Scalaris is a distributed transaction system on the chord# ring. It uses a symmetric replica strategy and the improved Paxos atomic commit protocol. It needs three phases to complete a transaction, and cannot adjust availability for different applications. There is also a prototype system written by academic research, which studies distributed transactions in the P-Ring environment and proposes an MVCC algorithm - LSTP. The article focuses on the read-busy environment. Read-only transactions will not be suspended and blocked, but it is not suitable for the write-busy environment. The application scenarios of this system are relatively limited.

To sum up, the existing distributed transaction processing systems have the following deficiencies: 1. The read-write environment is very limited, and the read-write availability cannot be configured according to the application requirements. 2. Global transactions rely on locking, which is expensive.

Contents of the invention

Aiming at the defects of the prior art, the purpose of the present invention is to provide a distributed transaction processing system using multi-type copies in a decentralized architecture, aiming at solving the limitation of the read-write environment existing in the existing system, which cannot be based on The application needs to configure read and write availability by itself, and global transactions rely on locking, which is expensive.

In order to achieve the above purpose, the present invention provides a distributed transaction processing system using multiple types of copies in a decentralized architecture, including a transaction interface module, a transaction processing module and a transaction storage module. The transaction interface module includes an external interface sub-module and a transaction Preprocessing sub-module, transaction processing module includes multi-type copy sub-module, read transaction processing module, copy group transaction status sub-module, read request distribution sub-module, copy repair sub-module, MVCC read sub-module, partial write transaction processing sub-module , local write transaction Paxos replica consistency submodule, local write transaction commit submodule, global write transaction processing submodule, main subtransaction Paxos replica consistency submodule, secondary subtransaction Paxos replica consistency submodule and global write transaction commit submodule, The external interface sub-module is used to receive the transaction request from the client and send the transaction request to the transaction pre-processing sub-module. The transaction pre-processing sub-module is used to judge whether the transaction request is a read transaction request or a write transaction request. If it is a read transaction request , then send the read transaction request to the read transaction processing sub-module, if it is a write transaction request, then further judge whether the write transaction request is a local write transaction request or a global write transaction request, if it is a local write transaction request, then the local write transaction request The transaction request is sent to the local write transaction processing submodule. If it is a global write transaction request, the global write transaction request is sent to the global write transaction processing submodule. The read transaction processing submodule is used to obtain the read transaction from the multi-type copy submodule. The address of the readable copy and the required number of responses corresponding to each read command included in the transaction request, and send the read transaction request, the address of the readable copy, and the required number of responses to the replica group transaction status sub-module, and control the entire read Timeout retry of the transaction request processing flow, the copy group transaction status submodule is used to read the transaction execution status in the corresponding copy group according to the address of the readable copy, so as to obtain the maximum commit status log number and the maximum commit status corresponding to the read command Log timestamp, the read request distribution sub-module judges whether the read command in the read transaction request can be executed locally, and if so, sends the read command, the maximum committed log number and the maximum committed log timestamp to the local replica repair sub-module module, otherwise, send the read command, the maximum committed log number and the maximum committed log timestamp to any readable replica corresponding to the read command, and the replica repair submodule is used to update the node where it is located to the replica group transaction status submodule At the maximum committed log number obtained in , the MVCC read submodule is used to read data from the transaction storage module according to the read command and the maximum committed log timestamp, and return the data to the read transaction processing module, and the read transaction processing module also Used to send data to the external interface submodule, the external interface submodule is also used to send data to the client, and the local write transaction processing submodule is used to obtain the write instructions included in the local write transaction request from the multi-type copy submodule The addresses of the corresponding witness replicas and readable replicas, and the number of responses required by the readable replicas, and the partial write transaction request, the addresses of the witness replicas and readable replicas, and the required The response number of the readable copy of the local write transaction is sent to the sub-module of the Paxos replica consistency submodule of the local write transaction, and controls the timeout retry of the entire partial write transaction request processing flow. The Paxos replica consistency submodule of the local write transaction is used to set the witness replica in the witness replica group Consistent log value, transfer the log value to the local write transaction submission submodule, and add a local transaction mark to the log entry, the local write transaction submission submodule is used to respond according to the address of the readable copy and the required readable copy Submit the log value to the corresponding readable copy, and return the successful processing result to the local write transaction processing sub-module. The local write transaction processing sub-module is also used to send the successful processing result to the external interface sub-module. The external interface The submodule is also used to send the result of successful processing to the client, and the global write transaction management submodule is used to obtain the witness copy and readable copy corresponding to each write instruction included in the global write transaction request from the multi-type copy submodule The address and the number of responses of the required readable copies, and send the global write transaction request, the addresses of the witness copies and readable copies corresponding to each write command, and the number of responses of the required readable copies to the main sub-transaction Paxos replica consistency submodule , and control the timeout retry of the entire global write transaction request processing flow, the main sub-transaction Paxos replica consistency sub-module is used to set the consistent log value on the witness replica in the witness replica group of the main sub-transaction, the log value and the main sub-transaction The location information of the sub-transaction is sent to the sub-sub-transaction submission sub-module, and a global transaction mark is added to the log entry. The sub-sub-transaction Paxos replica consistency sub-module is used to set the witness copy of the sub-sub-transaction for all sub-sub-transactions The consistent log value on the witness copy in the group adds the location information and global transaction mark of the primary subtransaction to the log entries of all secondary subtransactions, and transmits the log value of the primary subtransaction and the log value of all secondary subtransactions To the main subtransaction submission submodule, the global write transaction submission submodule is used to submit the log value of the main subtransaction to the corresponding readable copy according to the address of the readable copy of the main subtransaction and the response number of the required readable copy, And the result of successful processing is returned to the global write transaction management submodule. The log value of the sub-transaction is submitted to the corresponding readable copy, and the global write transaction management sub-module is also used to send the successful processing result to the external interface sub-module, and the external interface sub-module is also used to send the successful processing result to the client .

The transaction preprocessing sub-module judges its type by reading the OPER field in the transaction request. This field represents the read transaction request and the write transaction request. The key of the operation is calculated, and the type of the write transaction request is judged according to the operation result. If the key operations of all write operations point to the same node, the write transaction request is a local write transaction request, otherwise it is a global write transaction request.

The copy repair sub-module will obtain consistent values for all log entries smaller than this number and determine whether to commit. If the transaction type recorded by the log entry is a local transaction, when the log entry reaches consistency in the witness copy, it is considered to be committed , otherwise submit a null operation; if the transaction type recorded by the log entry is a global transaction, in addition to checking whether the consistency is reached in the witness copy, it is also necessary to check whether the stored main sub-transaction is committed. When the main sub-transaction has been committed , it is considered that it can be submitted, otherwise, a no-op is submitted, and finally all transactions that need to be submitted are executed to the completion state.

The Paxos copy consistency sub-module of the local write transaction uses the Paxos algorithm to try to achieve the consistency of the log value in the same log position of each witness copy. The log value adds a timestamp to the operation of the write command in the partial write transaction request. This timestamp is greater than the maximum committed log timestamp of the witness copy group before the execution of the Paxos algorithm.

A global write transaction includes two or more local write transactions, all of which will be marked with a global transaction, one of which will be designated as the main subtransaction and used as a commit point, and the other local write transactions will be designated as secondary subtransactions , will record the location information of the main subtransaction for replica repair.

The main sub-transaction Paxos copy consistency sub-module uses the Paxos algorithm to try to achieve the consistency of the log value at the same log position of each witness copy of the main sub-transaction. The log value is the operation of the write command in this main sub-transaction plus Timestamp, which is greater than the maximum committed log timestamp of the witness copy group before the execution of the Paxos algorithm.

The sub-sub-transaction Paxos copy consistency sub-module uses the Paxos algorithm, and for each sub-transaction, tries to achieve the consistency of the log value at the same log position of each witness copy of the sub-sub-transaction, and the log value is this time Add a timestamp to the operation of writing instructions in the sub-transaction, and the timestamp is greater than the maximum committed log timestamp of the witness copy group before the execution of the Paxos algorithm.

Through the above technical solutions conceived by the present invention, compared with the prior art, the present invention has the following beneficial effects:

(1) Separate read and write nodes

Due to the adoption of multi-type replica submodules, local write transaction Paxos replica consistency submodules, local write transaction commit submodules, primary subtransaction Paxos replica consistency submodules, secondary subtransaction Paxos replica consistency submodules, and global write transaction commit submodules , so the log processing and data processing nodes are separated, which improves the configurability

(2) Configurable read and write availability levels for distributed transactions

Due to the use of multi-type copy sub-modules, the number of readable copies required for reading and writing can be set, so that while ensuring consistency, the availability level of reading and writing can also be adjusted.

(3) Lock-free global transactions

Since the main sub-transaction Paxos replica consistency sub-module, the secondary sub-transaction Paxos replica consistency sub-module and the global write transaction commit sub-module are used, the main sub-transaction can be used as the commit point, avoiding the use of locks.

(4) Strong scalability

Due to the adoption of consistent hashing in the decentralized architecture, it provides strong scalability. When the data size increases, it can be conveniently expanded horizontally by adding nodes, and only need to set a token value to join the entire server cluster by itself. Overall performance increases nearly linearly with scale.

(5) High reliability

The copy mechanism in the system ensures the reliability of the data. The same data will be saved on multiple nodes at the same time. When a node fails, the data will not be lost. It can also be configured to upgrade the replica mechanism to the data center level to provide disaster recovery at the level of natural disasters.

Description of drawings

Figure 1 is a topological diagram of the interconnection of a distributed transaction processing system based on multiple types of replicas in a decentralized architecture.

Figure 2 is an architecture diagram of a distributed transaction processing system based on multi-type replicas in a decentralized architecture.

Detailed ways

In order to make the object, technical solution and advantages of the present invention clearer, the present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described here are only used to explain the present invention, not to limit the present invention.

As shown in Figure 1, the distributed transaction processing system using multiple types of copies in the decentralized architecture of the present invention is applied in a distributed system including a client and multiple nodes A, B and C located on the server side, specifically setting in the node. The client is used to respond to customer requests and interact with nodes A, B, and C to submit transactions and obtain results. Nodes A, B, and C are used to store data, respond to read and write transactions, etc., and the nodes are connected to each other using a high-speed network. The distributed system uses a distributed hash table as the bottom layer to process data in the form of key-value pairs (Key-Value). Each node maps the key to a token (Token) through a consistent hash function, and according to the token Determine the storage node for the key-value pair, and each node is responsible for storing a certain range of key-value pairs.

As shown in FIG. 2 , the distributed transaction processing system using multiple types of copies in the decentralized architecture of the present invention includes a transaction interface module 1 , a transaction processing module 2 and a transaction storage module 3 .

The transaction interface module 1 includes an external interface submodule 101 and a transaction preprocessing submodule 102 .

Transaction processing module 2 includes multi-type copy sub-module 201, read transaction processing module 202, copy group transaction status sub-module 203, read request distribution sub-module 204, copy repair sub-module 205, MVCC read sub-module 206, local write transaction processing Submodule 207, local write transaction Paxos replica consistency submodule 208, local write transaction submission submodule 209, global write transaction processing submodule 210, primary subtransaction Paxos replica consistency submodule 211, secondary subtransaction Paxos replica consistency submodule 212 and the global write transaction submission submodule 213.

The external interface submodule 101 is configured to receive a transaction request from a client, and send the transaction request to the transaction preprocessing submodule 102 .

The transaction preprocessing submodule 102 is used to judge whether the transaction request is a read transaction request or a write transaction request. If it is a read transaction request, the read transaction request is sent to the read transaction processing submodule 204. If it is a write transaction request, the transaction request is further judged. Whether the write transaction request is a local write transaction request or a global write transaction request, if it is a local write transaction request, then send the local write transaction request to the local write transaction processing submodule 207, if it is a global write transaction request, then the global write transaction request The transaction request is sent to the global write transaction processing sub-module 210 . Specifically, the type is judged by reading the OPER field in the transaction request. If the field is 0, it means a read transaction request, and if it is 1, it means a write transaction request; The key of the operation is calculated, and the type of the write transaction request is judged according to the operation result. If all the key operations of the write operation point to the same node, the write transaction request is a local write transaction request, otherwise it is a global write transaction request.

The read transaction processing submodule 202 is used to obtain the address of the readable copy corresponding to each read instruction contained in the read transaction request and the required response quantity R (R is a positive integer) from the multi-type copy submodule 201, and read the transaction The request, the address of the readable replica and the required number of responses are sent to the replica group transaction status sub-module 203, which controls the timeout retry of the entire read transaction request processing flow.

The copy group transaction status sub-module 203 is used to read the transaction execution status in the corresponding copy group according to the address of the readable copy, so as to obtain each maximum committed log number and maximum committed log timestamp corresponding to the read command; specifically, A replica group maintains the consistency of logs of each node. Each item in the log has an increasing number and timestamp, and there are multiple states: waiting state, commit state, and completion state. Each node will record known The maximum completion log number, the maximum commit log number, and the maximum commit log timestamp. The result obtained is the maximum value among at least R successful responses.

The read request distribution sub-module 204 judges whether the read command in the read transaction request can be executed locally, and if so, sends the read command, the maximum commit state log number and the maximum commit state log timestamp to the local copy repair sub-module 205, Otherwise, send the read command, the maximum committed log number and the maximum committed log timestamp to any readable copy corresponding to the read command.

The copy repair sub-module 205 is used to update the node where it is located to the maximum committed state log number obtained in the copy group transaction status sub-module 203; specifically, obtain consistent values for all log entries smaller than the number and determine whether Submission is required. If the transaction type recorded in the log entry is a local transaction, when the log entry reaches consistency in the witness copy, it is considered to be committed, otherwise, no operation will be submitted; if the transaction type recorded in the log entry is a global transaction, In addition to checking whether the consistency is reached in the witness copy, it is also necessary to check whether the stored main sub-transaction is committed. When the main sub-transaction has been committed, it is considered to be committed. Otherwise, a no-op is submitted. The transaction executes to completion.

The MVCC read sub-module 206 is used to read data from the transaction storage module 3 according to the read instruction and the maximum committed log timestamp, and return the data to the read transaction processing module 202 .

The read transaction processing module 202 is also used to send data to the external interface sub-module 101 .

The external interface sub-module 101 is also used to send data to the client.

The local write transaction processing submodule 207 is used to obtain from the multi-type copy submodule 201 the addresses of the witness copy and the readable copy corresponding to the write instruction included in the partial write transaction request, and the required response number W of the readable copy (where W is a positive integer), and send the partial write transaction request, the address of the witness copy and the readable copy, and the response quantity of the required readable copy to the partial write transaction Paxos replica consistency sub-module 208, and control the entire partial write transaction request processing flow timeout retries.

The partial write transaction Paxos copy consistency submodule 208 is used to set the consistent log value on the witness copy in the witness copy group, transmit the log value to the partial write transaction submission submodule 209, and add a local transaction mark to the log entry; specifically In other words, the Paxos algorithm is used to try to achieve the consistency of log values in the same log position of each witness copy. The log value adds a timestamp to the operation of the write command in this partial write transaction request, and the timestamp is greater than this time. The maximum committed log timestamp of the witness replica group before the execution of the Paxos algorithm.

The local write transaction submission submodule 209 is used to submit the log value to the corresponding readable copy according to the address of the readable copy and the required response number W of the readable copy, and return the result of successful processing to the partial write transaction processing submodule 207.

The local write transaction processing sub-module 207 is also used to send the successful processing result to the external interface sub-module 101 .

The external interface sub-module 101 is also used to send the result of successful processing to the client.

The global write transaction management submodule 212 is used to obtain from the multi-type copy submodule 201 the address of the witness copy and the address of the readable copy corresponding to each write instruction included in the global write transaction request and the response number V of the required readable copy (where V is a positive integer), and send the global write transaction request, the address of the witness copy and readable copy corresponding to each write command, and the response quantity of the required readable copy to the main sub-transaction Paxos copy consistency submodule 211, and control the entire Timeout retries for global write transaction request processing. Specifically, a global write transaction includes two or more local write transactions, all of which will be marked with a global transaction, one of which will be designated as the main subtransaction and used as a commit point, and the other local write transactions will be designated as The secondary subtransaction will record the position information of the primary subtransaction for replica repair.

The main sub-transaction Paxos copy consistency submodule 211 is used to set the consistent log value on the witness copy in the witness copy group of the main sub-transaction, and transmit the log value and the position information of the main sub-transaction to the secondary sub-transaction submission sub-module, and Add a global transaction mark to this log entry; specifically, use the Paxos algorithm to try to achieve consistency in the log value at the same log position of each witness copy of the main subtransaction, and the log value in this main subtransaction The operation of writing the command is added with a timestamp, which is greater than the maximum committed log timestamp of the witness replica group before the execution of the Paxos algorithm.

Secondary sub-transaction Paxos copy consistency submodule 212 is used to set the consistent log value on the witness copy in the witness copy group of this secondary sub-transaction for all secondary sub-transactions, add the main sub-transaction to the log entries of all secondary sub-transactions Transaction location information and global transaction markers, and the log value of the main sub-transaction and the log values of all secondary sub-transactions are transferred to the main sub-transaction commit submodule; specifically, using the Paxos algorithm, for each secondary sub-transaction transaction, try to achieve the consistency of the log value at the same log position of each witness copy of the secondary sub-transaction, and the log value adds a timestamp to the operation of the write command in this secondary sub-transaction, and the timestamp is greater than this Paxos The maximum committed log timestamp of the witness copy group before the algorithm is executed.

The global write transaction submission submodule 213 is used to submit the log value of the main subtransaction to the corresponding readable copy according to the address of the readable copy of the main subtransaction and the response number V of the required readable copy, and process the successful result Return to the global write transaction management submodule 212, after processing successfully, the log of each secondary subtransaction according to the address of the readable copy of the secondary subtransaction and the response number V of the required readable copy Values are committed to the corresponding readable replica.

The global write transaction management submodule 212 is also configured to send the successful processing result to the external interface submodule 101 .

The external interface sub-module 101 is also used to send the result of successful processing to the client.

Example:

In order to verify the feasibility and effectiveness of the method of the present invention, the system is configured in a real environment, and experiments are carried out on distributed transactions using multiple types of replicas in a decentralized architecture.

Server basic hardware and software configuration of the present invention are as shown in table 1:

Table 1

The invention effectively combines multi-type copies with distributed transaction processing in a decentralized architecture. It uses a decentralized architecture, which provides strong scalability, and its copy mechanism improves data reliability, recoverability, and higher data availability, and provides a strongly consistent distributed transaction function. The system uses multi-type replicas to separate the read-write physical nodes of distributed transactions, effectively reducing the impact of node failure on the availability of read and write transactions, which is of great significance for configuring distributed transactions with appropriate read-write availability for different application scenarios. It has great application potential.

It is easy for those skilled in the art to understand that the above descriptions are only preferred embodiments of the present invention, and are not intended to limit the present invention. Any modifications, equivalent replacements and improvements made within the spirit and principles of the present invention, All should be included within the protection scope of the present invention.

Claims (7)

1. in a decentralization framework, use the distributing real time system system of polymorphic type copy, comprise transaction interface module, transaction model and affairs memory module, transaction interface module comprises external interface submodule and transaction preprocess submodule, transaction model comprises polymorphic type copy submodule, read issued transaction submodule, replica group transaction status submodule, read request distribution submodule, submodule repaired by copy, MVCC reading submodule, issued transaction submodule is write in local, affairs Paxos copy consistency submodule is write in local, local is write affairs and is submitted submodule to, global write issued transaction submodule, main subtransaction Paxos copy consistency submodule, secondary subtransaction Paxos copy consistency submodule and global write affairs submit submodule to, it is characterized in that,

This transactions requests for receiving the transactions requests from client, and is sent to transaction preprocess submodule by external interface submodule;

Transaction preprocess submodule is for judging that transactions requests is read transactions requests or writes transactions requests, if read transactions requests, then will read transactions requests to be sent to and to read issued transaction submodule, if write transactions requests, then judging that this writes transactions requests is further that transactions requests or global write transactions requests are write in local, if transactions requests is write in local, then this local is write transactions requests be sent to local write issued transaction submodule, if global write transactions requests, then this global write transactions requests is sent to global write issued transaction submodule;

Read issued transaction submodule and read the address of hard copy corresponding to instruction and the response quantity of needs for each obtaining from polymorphic type copy submodule that this reads to comprise in transactions requests, and be sent to replica group transaction status submodule by reading transactions requests, the address of hard copy and the response quantity of needs, and control the whole timeout retry reading transactions requests treatment scheme;

Replica group transaction status submodule is used for the affairs executing state read according to the address of hard copy in corresponding replica group, reads instruction corresponding each maximum submission state daily record numbering and maximum submission state log timestamp to obtain;

Read request distribution submodule judges to read reading instruction and whether can perform in this locality in transactions requests, if passable, then be sent to local copy repair submodule by reading instruction, maximum submission state daily record numbering and maximum submission state log timestamp, otherwise send to read any one hard copy corresponding to instruction by reading instruction, maximum submission state daily record numbering and maximum submission state log timestamp;

The maximum submission state daily record numbering place that submodule is used for obtain in the node updates at its place to replica group transaction status submodule repaired by copy;

MVCC reading submodule is used for reading data according to reading instruction and maximum submission state log timestamp from affairs memory module, and data is returned to and read issued transaction submodule;

Read issued transaction submodule also for data are sent to external interface submodule;

External interface submodule is also for being sent to client by data;

Issued transaction submodule writes witness copy corresponding to the write command that comprises in transactions requests and the address of hard copy and the hard copy of needs response quantity for obtaining this local from polymorphic type copy submodule is write in local, and transactions requests is write in local, the response quantity of witness copy and the address of hard copy and the hard copy of needs is sent to local and writes affairs Paxos copy consistency submodule, and control the timeout retry that transactions requests treatment scheme is write in whole local;

Affairs Paxos copy consistency submodule is write for arranging daily record value consistent on witness copy in witness replica group in local, this daily record value is sent to local and writes affairs and submit submodule to, and adds locally transaction tag for journal entry;

Local is write affairs and is submitted to submodule for daily record value being committed to corresponding hard copy according to the response quantity of the address of hard copy and the hard copy of needs, and successful for process result is returned to and locally write issued transaction submodule;

Issued transaction submodule is write also for successful for process result is sent to external interface submodule in local;

External interface submodule is also for being sent to client by successful for process result;

Global write issued transaction submodule is used for the response quantity obtaining witness copy corresponding to each write command of comprising this global write transactions requests and the address of hard copy and the hard copy of needs from polymorphic type copy submodule, and the response quantity of witness copy corresponding to global write transactions requests, each write command and the address of hard copy and the hard copy of needs is sent to main subtransaction Paxos copy consistency submodule, and control the timeout retry of whole global write transactions requests treatment scheme;

The daily record value that main subtransaction Paxos copy consistency submodule is consistent on witness copy in the witness replica group arranging main subtransaction, the positional information of this daily record value and main subtransaction is sent to secondary subtransaction and submits submodule to, and add that global transaction marks for this journal entry;

The daily record value that secondary subtransaction Paxos copy consistency submodule is consistent on witness copy in the witness replica group all secondary subtransactions being arranged to this secondary subtransaction, journal entry for all secondary subtransactions adds positional information and the global transaction mark of main subtransaction, and the daily record value of the daily record value of main subtransaction and all secondary subtransactions is sent to main subtransaction submission submodule;

Global write affairs submit to submodule to be used for, according to the response number of the address of the hard copy of main subtransaction and the hard copy of needs, the daily record value of main subtransaction is committed to corresponding hard copy, and successful for process result is returned to global write issued transaction submodule, by the daily record value of this secondary subtransaction, corresponding hard copy is committed to according to the response number of the address of the hard copy of this secondary subtransaction and the hard copy of needs to each secondary subtransaction processing successfully;

Global write issued transaction submodule is also for being sent to external interface submodule by successful for process result;

External interface submodule is also for being sent to client by successful for process result.

2. distributing real time system system according to claim 1, it is characterized in that, transaction preprocess submodule judges its type by the OPER field read in transactions requests, this field is that transactions requests is read in expression, transactions requests is write for representing, consistance hash function is utilized to carry out computing to the key writing each write operation comprised in transactions requests, and judge according to operation result the type writing transactions requests, if same node is all pointed in the key computing of all write operations, then this writes transactions requests is that transactions requests is write in local, otherwise is global write transactions requests.

3. distributing real time system system according to claim 1, it is characterized in that, copy is repaired submodule and all journal entries being less than this numbering is all obtained homogeneity value and judges whether to need to submit to, if the transaction types of this journal entry record is local affairs, then when journal entry reaches consistent in witness copy, namely think and can submit to, otherwise just submit blank operation to; If the transaction types of this journal entry record is global transaction, then except whether needs inspection reaches unanimously in witness copy, also to check whether the main subtransaction of storage is submitted to, when main subtransaction is submitted to, just think and can submit to, otherwise just submitting blank operation to, finally all affairs needing to submit to being performed to completing state.

4. distributing real time system system according to claim 1, it is characterized in that, it is use Paxos algorithm that affairs Paxos copy consistency submodule is write in local, attempt reaching the consistent of daily record value on the same iog location of each witness copy, this daily record value is that this time locally writing the operation of write command in transactions requests adds timestamp, and this timestamp is greater than the maximum submission state log timestamp that this Paxos algorithm performs this witness replica group front.

5. distributing real time system system according to claim 1, it is characterized in that, global write affairs comprise two or more local and write affairs, all can be coupled with global transaction mark, one of them can be designated as main subtransaction, and is used by as submission point, and other local are write affairs and are designated as secondary subtransaction, the positional information of main subtransaction will be recorded, for copy reparation.

6. distributing real time system system according to claim 1, it is characterized in that, main subtransaction Paxos copy consistency submodule uses Paxos algorithm, attempt reaching the consistent of daily record value on the same iog location of each witness copy of main subtransaction, this daily record value is that the operation of write command in this main subtransaction adds timestamp, and this timestamp is greater than the maximum submission state log timestamp that this Paxos algorithm performs this witness replica group front.

7. distributing real time system system according to claim 1, it is characterized in that, secondary subtransaction Paxos copy consistency submodule uses Paxos algorithm, to each secondary subtransaction, attempt reaching the consistent of daily record value on the same iog location of each witness copy of secondary subtransaction, this daily record value for this reason in secondary subtransaction the operation of write command add timestamp, this timestamp be greater than this Paxos algorithm perform before the maximum submission state log timestamp of this witness replica group.