Electronic warrant issuing method and system

Abstract

The invention discloses an electronic warrant issuing method and system, and relates to the technical field of electronic warrant issuing, the information of a node receiving a warrant issuing request is obtained, the node is marked as an RL node, after the RL node receives the warrant issuing request, a Paxos protocol is used to propose a new proposal, the RL node copies the warrant issuing request to all Follower nodes, and the warrant issuing request is sent to the Follower nodes. The method comprises the following steps: before a warrant is issued and after a plurality of node states are obtained, predicting the running state development trend of a Follower node, automatically carrying out new RL node election when the node running is predicted to be abnormal, and if a warrant issuing request is copied and confirmed in a corresponding number of nodes, sending a successful response to a client by the RL node. The issuing system performs consistency verification, so that all the nodes are always kept consistent in data records, the problem that the states of different nodes are not synchronous is avoided, and the recovery capability of the system is improved through a rollback mechanism.

Description

Technical Field

[0001] The present invention relates to the technical field of electronic letter of guarantee issuance, and in particular to a method and system for electronic letter of guarantee issuance. Background Art

[0002] An electronic guarantee is a performance guarantee tool provided by banks or financial institutions to enterprises or individuals based on electronic technology. Its main function is to provide a guarantee for one party to the contract (usually the promisee or the debtor) to perform its contractual obligations. When the other party breaches the contract, the party can perform the compensation liability according to the guarantee agreement.

[0003] The issuance system is an electronic service system based on information technology, which aims to provide enterprises or individuals with convenient and fast electronic letter of guarantee issuance, management and verification services. Electronic letters of guarantee are usually issued by banks or financial institutions as a guarantee tool to provide credit support during the transaction process to ensure that in the event of a breach of contract during the performance of the contract, the payment obligations can be fulfilled in accordance with the terms of the contract.

[0004] The prior art has the following defects:

[0005] 1. In a distributed system, especially when multiple nodes are involved, ensuring data consistency among all nodes is a major challenge. Without a unified protocol, different nodes may store different data states, which in turn affects the stability and reliability of the system.

[0006] 2. In distributed systems, there is often a single point of failure problem. If the master node or leader node fails, the entire system may not be able to continue working, resulting in service interruption or data loss. When a failure occurs (such as node crash or network partition), there is often a lack of effective mechanisms to restore the system state, especially how to synchronize and maintain consistency after the node is restored.

[0007] Based on this, the present invention proposes a method and system for issuing an electronic letter of guarantee to perform consistency verification so that all nodes always remain consistent in data records, avoiding the problem of state asynchrony between different nodes, and improving the system's recovery capability through a rollback mechanism. Summary of the invention

[0008] The purpose of the present invention is to provide a method and system for issuing an electronic letter of guarantee to solve the deficiencies in the background technology.

[0009] In order to achieve the above object, the present invention provides the following technical solution: a method for issuing an electronic letter of guarantee, the method comprising the following steps:

[0010] The issuance system obtains the node information that receives the guarantee issuance request and marks the node as an RL node. After receiving the guarantee issuance request, the RL node uses the Paxos protocol to propose a new proposal. After the Paxos protocol votes in unanimity, the RL node copies the guarantee issuance request to all its Follower nodes.

[0011] Before the letter of guarantee is issued, after obtaining the status of multiple Follower nodes, the operating status development trend of the Follower nodes is predicted, and when any Follower node is predicted to be abnormal, a new RL node is automatically elected;

[0012] The new RL node recovers from the previous log and resynchronizes the status of all nodes. If the request for issuance of the letter of guarantee is replicated and confirmed in the corresponding number of nodes, the RL node sends a success response to the client.

[0013] In a preferred embodiment, after receiving the request for issuance of a letter of guarantee, the RL node uses the Paxos protocol to propose a new proposal, including the following steps:

[0014] The RL node uses the guarantee request as a proposal for the Paxos protocol, and the guarantee request information is used as the proposed content of the Paxos proposal.

[0015] The RL node generates a unique proposal number, which is used to identify the current proposal. The RL node sends a Prepare message of the Paxos protocol to the Follower node in the cluster. The Prepare message contains the proposal number, requests other nodes to vote on the current proposal, and requires all nodes to respond whether to accept the current proposal.

[0016] After receiving the Prepare message, each Follower node responds according to the rules of the Paxos protocol:

[0017] If all proposal numbers in the node are less than or equal to the current proposal number, the node responds that it agrees to accept the current proposal. If any proposal number in the node is greater than the current proposal number, the node returns a rejection message to the RL node and sends the proposal number with a number greater than the current proposal number to the RL node.

[0018] The RL node collects responses from all nodes. If the number of nodes that agree to accept the current proposal is greater than or equal to the threshold, the Paxos protocol considers that the current proposal has reached a consensus.

[0019] When the Paxos protocol believes that the current proposal has reached a consensus, the RL node sends an Accept message to the Follower node, requesting to accept the current proposal. The Accept message contains the proposal number and the request for the issuance of a letter of guarantee.

[0020] After receiving the Accept message, each Follower node confirms and stores the current proposal and marks the current proposal as accepted. After the Follower node confirms that the log has been received and the synchronization is successful, it updates the local log.

[0021] In a preferred embodiment, before the letter of guarantee is issued, after obtaining the status of multiple Follower nodes, the operating status development trend of the Follower nodes is predicted, including the following steps:

[0022] Before issuing the letter of guarantee, obtain the status data of multiple Follower nodes, including the operation queue index, log synchronization factor, and health index. After normalizing the operation queue index, log synchronization factor, and health index, comprehensively calculate and obtain the status coefficient.

[0023] The obtained state coefficient is compared with the preset coefficient threshold. The coefficient threshold is used to predict whether there is any abnormality in the operation of the Follower node. If the state coefficient is greater than or equal to the coefficient threshold, it is predicted that there is no abnormality in the operation of the Follower node. If the state coefficient is less than the coefficient threshold, it is predicted that there is an abnormality in the operation of the Follower node.

[0024] In a preferred embodiment, when it is predicted that any Follower node is running abnormally, a new RL node is automatically elected, including the following steps:

[0025] When a Follower node is detected to be operating abnormally, the automatic fault warning mechanism is triggered. By analyzing the monitoring data, the system will determine whether an RT node election is needed;

[0026] If the RL node is normal, continue to maintain the existing RL node. If the RL node is abnormal, trigger the Leader election;

[0027] When the Follower node initiates an election, it obtains the state coefficient and voting normalization value of the Follower node, and weights the state coefficient and voting normalization value to obtain the Follower node preference index, which is expressed as: yxsz = 0.7*Fzt + 0.3*tps, where yxsz is the preference index, Fzt is the state coefficient, and tps is the voting normalization value;

[0028] After obtaining the preferred indexes of all Follower nodes, all Follower nodes are sorted from large to small according to the preferred indexes, a sorting table is generated, and the Follower node ranked first in the sorting table is selected as the new RL node.

[0029] In a preferred embodiment, if the request for issuance of a letter of guarantee is replicated and confirmed in a corresponding number of nodes, the RL node sends a success response to the client, including the following steps:

[0030] The new RL node copies the recovered log entries to all Follower nodes. Each Follower node updates the local log and confirms the received log entries according to the log synchronization status of the new RL node.

[0031] When the new RL node copies and synchronizes the log, it compares the log entry number and proposal content information. If there are unsynchronized or lost log entries, the RL node requests synchronization again until all nodes are synchronized successfully;

[0032] If the new RL node finds that the request for issuance of a letter of guarantee has not been successfully submitted or is not fully synchronized, it will re-execute the request for issuance of a letter of guarantee. When resubmitting the request for issuance of a letter of guarantee, the RL node sends a new synchronization request to all nodes. If there are a corresponding number of Follower nodes confirming that the latest log entry for the request for issuance of a letter of guarantee has been synchronized, the RL node sends a confirmation response to the client, informing it that the electronic letter of guarantee has been issued.

[0033] In a preferred embodiment, the RL node copies the guarantee letter issuance request to all its Follower nodes, including the following steps:

[0034] After the Paxos protocol reaches consensus, the RL node will submit a proposal for the letter of guarantee issuance request and copy the proposal as a log entry to all Follower nodes. The replication process includes:

[0035] The RL node writes the letter of guarantee issuance request as a log entry in its local log, and the RL node copies the log entry to the log of each Follower node;

[0036] After receiving the log entry, the Follower node checks the integrity and consistency of the entry. If the log entry meets the requirements, the Follower node adds it to its own local log. After the Follower node receives and writes the log entry, it sends a confirmation message to the RL node.

[0037] In a preferred embodiment, the calculation expression of the operation queue index is: Where T is the monitoring duration, Queue Length(t) is the length of the operation queue at time t, λ is the decay coefficient, and Task Processing Rate(t) is the rate at which the node processes tasks at time t.

[0038] The calculation expression of the log synchronization factor is:

[0039] Where MaxSync Lag is the maximum synchronization delay, Log Sync Failures is the node log synchronization failure rate, Log Matching Ratio is the log matching ratio, and Sync Load Factor is the synchronization load factor;

[0040] The calculation expression of the health index is:

[0041] In the formula, Available Resources is the remaining percentage of the node's current CPU, Total Resources is the total resources of the node, and Uptime Factor is the normalized value of the node's online time.

[0042] An electronic letter of guarantee issuance system, comprising a letter of guarantee copy module, a node analysis module, and a response sending module;

[0043] Guarantee replication module: obtains the node information that receives the guarantee issuance request and marks the node as an RL node. After receiving the guarantee issuance request, the RL node uses the Paxos protocol to propose a new proposal. After the Paxos protocol votes in unanimity, the RL node replicates the guarantee issuance request to all its Follower nodes.

[0044] Node analysis module: before the letter of guarantee is issued, after obtaining the status of multiple Follower nodes, the operating status development trend of the Follower nodes is predicted. When it is predicted that any Follower node is running abnormally, a new RL node is automatically elected. The new RL node recovers from the previous log and resynchronizes the status of all nodes;

[0045] Response sending module: If the request for issuance of the letter of guarantee is replicated and confirmed in the corresponding number of nodes, the RL node sends a successful response to the client.

[0046] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0047] The present invention obtains the node information of the receiving letter of guarantee issuance request and marks the node as an RL node. After receiving the letter of guarantee issuance request, the RL node uses the Paxos protocol to propose a new proposal. After the Paxos protocol votes in unanimity, the RL node copies the letter of guarantee issuance request to all its Follower nodes. Before the letter of guarantee is issued, after obtaining the status of multiple Follower nodes, the operating status development trend of the Follower nodes is predicted, and when it is predicted that any Follower node is abnormal, a new RL node is automatically elected. If the letter of guarantee issuance request is copied and confirmed in the corresponding number of nodes, the RL node sends a successful response to the client. The issuance system performs consistency verification, so that all nodes are always consistent in data records, avoiding the problem of asynchronous status between different nodes, and improving the system's recovery capability through the rollback mechanism. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0049] Figure 1 The present invention is a flow chart of the method. DETAILED DESCRIPTION

[0050] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0051] Example 1: Please refer to Figure 1 As shown, the electronic letter of guarantee issuance method described in this embodiment includes the following steps:

[0052] The issuance system obtains the node information of the letter of guarantee issuance request and marks the node as the RL (Raft-Leader) node. After receiving the letter of guarantee issuance request, the RL node uses the Paxos protocol to propose a new proposal to ensure that all participating nodes reach a consensus and believe that the request is valid and can be submitted. The letter of guarantee issuance request can continue to be executed. After the Paxos protocol votes in unanimous agreement, the RL node copies the letter of guarantee issuance request to all its Follower nodes to ensure that all nodes have consistent records. At this point, the data of all nodes is consistent, and the letter of guarantee issuance request has been formally submitted. Before the letter of guarantee is issued, obtain After checking the status of multiple Follower nodes, the operating status development trend of the Follower nodes is predicted, and when any Follower node is predicted to have an abnormality in operation, a new RL node is automatically elected. The new RL node will recover from the previous log and resynchronize the status of all nodes, including the submitted guarantee issuance request, to ensure that no matter what system failure occurs, the consistency of the guarantee issuance request by all nodes is maintained and the submitted data will not be lost. If the guarantee issuance request is replicated and confirmed in the corresponding number of nodes, the RL node sends a success response to the client (i.e. the enterprise), informing it that the electronic guarantee has been issued successfully.

[0053] This application obtains the node information of the receiving letter of guarantee issuance request and marks the node as an RL node. After receiving the letter of guarantee issuance request, the RL node uses the Paxos protocol to propose a new proposal. After the Paxos protocol votes in unanimity, the RL node copies the letter of guarantee issuance request to all its Follower nodes. Before the letter of guarantee is issued, after obtaining the status of multiple Follower nodes, the operating status development trend of the Follower nodes is predicted, and when any Follower node is predicted to have an abnormality in operation, a new RL node is automatically elected. If the letter of guarantee issuance request is copied and confirmed in the corresponding number of nodes, the RL node sends a successful response to the client. The issuance system performs consistency verification to ensure that all nodes are always consistent in data records, avoiding the problem of asynchronous status between different nodes, and improving the system's recovery capability through the rollback mechanism.

[0054] Embodiment 2: The issuance system obtains the node information of receiving the guarantee issuance request and marks the node as an RL (Raft-Leader) node, including the following steps:

[0055] Company A initiates a request for a letter of guarantee to the system, which includes necessary information, such as the amount of the letter of guarantee, contract number, guarantee terms, etc. The request passes through the system's entry point and first reaches any node in the cluster. The node that receives the request is marked as an RL node:

[0056] After receiving the request for issuance of a letter of guarantee, the RL node starts to process the request. At this time, the Leader node needs to ensure the correctness and validity of the request. First, it verifies whether the content of the request complies with the rules, such as checking whether the contract number, guarantee amount, request format, etc. are legal.

[0057] After receiving the guarantee request, the RL node uses the Paxos protocol to propose a new proposal to ensure that all participating nodes reach a consensus that the request is valid and can be submitted. The guarantee request can continue to be executed, including the following steps:

[0058] The RL node prepares the request for the issuance of a letter of guarantee as a proposal for the Paxos protocol. The Paxos protocol uses proposals to ensure that nodes in a distributed system reach consensus. The detailed information of the request for the issuance of a letter of guarantee (such as the amount, contract number, guarantee terms, etc.) will be used as the proposed content of the Paxos proposal. The RL node generates a unique proposal number, which is used to identify the current proposal and ensure the consistency and order of proposals in the Paxos protocol. The RL node sends a Prepare message of the Paxos protocol to the Follower nodes (including the Follower nodes) in the cluster, requesting them to vote on the current proposal. The message contains the proposal number and requires all nodes to respond whether the current proposal can be accepted (that is, whether the current proposal is valid).

[0059] After receiving the Prepare message, each Follower node responds according to the rules of the Paxos protocol:

[0060] If the node has not accepted a proposal with a higher number, it will respond that it agrees to accept the current proposal. If the node has already accepted a proposal with a higher number, it will return a rejection message to the RL node and send the number of the proposal it accepted to the RL node. The RL node collects responses from all nodes to confirm whether enough nodes agree to accept the current proposal. Usually, when more than half of the nodes agree to the current proposal, the Paxos protocol considers that the current proposal has reached consensus.

[0061] When the RL node receives a response from the majority of nodes, it will send an Accept message to these nodes, requesting them to formally accept the current proposal. The Accept message contains the proposal number and the specific content of the request for the issuance of the letter of guarantee. Node confirmation proposal: After receiving the Accept message, each Follower node confirms and stores the current proposal, and marks the current proposal as accepted. At this point, the data status of all nodes is consistent, and the proposal takes effect.

[0062] When most nodes (including the Leader and at least one Follower) confirm and accept the current proposal, the RL node knows that the current proposal has been agreed upon in the system and can proceed with subsequent operations. The RL node copies the log entry of the guarantee request (i.e., the content of the guarantee request) to all Follower nodes in the cluster to ensure that each node holds a consistent record. The Leader node passes the log entry to the Follower node through the log replication mechanism of the Raft protocol. After the Follower node confirms that the log has been received and the synchronization is successful, it updates the local log.

[0063] After the Paxos protocol votes in unanimity, the RL node copies the guarantee request to all its Follower nodes to ensure that all nodes have consistent records. At this point, the data of all nodes is consistent, and the guarantee request has been formally submitted, including the following steps:

[0064] RL node proposes a proposal: When the RL node receives a request for a letter of guarantee, it proposes a new proposal through the Paxos protocol to ensure that all nodes in the system agree that the request is valid. The RL node assigns a unique proposal number to the proposal and attaches the content of the request for a letter of guarantee. The proposal number is assigned according to the rules of the Paxos protocol to ensure the uniqueness and order of the proposal. All participating nodes (including RL nodes and Follower nodes) vote based on the proposal number and content: the node checks whether the conditions of the proposal (such as the proposal number, log synchronization status, etc.) are met. The node votes to support or reject the current proposal. According to the Paxos protocol, a proposal can only be considered to be agreed upon when the majority of nodes (more than half) agree to the proposal. When more than half of the nodes agree to the proposal, the Paxos protocol reaches a consensus through voting, the proposal is approved, and the request for the letter of guarantee can continue to be executed.

[0065] After the Paxos protocol is agreed upon, the RL node will formally submit a proposal for the letter of guarantee issuance request and copy the proposal as a log entry to all Follower nodes. The replication process includes:

[0066] The RL node writes the request for issuance of a letter of guarantee (i.e., the content of the proposal) as a log entry into its local log. The RL node copies the log entry to the log of each Follower node. After receiving the log entry, the Follower node checks the integrity and consistency of the entry to ensure that the log entry is not lost or damaged. If the log entry meets the requirements, the Follower node adds it to its own local log. After the Follower node successfully receives and writes the log entry, it sends a confirmation message to the RL node. The RL node will only proceed with subsequent operations when the majority of Follower nodes confirm that the log entry has been successfully written. Once the majority of Follower nodes confirm the log entry, the RL node can assume that the logs of all nodes have been synchronized and the request for issuance of a letter of guarantee has been recorded in the system.

[0067] Through the Paxos protocol, the logs of all nodes are consistent, ensuring that all nodes in the system have the same guarantee request data. This means that the data status of all nodes (including RL nodes and Follower nodes) is consistent, and there will be no data loss or inconsistency. If the system fails or the network is partitioned, other nodes will recover to a consistent state based on the logs to ensure that the guarantee request is not lost. The guarantee request has been replicated and confirmed in most nodes, ensuring data consistency. At this time, the RL node will send a success response to the client (i.e., Enterprise A), informing it that the electronic guarantee has been successfully issued.

[0068] Before issuing a letter of guarantee, after obtaining the status of multiple Follower nodes, the operating status development trend of the Follower nodes is predicted, including the following steps:

[0069] Before the letter of guarantee is issued, the status data of multiple Follower nodes are obtained, including the operation queue index, log synchronization factor, and health index. After normalizing the operation queue index, log synchronization factor, and health index, the status coefficient is obtained by comprehensive calculation. The expression is:

[0070] Fzt = α·δ+β·θ-γ·ε, where Fzt is the state coefficient, δ is the health index, θ is the log synchronization factor, ε is the operation queue index, α, β, γ are adjustment coefficients, and α, β, γ are all greater than 0;

[0071] The smaller the state coefficient, the worse the future operation state of the Follower node will be. The obtained state coefficient is compared with the preset coefficient threshold. The coefficient threshold is used to predict whether there is an abnormality in the operation of the Follower node. If the state coefficient is greater than or equal to the coefficient threshold, it is predicted that there is no abnormality in the operation of the Follower node. If the state coefficient is less than the coefficient threshold, it is predicted that there is an abnormality in the operation of the Follower node.

[0072] The calculation expression of the operation queue index is: In the formula, T is the monitoring duration, Queue Length(t) is the length of the operation queue at time t, λ is the attenuation coefficient, which reflects that the influence of the queue length gradually weakens over time, Task Processing Rate(t) is the rate at which the node processes tasks, and the operation queue index reflects the pressure of the node when processing tasks. If the operation queue index is large, it may mean that the node is experiencing overload and fails to process requests in time.

[0073] The calculation expression of the log synchronization factor is:

[0074] Where MaxSync Lag is the maximum synchronization delay, which indicates the maximum log synchronization gap between the current node and all other nodes. LogSync Failures is the node log synchronization failure rate. LogMatchingRatio is the log matching ratio, which indicates the matching degree between the log of the current node and the log of other nodes (between 0 and 1, 1 indicates a perfect match). Sync Load Factor is the synchronization load factor, which indicates the burden of the current node in processing synchronization tasks. It is usually determined by the node load and the network load. The log synchronization factor reflects the consistency of the node's synchronization with other nodes. A smaller log synchronization factor reflects a higher synchronization delay, more frequent synchronization failures, and a higher synchronization load. All of the above performances will lead to a deterioration of the synchronization status of the node.

[0075] The calculation expression of health index is: Where Available Resources is the current remaining percentage of the node's CPU, Total Resources is the total resources of the node, Uptime Factor is the normalized value of the node's online time, and the health index comprehensively calculates the node's health status. The smaller the health index, the higher the error rate and delay, and the worse the node's health status. The larger the health index, the greater the remaining percentage of the CPU, that is, the more remaining computing resources, the better the health status, and the longer the node's online time (Uptime-Factor) also helps reflect the stability of the node.

[0076] When it is predicted that any Follower node is running abnormally, a new RL node will be automatically elected. The new RL node will recover from the previous log and resynchronize the status of all nodes, including the submitted guarantee issuance request, to ensure that no matter what system failure occurs, the consistency of the guarantee issuance request of all nodes is maintained and the submitted data will not be lost, including the following steps:

[0077] When a Follower node is detected to be operating abnormally, the automatic fault warning mechanism is triggered. By analyzing the monitoring data, the system will determine whether an RT node election is needed;

[0078] If the RL node is normal, continue to maintain the existing RL node. If the RL node is abnormal, trigger the Leader election;

[0079] Any follower node can initiate an election request and try to become a new RL node. When a follower node initiates an election, it obtains the state coefficient and voting normalization value of the follower node, and weights the state coefficient and voting normalization value to obtain the follower node preference index, which is expressed as: yxsz = 0.7*Fzt + 0.3*tps, where yxsz is the preference index, Fzt is the state coefficient, and tps is the voting normalization value;

[0080] The calculation logic of the voting election normalization value is as follows: obtain the number of votes for the current Follower node by other Follower nodes, normalize the number of votes for the current Follower node by other Follower nodes, and then obtain the voting election normalization value.

[0081] After obtaining the preference indexes of all Follower nodes, all Follower nodes are sorted from large to small according to the preference indexes to generate a sorting table, and the Follower node ranked first in the sorting table is selected as the new RL node.

[0082] The newly elected RL node will obtain the latest log entries from other nodes (especially the healthier nodes) to ensure that it has complete log records. If the log of the new RL node lags behind other nodes, it will request other nodes to push the missing log entries to it. The new RL node will update itself to the latest log status to ensure consistency with other nodes.

[0083] If the guarantee request is replicated and confirmed in the corresponding number of nodes, the RL node sends a success response to the client (i.e., the enterprise), informing it that the electronic guarantee has been successfully issued, including the following steps:

[0084] The new RL node will copy the recovered log entries to all Follower nodes to ensure that all nodes have the same log records. Each Follower node will update the local log and confirm the received log entries according to the log synchronization status of the new RL node. Each Follower node will send a confirmation message to the new RL node after successfully receiving and writing the log entry. The new RL node will wait for confirmation from the majority of Follower nodes to ensure the correctness of log synchronization.

[0085] When copying and synchronizing logs, the new RL node will compare the log entry number, proposal content and other information to ensure the consistency of all nodes. If there are unsynchronized or lost log entries, the RL node will request synchronization again until all nodes confirm that the synchronization is successful. The request for the issuance of a letter of guarantee has been recorded as a log entry in the log, and the new RL node will restore the submitted request for the issuance of a letter of guarantee from its log. The new RL node will check the status of the request to ensure that the request has been agreed upon and submitted successfully.

[0086] If the new RL node finds that the letter of guarantee issuance request has not been successfully submitted or is not fully synchronized, it will re-execute the letter of guarantee issuance request: the RL node will recheck the validity of the request and ensure that all participating nodes can process the request correctly. When resubmitting the letter of guarantee issuance request, the RL node will send a new synchronization request to all nodes to ensure that each node is synchronized to the correct state. Once the majority of Follower nodes confirm that the latest letter of guarantee issuance request log entry has been synchronized, the RL node will send a confirmation response to the client (such as Company A) to inform that the electronic letter of guarantee has been successfully issued.

[0087] Through the leader election and log synchronization mechanism of the Raft protocol, the system ensures that data consistency of all nodes is maintained regardless of system failures. All nodes can be restored to a consistent state and successfully execute the guarantee issuance request. Through log replication and leader election mechanisms, the system can automatically recover when a node fails, avoiding data loss or inconsistency caused by a single point of failure in the system. Even in the event of a node failure or network partition, the system can ensure that data will not be lost through the mechanisms of the Paxos protocol and the Raft protocol. All submitted guarantee issuance requests will be fully restored to ensure the high reliability of the system.

[0088] Embodiment 3: After receiving the request for issuance of a letter of guarantee, the RL node uses the Paxos protocol to propose a new proposal, which also includes the following steps:

[0089] The RL node uses the guarantee request as a proposal for the Paxos protocol, and the guarantee request information is used as the proposed content of the Paxos proposal.

[0090] The RL node generates a unique proposal number, which is used to identify the current proposal. The RL node sends a Prepare message of the Paxos protocol to the Follower node in the cluster. The Prepare message contains the proposal number, requests other nodes to vote on the current proposal, and requires all nodes to respond whether to accept the current proposal.

[0091] After receiving the Prepare message, each Follower node responds according to the rules of the Paxos protocol.

[0093] Embodiment 4: The electronic letter of guarantee issuance system described in this embodiment includes a letter of guarantee copying module, a node analysis module, and a response sending module;

[0094] Guarantee replication module: obtains the node information that receives the guarantee issuance request and marks the node as an RL node. After receiving the guarantee issuance request, the RL node uses the Paxos protocol to propose a new proposal. After the Paxos protocol votes in unanimity, the RL node replicates the guarantee issuance request to all its Follower nodes, and sends the replication result to the node analysis module;

[0095] Node analysis module: before issuing a letter of guarantee, after obtaining the status of multiple Follower nodes, predict the development trend of the operation status of the Follower nodes, and automatically elect a new RL node when it is predicted that any Follower node is running abnormally. The new RL node will recover from the previous log and resynchronize the status of all nodes, including the submitted letter of guarantee issuance request. The status of all nodes is sent to the response sending module;

[0096] Response sending module: If the request for issuance of a letter of guarantee is replicated and confirmed in the corresponding number of nodes, the RL node sends a successful response to the client (i.e., the enterprise).

[0097] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters in the formula are set by technicians in this field according to actual conditions.

[0098] In the description of this specification, the description with reference to the terms "one embodiment", "example", "specific example", etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0099] The preferred embodiments of the present invention disclosed above are only used to help explain the present invention. The preferred embodiments do not describe all the details in detail, nor do they limit the invention to only specific implementation methods. Obviously, many modifications and changes can be made according to the content of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the present invention, so that those skilled in the art can understand and use the present invention well. The present invention is limited only by the claims and their full scope and equivalents.

Claims

1. A method for issuing an electronic letter of guarantee, characterized by: The method for issuing the certificate comprises the following steps: The issuance system obtains the node information that receives the guarantee issuance request and marks the node as an RL node. After receiving the guarantee issuance request, the RL node uses the Paxos protocol to propose a new proposal. After the Paxos protocol votes in unanimity, the RL node copies the guarantee issuance request to all its Follower nodes. Before the letter of guarantee is issued, after obtaining the status of multiple Follower nodes, the operating status development trend of the Follower nodes is predicted, and when any Follower node is predicted to be abnormal, a new RL node is automatically elected; The new RL node recovers from the previous log and resynchronizes the status of all nodes. If the request for issuance of the letter of guarantee is replicated and confirmed in the corresponding number of nodes, the RL node sends a success response to the client.

2. The method for issuing an electronic letter of guarantee according to claim 1, characterized in that: After receiving the request for issuance of a letter of guarantee, the RL node uses the Paxos protocol to propose a new proposal, which includes the following steps: The RL node uses the guarantee request as a proposal for the Paxos protocol, and the guarantee request information is used as the proposed content of the Paxos proposal. The RL node generates a unique proposal number, which is used to identify the current proposal. The RL node sends a Prepare message of the Paxos protocol to the Follower node in the cluster. The Prepare message contains the proposal number, requests other nodes to vote on the current proposal, and requires all nodes to respond whether to accept the current proposal. After receiving the Prepare message, each Follower node responds according to the rules of the Paxos protocol: If all proposal numbers in the node are less than or equal to the current proposal number, the node responds that it agrees to accept the current proposal. If any proposal number in the node is greater than the current proposal number, the node returns a rejection message to the RL node and sends the proposal number with a number greater than the current proposal number to the RL node. The RL node collects responses from all nodes. If the number of nodes that agree to accept the current proposal is greater than or equal to the threshold, the Paxos protocol considers that the current proposal has reached consensus. When the Paxos protocol believes that the current proposal has reached a consensus, the RL node sends an Accept message to the Follower node, requesting to accept the current proposal. The Accept message contains the proposal number and the request for the issuance of a letter of guarantee. After receiving the Accept message, each Follower node confirms and stores the current proposal and marks the current proposal as accepted. After the Follower node confirms that the log has been received and the synchronization is successful, it updates the local log.

3. The method for issuing an electronic letter of guarantee according to claim 2, characterized in that: Before issuing a letter of guarantee, after obtaining the status of multiple Follower nodes, the operating status development trend of the Follower nodes is predicted, including the following steps: Before issuing the letter of guarantee, obtain the status data of multiple Follower nodes, including the operation queue index, log synchronization factor, and health index. After normalizing the operation queue index, log synchronization factor, and health index, comprehensively calculate and obtain the status coefficient. The obtained state coefficient is compared with the preset coefficient threshold. The coefficient threshold is used to predict whether there is any abnormality in the operation of the Follower node. If the state coefficient is greater than or equal to the coefficient threshold, it is predicted that there is no abnormality in the operation of the Follower node. If the state coefficient is less than the coefficient threshold, it is predicted that there is an abnormality in the operation of the Follower node.

4. The method for issuing an electronic letter of guarantee according to claim 3, characterized in that: When any Follower node is predicted to be running abnormally, a new RL node election is automatically performed, including the following steps: When a Follower node is detected to be operating abnormally, the automatic fault warning mechanism is triggered. By analyzing the monitoring data, the system will determine whether an RT node election is needed; If the RL node is normal, continue to maintain the existing RL node. If the RL node is abnormal, trigger the Leader election; When the Follower node initiates an election, it obtains the state coefficient and voting normalization value of the Follower node, and weights the state coefficient and voting normalization value to obtain the Follower node preference index, which is expressed as: yxsz = 0.7*Fzt + 0.3*tps, where yxsz is the preference index, Fzt is the state coefficient, and tps is the voting normalization value; After obtaining the preferred indexes of all Follower nodes, all Follower nodes are sorted from large to small according to the preferred indexes, a sorting table is generated, and the Follower node ranked first in the sorting table is selected as the new RL node.

5. The method for issuing an electronic letter of guarantee according to claim 4, characterized in that: If the letter of guarantee issuance request is replicated and confirmed in the corresponding number of nodes, the RL node sends a success response to the client, including the following steps: The new RL node copies the recovered log entries to all Follower nodes. Each Follower node updates the local log and confirms the received log entries according to the log synchronization status of the new RL node. When the new RL node copies and synchronizes the log, it compares the log entry number and proposal content information. If there are unsynchronized or lost log entries, the RL node requests synchronization again until all nodes are synchronized successfully; If the new RL node finds that the request for issuance of a letter of guarantee has not been successfully submitted or is not fully synchronized, it will re-execute the request for issuance of a letter of guarantee. When resubmitting the request for issuance of a letter of guarantee, the RL node sends a new synchronization request to all nodes. If there are a corresponding number of Follower nodes confirming that the latest log entry for the request for issuance of a letter of guarantee has been synchronized, the RL node sends a confirmation response to the client, informing it that the electronic letter of guarantee has been issued.

6. The method for issuing an electronic letter of guarantee according to claim 5, characterized in that: The RL node copies the letter of guarantee issuance request to all its Follower nodes, including the following steps: After the Paxos protocol reaches consensus, the RL node will submit a proposal for the letter of guarantee issuance request and copy the proposal as a log entry to all Follower nodes. The replication process includes: The RL node writes the letter of guarantee issuance request as a log entry in its local log, and the RL node copies the log entry to the log of each Follower node; After receiving the log entry, the Follower node checks the integrity and consistency of the entry. If the log entry meets the requirements, the Follower node adds it to its own local log. After the Follower node receives and writes the log entry, it sends a confirmation message to the RL node.

7. The method for issuing an electronic letter of guarantee according to claim 6, characterized in that: The calculation expression of the operation queue index is: Where T is the monitoring duration, Queue Length(t) is the length of the operation queue at time t, λ is the decay coefficient, and Task Processing Rate(t) is the rate at which the node processes tasks at time t. The calculation expression of the log synchronization factor is: Where Max SyncLag is the maximum synchronization delay, Log Sync Failures is the node log synchronization failure rate, Log Matching Ratio is the log matching ratio, and Sync Load Factor is the synchronization load factor; The calculation expression of the health index is: Where Available Resources is the remaining percentage of the node's current CPU, Total Resources is the total resources of the node, and Uptime Factor is the normalized value of the node's online time.

8. An electronic letter of guarantee issuance system, used to implement the issuance method according to any one of claims 1 to 7, characterized in that: It includes letter of guarantee copy module, node analysis module and response sending module; Guarantee replication module: obtains the node information that receives the guarantee issuance request and marks the node as an RL node. After receiving the guarantee issuance request, the RL node uses the Paxos protocol to propose a new proposal. After the Paxos protocol votes in unanimity, the RL node replicates the guarantee issuance request to all its Follower nodes. Node analysis module: before the letter of guarantee is issued, after obtaining the status of multiple Follower nodes, the operating status development trend of the Follower nodes is predicted. When it is predicted that any Follower node is running abnormally, a new RL node is automatically elected. The new RL node recovers from the previous log and resynchronizes the status of all nodes; Response sending module: If the request for issuance of the letter of guarantee is replicated and confirmed in the corresponding number of nodes, the RL node sends a successful response to the client.

Images