CN117931382A - Transaction guarantee method for server-oriented non-perception calculation - Google Patents

Abstract

The invention discloses a transaction guarantee method for server-oriented unaware computation, which ensures that the execution of workflow transactions accords with the serializable and accurate one-time execution of a session by designing a session serializable transaction protocol based on a clock barrier technology and providing a transaction fault-tolerant mechanism based on dependency tracking on the basis. Compared with the prior art that various consistency technologies are provided for a server non-perception computing platform, the transaction protocol designed by the invention can provide optimal performance and throughput, and meanwhile, various transaction anomalies can be avoided, and compared with the prior art and a general scheme, the transaction protocol is 2.2-6.5 times faster in end-to-end delay, and the throughput is improved by 1.5-8 times; compared with the prior art, the method has the advantages that the performance is improved, the application scene is expanded, the log proportion can be fully reduced by the optimistic log technology after comparison test, the system performance and the throughput are effectively improved, the end-to-end delay is 4.5-7 times faster than that of the scheme of all logging, and the throughput is improved by 1.6-2 times.

Description

Transaction guarantee method for server-oriented non-perception calculation

Technical Field

The invention belongs to the technical field of cloud computing, and relates to a business guarantee method for server-oriented non-perception computing.

Background

Server unaware computing is used as an emerging cloud computing programming model, and has become an increasingly popular cloud computing development paradigm due to the advantages of high abstraction of resources and programming, on-demand charging, dynamic capacity expansion and the like. In a server-unaware computing scenario, functionality in a legacy application is split into multiple stateless functions. In application development, transactions are widely used to ensure consistency and integrity of shared states, session serializability (Strong Session Serializability) is a variant of serializable isolation, can provide good performance while ensuring serializable and session consistency, is the best choice of performance and consistency for applications with transactional session consistency and avoiding concurrent abnormal requirements such as write skew, but existing servers do not have the separation of execution and state management of functions in a aware-less computing platform design, functions rely on external cloud storage to manage states between functions, but transactions in a workflow may span multiple functions or have multiple data sources, and existing cloud storage cannot provide such global transaction consistency, so relying on cloud storage alone to manage consistency requirements of applications cannot be met, and how to explore how to provide session serializability for server-less computing workflows is needed.

At present, the work of providing consistency guarantee for a server-less computing platform is focused on providing weak consistency without coordination and strongest strict serialization, and related research of providing session serialization for workflow is lacking. However, there are two major challenges to providing session serializable for server unaware computing workflows: (1) While there is more work in the current transaction protocol that provides serializable guarantee in the stateful database field, on the basis of which it is guaranteed that transactions in the same session are ordered, the prior art needs to save the last executed session state, such as database connection, commit timestamp, and the like, which contradicts the feature of function non-state in the server non-aware computing platform, in which requests may be forwarded to different function instances, and function instances may be reclaimed at any time, so that session consistency cannot be guaranteed, and therefore a management mechanism for transaction state needs to be designed for the server non-aware computing platform; (2) The server-agnostic computing platform typically provides a fault tolerant mechanism at least once, and re-executes when a function or workflow fails, but may also cause a problem of repeated execution of a transaction in the workflow because the server-agnostic computing platform cannot perceive the execution state of the transaction.

Disclosure of Invention

Aiming at the technical problems existing in the prior art, the invention aims to provide a server-oriented transaction guarantee method without perceived computation, which ensures that the execution of workflow transactions accords with the serialization and the accurate one-time execution of the session by designing a session serializable transaction protocol based on a clock barrier technology and providing a transaction fault-tolerant mechanism based on dependency tracking on the basis, and solves the problems of the lack of the serializable guarantee of the session in the prior server-oriented computing application.

In order to achieve the above purpose, the present invention adopts the following technical scheme:

a business guarantee method for server-oriented non-aware computing comprises the following steps:

S1, a user initiates a workflow request, wherein the workflow comprises a plurality of transactions;

S2, associating each request of the initiated workflow with a unique request ID;

s3, executing a transaction of the workflow, wherein the execution of the transaction comprises three phases of execution, preparation and submission of a transaction protocol;

s4, continuing to execute the next transaction of the workflow;

S5, returning an execution result of the workflow.

Preferably, in step S3, the execution of the transaction includes three phases of execution, preparation and submission of a transaction protocol, and specifically includes the following steps:

The execution stage: the two parts of the acquisition of the clock barrier and the execution of the orchestrator function are included, in particular: when the orchestrator function obtains the clock barrier asynchronously according to the requested session identification, and the orchestrator function orchestrates other functions of the call workflow, when the other functions execute writing operation, the transaction manager needs to be tried to lock and obtain the latest lease of the object, the reading operation is directly forwarded to the data cache, when the object is read or written, the logical lease is returned, the read and written data is stored in the transaction buffer area of the node actually executed by the function, and when the call function is orchestrated, only the metadata of the read and write set is transferred.

The preparation stage: the commit timestamp is computed, then the read-write set of the transaction is validated, the write data is saved to a temporary table, and a decision is made as to whether to commit, the computed commit timestamp (cts) meeting the Session serializable only if the following three conditions are met:

(1)

(2)

(3)cts≥T.TF。

Satisfying the condition (1) and the condition (2) can only ensure that the execution of the transaction is consistent with serializable, and the condition (3) relies on clock barrier technology to ensure transaction session consistency.

After the TF acquisition is completed, a commit timestamp is calculated according to the above conditions, if the timestamp is not present, the transaction will be aborted, otherwise, the transaction manager will verify the read-write set: for a read set, the verification process is lease stored in an extended transaction manager; for a write set, since it needs to be ensured that the write set has been persisted into the temporary table and the lock is not lost, verification is also needed, the transaction can be committed only after all passes of the verification, and a session information record transaction log needs to be saved before commit.

A submitting stage: if the transaction confirmation can be submitted, the transaction cache responsible for coordination asynchronously informs all participating transaction managers to synchronize the write set into the actually used table, then unlock and clear the temporary storage area, and finally delete the read/write set of the submitted transaction in each node transaction buffer.

Preferably, in step S3, if the committed transaction is completed, but fails before the result is returned to the user or the orchestrator, logging needs to be deferred by an optimistic logging policy based on dependency tracking, and logging is performed only when an inconsistent output scenario is found to be possible, which is specifically divided into two steps of transaction type marking and selective logging:

(1) Transaction type tag: the transaction type tag is used to identify characteristics and dependencies of transactions in the dynamic workflow, including whether the transactions are read-only, and the dependency of the transactions, and the tagging process identifies read-write sets and input sources to proceed in the preparation phase of the session serializable transaction protocol. The online marking mode does not require the structure and execution logic of the workflow to be fixed, can support dynamic workflow, and has more common use occasions;

(2) Selective logging: distinguishing read-write transaction from read-only transaction in the process of selective log recording, wherein the read-only transaction is only stored in a transaction buffer zone, and the output of the read-write transaction is required to be recorded so as to ensure that the write operation cannot be repeatedly executed; when recording a read-write transaction, it needs to determine whether there are other transactions parallel to it, if so, it needs to record the result of a common ancestor transaction to ensure that the output seen by the transactions in the workflow is consistent, which needs to traverse all ancestor transactions on which the read-write transaction depends in the transaction buffer with breadth first, and the parallel determination is based on the split convergence principle, specifically: flow=1 is passed at the beginning of the workflow, branches are evenly divided when they occur, and whether other parallel transactions exist is determined according to the relative size of the position flow in the workflow, so the log record of read-only transactions in the transaction buffer is deferred until it is found that there are parallel transactions depending on its output.

The invention has the beneficial effects that:

(1) In the invention, the design of the transaction protocol references the existing work, and on the basis, a clock barrier technology is designed for the characteristic that the server does not have a perception of the state of the computing platform, so that the persistence time is reduced by 99% compared with the scheme of directly using cloud storage to manage the session while the loss of session consistency is compensated, and the scheme is proved to be capable of fully reducing persistence expenditure. In order to enable the stages of the transaction protocol to be efficiently executed on the server-agnostic computing platform, buffering is fully utilized to manage transaction states during design, and parallelism is used to shorten the critical path length of the protocol as much as possible. Finally, compared with the prior art for providing various consistencies for the server non-aware computing platform, the transaction protocol designed by the invention is found to provide optimal performance and throughput, and meanwhile, various transaction anomalies can be avoided, compared with the prior art and the general scheme, the transaction protocol is 2.2-6.5 times faster in end-to-end delay, and the throughput is improved by 1.5-8 times.

(2) The transaction fault-tolerant part in the invention records only when the dependency relationship is found, the dynamic workflow is supported by utilizing the thought of online detection, and the log overhead is reduced by selective log recording. After comparison test, the optimistic log technology designed by the invention can fully reduce the log proportion, effectively improve the performance and throughput of the system, and is 4.5-7 times faster in end-to-end delay than the scheme of all logging, and the throughput is improved by 1.6-2 times.

Drawings

FIG. 1 is a block diagram of a server-oriented, non-aware computing transaction assurance system according to the present invention;

FIG. 2 is a flow diagram of stages of a transaction protocol;

FIG. 3 is an example diagram of fault tolerant policy log decisions.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

Because the transaction in the workflow may span multiple functions or have multiple data sources, and the server does not have a aware computing platform and cannot perceive the execution state of the transaction, the manner of simply using cloud storage to implement the transaction cannot guarantee global transaction consistency and fault tolerance. The invention designs a session serializable transaction protocol based on a clock barrier technology, and provides a transaction fault-tolerant mechanism based on dependency tracking on the basis, so as to ensure that the execution of the workflow transaction accords with the serializable session and is accurately executed once.

1. System architecture

In order to meet SERVERLESS application consistency and fault tolerance requirements, the invention provides a server-oriented transaction guarantee method for non-aware computing, and particularly provides a set of session serializable transaction protocols for server-oriented workflow of non-aware computing. The basic idea of the protocol is to design a clock barrier mechanism to acquire a non-decremental logic clock from a cache on the basis of a distributed concurrency control protocol (Sundial) so as to ensure that a sequence of commit timestamps of transactions initiated by the same client in sequence accords with a session serializable, and then determine whether the transactions need a log according to a transaction dependency relationship in a workflow to ensure fault tolerance. Referring to fig. 1, a transactional SERVERLESS platform is designed for a server-oriented, non-aware computing transaction security system, and for meeting the requirements of a session serializable transaction protocol for state management, the transactional SERVERLESS platform is designed for managing transaction states based on cache. The specific functions of each component are as follows: (1) when the function is running: arranging a workflow and forwarding the transaction and the read or write operation to a transactional cache; (2) transactional cache: saving the temporary state of the recently accessed object and transaction, wherein the transactional cache is used as a key value cache in a local memory and runs at each SERVERLESS node; (3) transaction manager: transaction coordination operations, such as locking and verification, are performed and a metadata cache consisting of session information and logical leases is maintained in memory. (4) etcd: the configuration of the cluster and the transaction execution log are stored. (5) Cluster manager: automatic expansion of the transaction manager and fault-tolerant recovery policies are performed. The transaction protocol runs on top of the architecture, and in stages of the protocol it will be introduced how the components work together to provide session serializable guarantees for the application.

The invention provides a server-oriented transaction guarantee method without perceived computation, which comprises the following steps: a user initiates a workflow request, wherein the workflow comprises a plurality of transactions; associating each request of the initiated workflow with a unique request ID; executing a transaction of a workflow, wherein the execution of the transaction comprises three phases of execution, preparation and submission of a transaction protocol; the execution of each stage of the transaction protocol needs to interact with the transactional cache and the transaction manager to perform operations such as reading, writing, verification and the like, whether the log is needed or not is judged based on the fault tolerance policy of the invention before the transaction is submitted, then the next transaction in the workflow is continuously executed, and finally the execution result of the workflow is returned.

2. Session serializable transaction protocol

The session serializable transaction protocol for a server-oriented unaware computing platform of the present invention is extended on the basis of the distributed concurrency control protocol, which uses the hybrid concurrency control protocol and dynamically reorders transactions according to logical leases. However, the Sundial is a stateful data storage scenario, and to apply it to a server-agnostic computing platform, it is also necessary to redesign each stage of the transaction protocol. Furthermore, since functions may execute on different nodes, stale caches may be seen to violate transaction session consistency, which is inconsistent with the objective of the present invention to provide session serializable transactions.

To this end, the present invention devised a clock barrier technique to promote the isolation level of a local from serializable to session serializable, the core idea of which is to generate a monotonic logic clock to ensure that commit timestamps of transactions initiated in sequence by the same client are not decremented.

Acquisition procedure of clock barrier (TF): when the TF is acquired from the transaction manager, an upper bound time stamp of the metadata is returned if the corresponding session information does not exist. The TF is a monotone logic clock in nature, so that the value of the TF obtained by the same client is always forward, the callback phenomenon of the clock does not occur, the logic sequence of the subsequent transaction submission of the same client can be ensured to be necessarily after the transaction is submitted in the past, and the transaction manager only needs to ensure that the upper bound timestamp is not lost, so that the persistence expenditure can be greatly reduced.

Referring to fig. 2, the operations performed at each stage of the transaction protocol and the dependency relationship between the operations are shown, the critical path of the transaction protocol covers the process from starting to ending the transaction, the later commit stage is performed asynchronously after the transaction execution result is returned, and the parallel and asynchronous processing capacities of each stage are fully utilized in the design of the transaction protocol, so as to shorten the length of the critical path as much as possible and accelerate the execution speed of the transaction protocol. The operation of each stage fully utilizes the cache, and the specific operation is as follows:

The execution stage: two parts of the execution of the acquisition and orchestrator functions, including the clock barrier (TF), are: the orchestrator function asynchronously acquires the clock barrier according to the requested session identification, while the orchestrator function orchestrates other functions that invoke the workflow. Each object has a logical lease meaning that the object is valid for a logical time interval wts, trs, the execution of a write operation in a function requires an attempt to lock on the transaction manager and obtain the latest lease for the object, while a read operation is forwarded directly to the data cache, and returns its logical lease when the object is read or written. The read-write data are stored in the transaction buffer of the node where the function is actually executed, and only the metadata of the read-write set are transferred when the calling function is arranged.

The preparation stage: the commit timestamp is computed, then the read-write set of the transaction is validated, the write data is saved to a temporary table, and a decision is made as to whether to commit, the computed commit timestamp (cts) meeting the Session serializable only if the following three conditions are met:

(1)

(2)

(3)cts≥T.TF。

Satisfying the condition (1) and the condition (2) can only ensure that the execution of the transaction is consistent with serializable, and the condition (3) relies on clock barrier technology to ensure transaction session consistency.

After the TF acquisition is completed, a commit timestamp is calculated according to the above conditions, if the timestamp is not present, the transaction will be aborted, otherwise, the transaction manager will verify the read-write set: for a read set, the verification process is lease stored in an extended transaction manager; for a write set, since it needs to be ensured that the write set has been persisted into the temporary table and the lock is not lost, verification is also needed, the transaction can be committed only after all passes of the verification, and a session information record transaction log needs to be saved before commit.

A submitting stage: if the transaction confirmation can be submitted, the transaction cache responsible for coordination asynchronously informs all participating transaction managers to synchronize the write set into the actually used table, then unlock and clear the temporary storage area, and finally delete the read/write set of the submitted transaction in each node transaction buffer.

3. Session serializable transaction fault tolerance mechanism

Referring to fig. 3, if the transaction commit is completed but fails before the result is returned to the user or the orchestrator, a common method for the current server unaware computing platform in this scenario is a retry function, but this may result in repeated commit of the committed transaction, possibly causing serious problems such as repeated payments. Thus, the present invention devised an optimistic logging strategy based on dependency tracking, using as few logging operations as possible to guarantee an accurate one-time execution of transactions, the core idea being to ensure that the output seen by all transactions is consistent when repeatedly executing by analyzing workflow dependencies during execution. This requires that the output of a common ancestor transaction observed by all transactions in parallel in the workflow be consistent, although a simple solution is to log all transactions, this may cause additional overhead to read-only transactions, since read-only transactions do not modify the external state, only produce output. The optimistic logging strategy based on dependency tracking designed in the present invention postpones logging only when inconsistent output observations are found. The method can be divided into two steps: transaction type flags and optional log records.

Transaction type tag: the transaction type tag is used to identify characteristics and dependencies of transactions in the dynamic workflow, including whether the transactions are read-only, and the dependency of the transactions, and the tagging process identifies read-write sets and input sources to proceed in the preparation phase of the session serializable transaction protocol. The online marking mode does not require the structure and execution logic of the workflow to be fixed, can support dynamic workflow, and is more universal in use scenario.

Selective logging: the read-write transaction is distinguished from the read-only transaction in the process of selective logging, the read-only transaction is only stored in the transaction buffer, and the output of the read-write transaction must be logged to ensure that the write operation is not repeatedly performed. When recording read-write transaction, it needs to judge whether there are other transactions parallel to it, if yes, it needs to record the result of common ancestral transaction to ensure that the output seen by the transaction in the workflow is consistent, this needs to traverse all ancestral transactions on which the read-write transaction depends in the transaction buffer area by breadth first, the parallel judgment is based on the split convergence principle designed and proven by the invention, the flow=1 is transferred at the beginning of the workflow, when branching occurs, it is evenly divided, and it can judge whether there are other parallel transactions according to the relative size of the position flow in the workflow. Thus, the log record of read-only transactions in the transaction buffer is deferred until it is found that there are parallel transactions that rely on their output.

Example 1

1. Session serializable transaction execution in a workflow

Using r to denote a read operation, w to denote a write operation, x and y to be object names, functions 1 and 2 are executed sequentially and within the same transaction, taking the following workflow execution example, the database operation in each function is: function 1: r (x), r (y); function 2: r (x), w (x).

There is a function in the system that is responsible for the orchestration operation, in this example, functions 1 and 2 are called in order, and when functions 1 and 2 perform read and write operations, a logical lease wts, trs is returned at the same time. Assuming that SERVERLESS has only y data in the data cache of node 1, its lease is [3,5], and node 2 has only x data in the data cache, its lease is [4,6]; the transaction manager has a node in which the maximum timestamp in the metadata cache is 8, where x lease [4,7], y lease [3,6]; function 1 is executed at SERVERLESS node 1 and function 2 is executed at SERVERLESS node 2. The session serializable protocol of the present invention has the following execution flow at each stage:

The execution stage: when the orchestration function is started, according to the client identifier in the request, a clock barrier corresponding to the client is acquired from the transaction manager, and the session information of the client is not available, so that the obtained result is an upper bound timestamp 8. The operations of function 1 to perform reads x and y will be forwarded first to the transactional cache local to each node, returning the result if there is an object in the data cache, otherwise reading the data from the cloud storage. The lease from which function 1 ultimately reads data is x 4,7, y 3,5, respectively. After the execution of the function 1 is completed, the scheduler will transfer the lease of the read set as a parameter to the function 2, when the function 2 reads x, it finds that x of the read-write set is identical to wts of x in the cache of the node 2, so the cache will be directly read, otherwise, data will be read from the transaction buffer of the node 1, when x is written, the object lock and the latest lease will be obtained from the transaction manager first, the lock can be continuously executed after successful obtaining, otherwise, the transaction is aborted, and finally the lease of the read-write set of the function 2 is about x [4,7].

The preparation stage: the read set comprises y [3,5], the write set comprises x [4,7], the minimum commit time stamp is calculated according to the acquired clock barrier 8 and the read-write set, the commit condition can be met, then the y lease in the transaction manager is expanded from [3,6] to [3,8], whether the lock of x still exists and written data is durable is detected, the client session information is updated to 8 after the read-write set is verified successfully, and the last output result is written into a log because the upper bound time stamp of the transaction manager is not changed during updating, the durability is not needed.

Asynchronous commit phase: the new data for x and new leases [8,8] are synchronized to cloud storage, then the transaction temporary state is unlocked and cleared.

The execution of the workflow will end after the execution and preparation phases and then return the results, and finally the system will synchronize the data asynchronously, ensuring that the session can be serialized through the above-described flow.

2. Session serializable transaction fault tolerance mechanism

For a simple scene of a single read-only transaction, the transaction fault tolerance mechanism of the invention can directly omit a log record link after finding that no subsequent dependency exists. For a complex scenario of multiple transactions, in order to fully explain the log decision process of the transaction fault tolerance (policy) mechanism, a workflow composed of 4 transactions and 8 functions as shown in fig. 3 is taken as an example. Orange indicates no transaction is parallel to it, white indicates a transaction is parallel to it, the dashed border indicates no logging is needed, and the solid line indicates logging is needed. The specific decision flow is as follows:

flow=1 at T1, followed by the split at T2 and T3 And again converge to 1 at T4. When T1 and T2 execution is complete, the log is only saved in the in-transaction buffer since its write set is found to be empty during the preparation phase. When T3 is completed, since the write set is not empty, the log of T3 must be recorded, so that the ancestor transaction of T3 is traversed first to determine whether there is a parallel situation, T3 depends only on T1, and the flow of T1 is greater than that of T3, which indicates that T1 is a branch point, and there are other transactions parallel to T3, so that it is necessary to ensure that the output of T1 is consistent for the subsequent transactions, so that the output of T1 and T3 is sequentially persisted at this time. Finally, when the execution of the T4 is completed, since the flow of the T2 and the T3 which directly depend on and the flow of the T1 which indirectly depend on are not larger than the flow of the T4, only the log of the T4 is required to be durable. The final logs to be recorded are T1, T3 and T4, and the log of the persistent T2 is omitted.

The invention takes selective persistence as a core thought for realizing a state management part in a transaction protocol, and can greatly reduce delay and improve throughput while providing a conversation serializable and accurate once semantic.

In terms of delay, in the transaction execution link of the above embodiment, the delay of reading the session state from the remote cache is about 0.3 ms, and the operation of updating the session state can be omitted, which is greatly reduced compared with the delay of reading and writing session data of 1.5 ms and 2.3 ms in the original scheme based on the cloud storage management session state; in the logging link, for a single read-only transaction, the link can be directly omitted because of no dependency, reducing the logging overhead by about 3.6 milliseconds compared to the full logging scheme used by existing work.

From the throughput aspect, the invention tests under different QPSs (query per second), and experimental results show that the number of times of the persistent session information and the number of times of the persistent fault-tolerant log are reduced by 99% at the highest, so that the I/O pressure of the underlying storage system is effectively reduced, and the total throughput of the system is increased.

Compared with the prior art for providing various consistencies for a server non-aware computing platform, the transaction protocol designed by the invention is found to provide optimal performance and throughput, various transaction anomalies can be avoided, the end-to-end delay is 2.2-6.5 times faster than that of the prior art and a general scheme, and the throughput is improved by 1.5-8 times.

The transaction fault-tolerant part in the invention records only when the dependency relationship is found, the dynamic workflow is supported by utilizing the thought of online detection, and the log overhead is reduced by selective log recording. After comparison test, the optimistic log technology designed by the invention can fully reduce the log proportion, effectively improve the performance and throughput of the system, and is 4.5-7 times faster in end-to-end delay than the scheme of all logging, and the throughput is improved by 1.6-2 times.

The invention provides a transaction guarantee method for server-oriented unaware computing, in particular to a session serializable transaction protocol and a transaction fault tolerance technology for server-oriented unaware computing workflow, which can provide session serializable transaction support for the workflow and ensure accurate one-time execution of the transaction. Compared with the prior art, the invention firstly extends the session serializable to the server non-perception computing platform, designs the session serializable transaction protocol based on the clock barrier, fully utilizes the cache when the protocol is designed, reduces the communication times with the cloud storage as much as possible by only storing the maximum clock in the metadata cache, and designs the optimistic log recording strategy based on dependency tracking on the basis, analyzes the dependency relationship on line during execution, selectively records the state of the transaction, and ensures the accurate one-time execution of the session serializable transaction in the workflow.

The foregoing is only a preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art, who is within the scope of the present invention, should make equivalent substitutions or modifications according to the technical solution and the modified concept thereof, within the scope of the present invention.

Claims (3)

1. A business guarantee method for server-oriented non-perception calculation is characterized in that: the method comprises the following steps:

S1, a user initiates a workflow request, wherein the workflow comprises a plurality of transactions;

S2, associating each request of the initiated workflow with a unique request ID;

s3, executing a transaction of the workflow, wherein the execution of the transaction comprises three phases of execution, preparation and submission of a transaction protocol;

s4, continuing to execute the next transaction of the workflow;

S5, returning an execution result of the workflow.

2. The server-agnostic computing-oriented transaction assurance method of claim 1, wherein: in step S3, the execution of the transaction includes three phases of execution, preparation and submission of the transaction protocol, specifically including the following steps:

The execution stage: the two parts of the acquisition of the clock barrier and the execution of the orchestrator function are included, in particular: when the orchestrator function acquires a clock barrier asynchronously according to the requested session identification, and the orchestrator function orchestrates other functions of the call workflow, when the other functions execute writing operation, the transaction manager needs to be tried to lock and acquire the latest lease of the object, the reading operation is directly forwarded to a data cache, when the object is read or written, the logical lease is returned, the read and written data is stored in a transaction buffer area of a node actually executed by the function, and when the call function is orchestrated, only metadata of a read and write set is transferred;

The preparation stage: the commit timestamp is computed, then the read-write set of the transaction is validated, the write data is saved to a temporary table, and a decision is made as to whether to commit, the computed commit timestamp (cts) meeting the Session serializable only if the following three conditions are met:

(1)

(2)

(3)cts≥T.TF；

Satisfying the condition (1) and the condition (2) can only ensure that the execution of the transaction accords with serializable, and the condition (3) depends on a clock barrier technology to ensure the consistency of the transaction session;

After the TF acquisition is completed, a commit timestamp is calculated according to the above conditions, if the timestamp is not present, the transaction will be aborted, otherwise, the transaction manager will verify the read-write set: for a read set, the verification process is lease stored in an extended transaction manager; for a write set, since it needs to ensure that the write set has been persisted into a temporary table and that the lock is not lost, verification is also needed, and only after all the verification passes, the transaction can be submitted, and a session information record transaction log needs to be saved before the transaction is submitted;

a submitting stage: if the transaction confirmation can be submitted, the transaction cache responsible for coordination asynchronously informs all participating transaction managers to synchronize the write set into the actually used table, then unlock and clear the temporary storage area, and finally delete the read/write set of the submitted transaction in each node transaction buffer.

3. The server-agnostic computing-oriented transaction assurance method of claim 1, wherein: in step S3, if the commit transaction is completed, but fails before the result is returned to the user or the orchestrator, logging needs to be deferred by an optimistic logging policy based on dependency tracking, and logging is performed only when an inconsistent output observation is found to be possible, which is specifically divided into two steps of transaction type marking and selective logging:

(1) Transaction type tag: the transaction type tag is used to identify characteristics and dependencies of transactions in the dynamic workflow, including whether the transactions are read-only, and the dependency of the transactions, and the tagging process identifies read-write sets and input sources to proceed in the preparation phase of the session serializable transaction protocol. The online marking mode does not require the structure and execution logic of the workflow to be fixed, can support dynamic workflow, and has more common use occasions;

(2) Selective logging: distinguishing read-write transaction from read-only transaction in the process of selective log recording, wherein the read-only transaction is only stored in a transaction buffer zone, and the output of the read-write transaction is required to be recorded so as to ensure that the write operation cannot be repeatedly executed; when recording a read-write transaction, it needs to determine whether there are other transactions parallel to it, if so, it needs to record the result of a common ancestor transaction to ensure that the output seen by the transactions in the workflow is consistent, which needs to traverse all ancestor transactions on which the read-write transaction depends in the transaction buffer with breadth first, and the parallel determination is based on the split convergence principle, specifically: flow=1 is passed at the beginning of the workflow, branches are evenly divided when they occur, and whether other parallel transactions exist is determined according to the relative size of the position flow in the workflow, so the log record of read-only transactions in the transaction buffer is deferred until it is found that there are parallel transactions depending on its output.