Cross-platform intelligent project dynamic information real-time synchronization method and device

Abstract

The invention discloses a cross-platform intelligent project dynamic information real-time synchronization method and device, and relates to the technical field of information synchronization. Comprising the following steps: S1, obtaining a latest update request through communication connection with each platform, performing sensitive analysis on the update request, and performing different security verification strategies on the update request according to a sensitive analysis result; s2, comprehensively analyzing each service node to select an optimal service node to serve the update request, and executing a fusing strategy when an exception exists in the service process; and S3, encrypting and storing the update request to the block chain by the control service node, and executing different encryption modes for the update requests of different sensitive types at the same time. According to the method, the problem of performance bottleneck and expansion of a traditional synchronization architecture when the number of users and the data volume are increased exponentially is effectively solved, and meanwhile, through multi-level security protection, the security risk in the data transmission process is remarkably reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of information synchronization, and specifically to a method and device for real-time synchronization of cross-platform intelligent project dynamic information. Background Art

[0002] Information synchronization refers to the process of ensuring data consistency among multiple systems, platforms, or devices. When data in a certain system changes, this change can be updated in other systems to ensure that all nodes have the same information. This mechanism covers all aspects such as data collection, transmission, processing, and storage to ensure the real-time and consistency of information;

[0003] With the exponential growth of the number of users and data volume, traditional synchronization architectures will face performance bottlenecks and expansion difficulties, especially in complex distributed environments; at the same time, during the process of cross-platform data transmission, it is prone to risks of man-in-the-middle attacks, data leakage, or tampering, especially when sensitive data is involved. Summary of the Invention

[0004] Aiming at the deficiencies of the prior art, the present invention provides a method and device for real-time synchronization of cross-platform intelligent project dynamic information, which solves the problems raised in the above background art.

[0005] To achieve the above objectives, the present invention is realized through the following technical solutions: A method for real-time synchronization of cross-platform intelligent project dynamic information, including:

[0006] S1: Obtain the latest update requests by communicating with each platform. The update requests include the requesting platform, request time, and request content. Perform sensitive parsing on the update requests to evaluate the sensitivity level of the update requests, and accordingly adopt different security verification strategies for the update requests;

[0007] S2: Set a number of service nodes, and select the optimal service node to allocate the update requests; when an exception occurs during the execution of the service node, the circuit breaker strategy is executed; the specific implementation steps of the circuit breaker strategy are:

[0008] Real-time update the total number of requests and the number of failed requests of each service node within each time window, and divide the number of failed requests by the total number of requests and multiply by 100% to obtain the error rate. If the number of consecutive failures within the time window ≥ n times, where n is a positive integer, then execute the fast-failure type circuit breaker; otherwise, calculate the window error rate and execute the circuit breaker based on the error rate

[0009] Preset an error rate one. If the error rate is greater than or equal to the preset error rate one, then execute the high-error-rate circuit breaker,

[0010] If the error rate is less than the error rate one, then there is no need to execute the circuit breaker;

[0011] S3: The service node encrypts and stores the update request in the blockchain;

[0012] S4: Perform cross-platform synchronization and coordination based on the new block.

[0013] Furthermore, the quick-fail fuse and the high-error-rate fuse are respectively:

[0014] Quick-fail fuse: Activate the quick-fail fuse, with a fuse time of T1. After T1 time, 10% of the update requests are allowed to pass for probe requests. If any subsequent request is successful, the probe is successful, and the counter is restored and reset. If the probe is not successful, the fuse time is extended.

[0015] High-error-rate fuse: Activate the high-error-rate fuse and enter the cooling state, that is, all requests directly return failure. Start the cooling timer and maintain the cooling duration T2. After the cooling duration ends, enter the half-open state and allow 10% of the update requests to pass. When the success rate reaches 90%, the high-error-rate fuse is closed; each time the probe fails, the post-fuse cooling duration increases.

[0016] Furthermore, for the sensitive parsing of the update request:

[0017] It is set that there is a sensitive word library, where the sensitive words are set by those skilled in the art according to the actual requirements of each platform. Each sensitive word in the sensitive word library corresponds to a sensitive value. Use NLP technology to perform in-depth semantic analysis on the request content to obtain the sensitive words involved in the update request content, the number of times each sensitive word appears, and its corresponding sensitive value. Multiply the number of times each sensitive word appears by its corresponding sensitive value to obtain the cumulative sensitive value corresponding to the sensitive word, and sum up the sensitive cumulative words of each sensitive word to obtain the total sensitive value of the update request. If the total sensitive value is greater than the upper limit of the set sensitive interval, then mark this update request as a highly sensitive request; if the total sensitive value is within the set sensitive interval, then mark this update request as a moderately sensitive request; if the total sensitive value is less than the lower limit of the set sensitive interval, then mark this update request as a mildly sensitive request;

[0018] If the update request is a mildly sensitive request, it can be directly processed, and then execute S2;

[0019] If the update request is a moderately sensitive request, then further confirm the legitimacy of the request source through device fingerprint binding until it passes the verification, and then execute S2;

[0020] If the update request is a highly sensitive request, then trigger two-factor authentication until it passes the verification, and then execute S2.

[0021] Furthermore, allocate the update request:

[0022] Step 1: Sort the update requests in descending order according to their corresponding total sensitivity values to obtain an update request task schedule, and select the update request with the largest total sensitivity value as the target request;

[0023] Step 2: Collect metrics for each service node to obtain node information. The specific node information includes IP address, heartbeat packet, concurrent connection count, network latency, packet loss rate, CPU utilization, memory occupancy, and request queue length; Set a time window and check the heartbeat packets within the most recent time window up to the current time. If there is a missing heartbeat packet, mark the service node as an unavailable node. If there is no missing heartbeat packet, mark the service node as an available service node; Integrate all available service nodes to form a preliminary service node list;

[0024] Step 3: Perform a comprehensive analysis on each service node in the preliminary service node list based on the node information to generate a service value; Sort the service nodes in the preliminary service node list in descending order according to their corresponding service values, select the one with the largest service value as the final selected service node, and send the target request to the final selected service node. At the same time, increment the request queue length of the final selected service node by one;

[0025] Step 4: Update the preliminary service node list and the node information of each service node in it in real time, and repeat Steps 1 to 3 until all update requests are allocated; Each service node processes the update requests in its request queue according to the request time of each update request.

[0026] Further, the analysis process of the service value:

[0027] Obtain the IP address from which the update request is initiated, calculate the geographical distance between it and the IP addresses of each service node in the preliminary service node list to obtain the geographical distance, and mark it as P; Normalize the geographical distance to obtain the regional affinity value. The specific processing formula is: max(P) The maximum geographical distance allowed for this service node in this application scenario;

[0028] Record the concurrent connection count, network latency, packet loss rate, CPU utilization, memory occupancy, and request queue length of each service node in the preliminary service node list as L 并发 、L 延迟 、L 丢包率 、L CPU 、L 内存占用 、L 队列长度 , and normalize them, and then perform a weighted calculation to obtain the node performance value. The specific normalization formula is: where min(L 并发) is the minimum number of concurrent connections allowed for this service node in this application scenario, max(L 延迟 ) is the maximum network latency that this service node can tolerate in this application scenario, max(L 丢包率 ) is the maximum packet loss rate that this service node can tolerate in this application scenario, min(L CPU ) is the minimum CPU utilization rate allowed for this service node in this application scenario, max(L 内存占用 ) is the maximum memory occupancy allowed for this service node in this application scenario, max(L 队列长度 ) is the maximum internal queue length allowed for this service node in this application scenario;

[0029] The service value of the service node is obtained by weighted calculation of the node performance value and the regional affinity value.

[0030] Furthermore, the service node encrypts and stores the update request in the blockchain:

[0031] Step 1: Extract the update request and its request sensitive type. For low-sensitivity requests, no encryption is required. The service node waits for the blockchain network to perform consensus confirmation on the update request until the request is officially written into the blockchain. Once the confirmation is successful, a unique transaction identifier and timestamp are returned as the voucher for the data to be uploaded to the chain. If it is a medium-sensitivity request, then execute Step 2. If it is a high-sensitivity request, then execute Step 3;

[0032] Step 2: Divide the update request according to the block size of AES. Pad the data block that is less than 16 bytes to meet the requirements of block encryption. Randomly generate an initialization vector denoted as IV. For the first data block, perform XOR operation with IV and then use AES encryption to obtain the ciphertext block. For each subsequent data block, perform XOR operation with the previous ciphertext block and then use AES encryption to obtain the ciphertext block. After the encryption is complete, combine all the ciphertext blocks into the final encrypted data;

[0033] Step 3: Convert the update request into a numerical sequence according to the character-numerical one-to-one mapping table. Identify the positions of zeros in the numerical sequence and mark them as zero positions, and then remove all zero positions to complete the zero-removal of the numerical sequence. Then, take every three adjacent numerical values in the numerical sequence as a set of three elements. Select the largest value in each set of three elements as the radius of the bottom circle, select the smallest value as the radius of the top circle, and the remaining value as the height to construct a frustum of a cone. Thus, each set of three elements corresponds to a frustum of a cone. Calculate the volume of the frustum of a cone, and sort the volumes according to the position order of each set of three elements in the original sequence to form a preliminary encrypted numerical sequence. Then, invert and convert the preliminary encrypted numerical sequence into a character sequence according to the character-numerical one-to-one mapping table, and then use the same encryption method as in Step 2 for the character sequence to obtain a secondary ciphertext sequence. Then, take the zero positions of each zero bit and the three elements of each volume as supplementary information, and integrate the secondary ciphertext and the supplementary information into the final encrypted data;

[0034] Step 4: After going through Step 1, Step 2 or Step 3, the service node obtains the final update request data, calculates the data digest using SHA-256 to generate a data fingerprint to ensure data integrity. At the same time, collect the metadata related to the update request, such as the request sensitive type, request time, service node identifier, and package it together with the final update request data into a standard transaction object; use the private key of the service node to digitally sign the transaction object to generate signature data; according to the blockchain protocol used, encode and format the transaction object to form the final transaction data packet; broadcast the constructed transaction data packet to the entire blockchain network through the blockchain interface or node network;

[0035] Step 5: After receiving the transaction, each node in the blockchain network verifies the transaction. After passing the verification, the transaction is added to the transaction pool to be packaged; according to the regulations of the blockchain consensus mechanism, the node selects several valid transactions from the transaction pool to be packaged to construct a candidate block. The candidate block is verified through the consensus algorithm in the network, and all nodes reach an agreement on the legality of the candidate block; once the consensus is reached, the candidate block is officially generated and added to the blockchain;

[0036] Step 6: When the transaction is successfully packaged into a block, the service node obtains relevant information from the blockchain. The relevant information includes the unique transaction identifier, block number and generation time, and other metadata related to the transaction; integrate the above information into a storage certificate.

[0037] Further, perform cross-platform synchronization and coordination based on the new block:

[0038] Step 1, Blockchain event listening:

[0039] Start the blockchain event listener to monitor the generation of new blocks and the update request transactions recorded in the blocks in real time;

[0040] Step 2, Data Parsing and Verification:

[0041] After extracting the monitored transaction data, parse the data and verify its digital signature, timestamp, and data digest;

[0042] Step 3, Sorting and Version Management:

[0043] Sort all captured update requests according to the timestamp in the blockchain and the preset version control rules;

[0044] Step 4, Synchronization Coordination and Data Distribution:

[0045] After determining the final update status and taking this status as the authoritative data, distribute the update notifications to each platform through a message queue or direct push; each receiving end updates the local cache, database, or other storage systems according to the received synchronization data.

[0046] Step 5, Conflict Resolution and Compensation Mechanism:

[0047] If conflicts are found between different update requests during sorting or version merging, call the conflict resolution strategy to automatically merge through predefined rules. At the same time, use smart contracts to record the conflict handling process.

[0048] Step 6, Confirmation Feedback and Audit Record:

[0049] After synchronization is completed, generate confirmation feedback, including the unique identifier of each transaction, synchronization time, and update status of each platform; regularly audit all synchronization operations.

[0050] In a second aspect, the present invention provides a cross-platform intelligent project dynamic information real-time synchronization device, including a request verification module, a service module, a block storage module, and a synchronization coordination module;

[0051] The request verification module communicates with each platform to obtain the latest update requests. The update requests include the requesting platform, request time, and request content. Perform sensitive parsing on the update requests to evaluate the sensitivity level of the update requests, and accordingly implement different security verification strategies for the update requests;

[0052] The service module selects the optimal service node to serve the update requests by comprehensively parsing each service node. When an exception occurs during the service process, execute the circuit breaker strategy;

[0053] The block storage module controls the service node to encrypt and store the update requests in the blockchain, and at the same time implements different encryption methods for different sensitive types of update requests;

[0054] The synchronization and coordination module performs cross-platform synchronization and coordination based on new blocks.

[0055] The present invention has the following beneficial effects:

[0056] 1. By communicating with each platform in real time, quickly receiving the latest update requests, and using a preset sensitive word library and sensitive values to perform in-depth NLP analysis on the request content. During the analysis process, not only individual sensitive words are detected, but also the operation intention is judged in combination with the context, the number of occurrences of each sensitive word and its corresponding sensitive cumulative value are calculated, and finally the sensitive total value of the update request is obtained. According to the comparison between the sensitive total value and the preset sensitive interval, the system classifies the update requests into three types: highly sensitive, moderately sensitive, and mildly sensitive; different security verification strategies are implemented based on the sensitivity classification, effectively preventing the risk of data leakage or tampering caused by incorrect authorization or malicious operations; through sensitive parsing and hierarchical processing, the data is classified and preprocessed in advance, avoiding the use of the same processing strategy for all requests, thereby reducing unnecessary encryption calculations and verification overhead of the system;

[0057] 2. By monitoring the real-time collection of key performance indicators, node heartbeats, and regional geographical locations of all service nodes, using normalization processing and weighted calculation to obtain the comprehensive performance value of each service node, and combining with the regional affinity value, constructing the "service value" of the service node; sorting the service nodes according to the service value, automatically selecting the optimal node, and allocating sensitive requests to nodes with fast response speed, low load, and close geographical distance to the request source, thereby improving the overall processing efficiency and user experience; real-time monitoring of the total number of requests and the number of failed requests of each node within a fixed time window, calculating the error rate, and setting the threshold of the continuous failure times and the error rate threshold. When the fast failure condition is reached, the fuse is immediately triggered to quickly isolate the faulty node and prevent the spread of the fault; when the error rate exceeds the high threshold, it enters the cooling state, adopts a semi-open state detection strategy, and adjusts the fuse cooling duration through exponential backoff, forming a hierarchical fuse strategy, which can not only respond quickly in case of sudden serious faults, but also isolate the problem node in time in case of gradual performance degradation, thus ensuring the stability and availability of the entire system in a high-concurrency environment; through intelligent scheduling and dynamic load balancing, it can effectively cope with the request pressure generated by the rapid increase of users and data volume, avoiding overloading of a single node; at the same time, the distributed service nodes work together to achieve horizontal expansion, break through the performance bottleneck of the traditional synchronization architecture, and realize flexible scheduling and load balancing of resources;

[0058] 3. By adopting different processing methods for data according to the sensitivity level of the update request, a hierarchical encryption mechanism is formed, which can ensure that data with different sensitivity levels is properly protected, effectively preventing man-in-the-middle attacks, data leakage and tampering. After encryption, the SHA-256 algorithm is used to calculate the data digest to generate a data fingerprint, and then the data and related metadata are packaged into a standard transaction object, which is digitally signed by the service node with a private key. After encoding and formatting, the transaction data is broadcast to the entire blockchain network through the blockchain interface, and is confirmed and packaged into a block by the network consensus mechanism, ensuring that the data cannot be tampered with once it is on the chain, and has the characteristics of public transparency and traceability. Based on the above method of combining hierarchical encryption and blockchain storage, the risk of data being stolen, tampered with or forged during cross-platform transmission is solved, and a solid defense line is built for the data security of the entire system.

[0059] 4. By starting the blockchain event listener, the generation of new blocks and the situation of transactions being added to the chain are monitored in real time, and events containing key information such as update request data, digital signatures, and timestamps are captured. The real-time monitoring mechanism ensures that all the latest update requests can be captured in the first time and enter the synchronization process, guaranteeing data timeliness. The preset version control rules are used to sort and manage the versions of all update requests, so as to determine the final state during multiple updates or concurrent operations, ensuring data consistency. The sorted and verified update data is used as the authoritative data, and is distributed to each platform through a message queue or direct push. After each platform receives the synchronized data, it updates the local cache, database or other storage systems, ensuring the data consistency of the entire cross-platform system and eliminating the data island problem caused by the distributed environment.

[0060] In summary, through distributed caching, efficient message queues and blockchain storage, the present invention can adapt to the increasing load, and ensure information security and cross-platform synchronization through blockchain technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention, and those of ordinary skill in the art can also obtain other drawings based on these drawings without creative efforts.

[0062] Figure 1 It is a block diagram of the method of the present invention;

[0063] Figure 2 It is a melting three-state conversion diagram of the present invention;

[0064] Figure 3 It is a system block diagram of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0065] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts belong to the scope of protection of the present invention.

[0066] Please refer to Figure 1 , the present invention provides a technical solution: a cross-platform intelligent project dynamic information real-time synchronization method, including the following steps:

[0067] S1: Obtain the latest update request by communicating with each platform. The update request includes the requesting platform, the request time, and the request content (the request content here is the content that needs to be updated and synchronized). Perform sensitive parsing on the update request to evaluate the sensitivity level of the update request. Specifically:

[0068] Set up a sensitive word library, where the sensitive words are set by those skilled in the art according to the actual requirements of each platform, such as "change permissions, delete, add, privacy information, etc.". Each sensitive word in the sensitive word library corresponds to a sensitive value. Use NLP technology to perform in-depth semantic analysis on the request content, not only detecting individual sensitive words, but also judging the operation intention according to the context, obtaining the sensitive words involved in the update request content, the number of times each sensitive word appears, and its corresponding sensitive value. Multiply the number of times each sensitive word appears by its corresponding sensitive value to obtain the sensitive cumulative value corresponding to the sensitive word, and sum up the sensitive cumulative words of each sensitive word to obtain the total sensitive value of the update request. When comparing the total sensitive value with the set sensitive interval, if the total sensitive value is greater than the upper limit of the set sensitive interval, then mark the update request as a highly sensitive request; if the total sensitive value is within the set sensitive interval, then mark the update request as a moderately sensitive request; if the total sensitive value is less than the lower limit of the set sensitive interval, then mark the update request as a mildly sensitive request;

[0069] If the update request is a mildly sensitive request, it means that this update request is an ordinary operation and can be directly processed, then execute S2;

[0070] If the update request is a moderately sensitive request, it means that there is a certain sensitive risk in this update request. Then further confirm the legitimacy of the request source through device fingerprint binding (collecting User-Agent, IP, and Canvas fingerprint hash) until it passes the verification, and then execute S2;

[0071] If the update request is a highly sensitive request, it means that the sensitivity level of this update request is relatively high and the risk is relatively large. Then trigger secondary authentication (such as biometric recognition or dynamic token verification) until it passes the verification, and then execute S2;

[0072] By communicating with each platform in real time, the latest update requests are quickly received, and the request content is deeply analyzed by NLP using a preset sensitive word library and sensitive values. During the analysis process, not only individual sensitive words are detected, but also the operation intention is judged in combination with the context, the number of occurrences of each sensitive word and its corresponding sensitive cumulative value are calculated, and finally the sensitive total value of the update request is obtained. According to the comparison between the sensitive total value and the preset sensitive interval, the system classifies the update requests into three types: highly sensitive, moderately sensitive, and slightly sensitive; different security verification strategies are implemented based on the sensitivity classification to effectively prevent the risk of data leakage or tampering caused by incorrect authorization or malicious operations; through sensitive parsing and classification processing, the data is classified and preprocessed in advance, avoiding the use of the same processing strategy for all requests, thereby reducing unnecessary encryption calculations and verification overhead of the system.

[0073] S2: Assume that there are several service nodes, send the request to the service nodes, and select the optimal service node; when an exception occurs, then perform a circuit breaker; the specific implementation methods of selection and circuit breaker are as follows:

[0074] Step 1: Sort the update requests in descending order according to their corresponding sensitive total values to obtain an update request task arrangement table, and select the update request with the largest sensitive total value as the target request;

[0075] Step 2: Collect indicators for each service node to obtain node information. The specific node information includes IP address, heartbeat packet, concurrent connection count (the concurrent connection count refers to the number of clients that establish and maintain connections with a service node at the same time), network latency, packet loss rate, CPU utilization, memory occupancy, and request queue length; set a time window (in this application scenario, the time window is set to 2 minutes), check the heartbeat packet within the most recent time window up to the current time. If there is a missing heartbeat packet, the service node is classified as an unavailable node. If there is no missing heartbeat packet, the service node is marked as an available service node; integrate all available service nodes to form a primary service node list;

[0076] Step 3: Obtain the IP address from which the update request is initiated, calculate the geographical distance between it and the IP addresses of the service nodes in the primary service node list to obtain the geographical distance, and mark it as P; normalize the geographical distance to obtain the regional affinity value. The specific processing formula is: max(P) is the maximum geographical distance allowed for this service node in this application scenario;

[0077] Let the concurrent connection count, network latency, packet loss rate, CPU utilization, memory occupancy, and request queue length of each service node in the primary service node list be denoted as L 并发 、L延迟 and L 丢包率 and L CPU and L 内存占用 and L 队列长度 , and perform normalization processing on it, and then perform weighted calculation to obtain the node performance value. The specific normalization formula is: where min(L 并发 ) is the minimum concurrent connection number allowed for this service node in this application scenario, max(L 延迟 ) is the maximum network latency that this service node can tolerate in this application scenario, max(L 丢包率 ) is the maximum packet loss rate that this service node can tolerate in this application scenario, min(L CPU ) is the minimum CPU utilization rate allowed for this service node in this application scenario, max(L 内存占用 ) is the maximum memory occupancy allowed for this service node in this application scenario, max(L 队列长度 ) is the maximum internal queue length allowed for this service node in this application scenario;

[0078] Step Four: Perform weighted calculation on the node performance value and the regional affinity value to obtain the service value of the service node. Sort the service nodes in the initial selection list of service nodes in descending order according to their corresponding service values, select the one with the largest service value as the final selected service node, and send the target request to the final selected service node. At the same time, the request queue length of the final selected service node is increased by one. It should be noted that weighted calculation assigns weights to different data and then sums them up. The weights are determined by technical personnel when using the subjective weighting method.

[0079] Step Five: Update the initial selection list of service nodes and the node information of each service node in real time, and repeat Step One to Step Four until all update requests are allocated; each service node processes the update requests in its request queue according to the request time of each update request.

[0080] Step 6: Continuously update the total number of requests and the number of failed requests of each service node within each time window (2 minutes). Divide the number of failed requests by the total number of requests and multiply by 100% to obtain the error rate. If the number of consecutive failures within the time window is ≥ n (n is a positive integer, and those skilled in the art set n to 5), then perform fast-fail circuit breaking. Without waiting for a complete statistical cycle, it can quickly block sudden severe failures and prevent the avalanche effect (such as complete service downtime). The circuit-breaking time is T1 (those skilled in the art set T1 to 30 seconds). After T1 time, 10% of the update requests are allowed to pass for probe requests. If the probe is successful (any subsequent request is successful), then recovery occurs and the counter is reset; otherwise, the circuit-breaking time is extended. If the number of consecutive failures within the time window is < n, then perform circuit breaking based on the error rate. The specific circuit-breaking method is as follows:

[0081] Presume there is an error rate one, and the error rate one > 0. If the error rate is greater than the preset error rate one (which those skilled in the art set to 30%), then perform high-error-rate circuit breaking, as Figure 2 shown. When high-error circuit breaking is initiated, it enters the cooling state, that is, all requests directly return failures (without calling the backend service), start the cooling timer, and maintain the cooling duration T2 (those skilled in the art set T2 to 10 seconds). After the cooling duration ends, it enters the half-open state, allowing 10% of the update requests to pass. When the success rate reaches 90%, then turn off the high-error-rate circuit breaking. The initial value of the cooling duration T2 is 10 seconds, and each time a probe fails and enters circuit breaking, the cooling duration increases (the maximum value of T2 after increase is 100 seconds). After a probe failure, it extends according to exponential backoff to prevent the avalanche effect;

[0082] If the error rate is less than the error rate one, then there is no need to perform circuit breaking;

[0083] It should be noted that fast-fail circuit breaking belongs to millisecond-level instant triggering and is usually used for sudden severe failures; high-error-rate circuit breaking belongs to minute-level triggering depending on the statistical cycle and is usually used for progressive performance degradation;

[0084] By monitoring the real-time collection of key performance indicators, node heartbeats, and regional geographical locations of all service nodes, using normalization processing and weighted calculation to obtain the comprehensive performance value of each service node, and combining with the regional affinity value, the "service value" of the service node is constructed; sorting the service nodes according to the service value, automatically selecting the optimal node, and allocating sensitive requests to nodes with fast response speed, low load, and close geographical distance to the request source, thereby improving the overall processing efficiency and user experience; real-time monitoring the total number of requests and the number of failed requests of each node within a fixed time window, calculating the error rate, and setting the threshold of the continuous failure times and the error rate threshold. When the fast failure condition is reached, the fuse is immediately triggered to quickly isolate the faulty node and prevent the spread of the fault; when the error rate exceeds the high threshold, it enters the cooling state, adopts the semi-open state detection strategy, and adjusts the fuse cooling duration through exponential backoff to form a hierarchical fuse strategy, which can not only respond quickly in case of sudden serious faults but also isolate the problem nodes in time in case of gradual performance degradation, thus ensuring the stability and availability of the entire system in a high-concurrency environment; through intelligent scheduling and dynamic load balancing, it can effectively cope with the request pressure generated by the surge in users and data volume and avoid overloading of a single node; at the same time, the distributed service nodes work together to achieve horizontal expansion, break through the performance bottleneck of the traditional synchronous architecture, and realize flexible scheduling and load balancing of resources.

[0085] S3: The service node encrypts and stores the update request in the blockchain. Specifically:

[0086] Step 1: Extract the update request and its request sensitive type (including highly sensitive requests, moderately sensitive requests, and mildly sensitive requests). For low-sensitive requests, no encryption is required. The service node waits for the blockchain network to conduct a consensus confirmation on the update request until the request is officially written into the blockchain; once the confirmation is successful, a unique transaction identifier (transaction ID) and timestamp are returned as the voucher for the data to be uploaded to the chain; if it is a moderately sensitive request, then execute Step 2; if it is a highly sensitive request, then execute Step 3;

[0087] Step 2: Divide the update request according to the block size of AES (128 bits), and pad the data block that is less than 16 bytes to meet the requirements of block encryption; randomly generate an initialization vector denoted as IV. For the first data block, after alienating it with the IV, it is encrypted using AES to obtain a ciphertext block. For each subsequent data block, it is alienated with the previous ciphertext block and then encrypted using AES to obtain a ciphertext block. After the encryption is complete, all ciphertext blocks are combined into the final encrypted data;

[0088] Step 3: Convert the update request into a numerical sequence according to the character-numerical one-to-one mapping table. Identify the positions of zeros in the numerical sequence and mark them as zero positions, and then remove all zero positions to complete the zero-removal of the numerical sequence. Then, take every three adjacent numerical values in the numerical sequence as a set of three elements. Select the largest numerical value in each set of three elements as the radius of the bottom circle, select the smallest numerical value as the radius of the top circle, and use the remaining numerical value as the height to construct a frustum of a cone. Thus, each set of three elements corresponds to a frustum of a cone. Calculate the volume of the frustum of a cone, and sort the volumes according to the position order of each set of three elements in the original sequence to form a preliminary encrypted numerical sequence. Then, invert and convert the preliminary encrypted numerical sequence into a character sequence according to the character-numerical one-to-one mapping table, and then use the same encryption method as in Step 2 to obtain a secondary ciphertext sequence for the character sequence. Then, use the zero positions of each zero bit and the three elements of each volume as supplementary information, and integrate the secondary ciphertext and the supplementary information into the final encrypted data;

[0089] Step 4: After Step 1, Step 2 or Step 3, the service node obtains the final update request data (the data here includes the original data of the low-sensitivity request and the encrypted data of the medium or high-sensitivity request). Use SHA-256 to calculate the data digest to generate a data fingerprint to ensure data integrity. At the same time, collect the metadata related to the update request, such as the request sensitivity type, request time, and service node identifier, and package them into a standard transaction object together with the final update request data; use the private key of the service node to digitally sign the transaction object to generate signature data to ensure the authenticity and anti-tampering of the transaction; according to the blockchain protocol used, encode and format the transaction object (including the signature) to form the final transaction data packet; broadcast the constructed transaction data packet to the entire blockchain network through the blockchain interface or node network, and monitor the propagation status of the transaction. In case of network anomalies, retransmission or other fault tolerance processing can be performed;

[0090] Step 5: After receiving the transaction, each node in the blockchain network will verify the transaction, check whether the digital signature, data format, and data digest are correct. After passing the verification, the transaction is added to the transaction pool to be packaged (mempool); according to the regulations of the blockchain consensus mechanism, the node selects several valid transactions from the transaction pool to be packaged to construct a candidate block. The candidate block contains all the transaction data and its related metadata that meet the rules within the current time window; the candidate block is verified through the consensus algorithm in the network, and all nodes reach an agreement on the legality of the candidate block; once the consensus is reached, the candidate block is officially generated and added to the blockchain. From then on, the transaction data in this block cannot be tampered with; the generated block and all the transaction data it contains are permanently recorded on the blockchain, forming an irreversible record chain; the block will contain the block number, generation time, transaction list, and other necessary information for subsequent verification and query;

[0091] Step 6: Once the transaction is successfully packed into a block, the service node retrieves relevant information from the blockchain. The relevant information includes the unique transaction identifier (transaction ID), block number, generation time, and other transaction-related metadata (such as sensitivity level, service node information, etc.); integrate the above information into a storage certificate or proof document, which can prove that the update request has been successfully written into the blockchain and has the characteristics of immutability and traceability; it should be noted that the storage certificate can be either a digital format record or returned to the upper-layer application through an interface as a transaction confirmation certificate; the service node returns the storage certificate to the requester to ensure that it can obtain the confirmation information of the update request being written onto the blockchain; at the same time, a detailed log of the entire process of writing onto the blockchain is recorded for subsequent auditing, troubleshooting, and security monitoring;

[0092] According to the sensitivity level of the update request, different processing is applied to the data to form a hierarchical encryption mechanism, which can ensure that data of different sensitivity levels are properly protected, effectively preventing man-in-the-middle attacks, data leakage, and tampering; after encryption, the SHA-256 algorithm is used to calculate the data digest to generate a data fingerprint, and then the data and relevant metadata are packaged into a standard transaction object, and the service node digitally signs it with a private key; after encoding and formatting, the transaction data is broadcast to the entire blockchain network through the blockchain interface and is confirmed and packed into a block by the network consensus mechanism to ensure that the data is immutable once written onto the blockchain, with public transparency and traceability; based on the above method of combining hierarchical encryption and blockchain storage, the risk of data being easily stolen, tampered with, or forged during cross-platform transmission is solved, and a solid defense line is built for the data security of the entire system.

[0093] S4: Perform cross-platform synchronization and coordination based on the new block, specifically:

[0094] Step 1, blockchain event listening:

[0095] Start the blockchain event listener to monitor the generation of new blocks and the update request transactions recorded in the blocks in real time; when a new transaction is written into the blockchain, the listener will capture events containing key information such as update request data, digital signature, timestamp, etc.;

[0096] Step 2, data parsing and verification:

[0097] After extracting the monitored transaction data, parse the data and verify its digital signature, timestamp, and data digest to ensure the integrity and legality of the information; this step ensures that each update request obtained from the blockchain is legitimate data that has been encrypted and verified, preventing malicious tampering of the data;

[0098] Step 3, sorting and version management:

[0099] Sort all captured update requests according to the timestamps in the blockchain and preset version control rules (such as "last write wins" or CRDT-based merge strategies). In this way, it is possible to determine which update should be the final state in case of multiple updates or concurrent operations, thus achieving version consistency.

[0100] Step 4, Synchronization Coordination and Data Distribution:

[0101] After determining the final update status and taking this status as the authoritative data, distribute the update notifications to each platform via a message queue or direct push; each receiving end updates the local cache, database, or other storage systems according to the received synchronization data to ensure that the data of all platforms is consistent with the blockchain records.

[0102] Step 5, Conflict Resolution and Compensation Mechanism:

[0103] If conflicts are found between different update requests during sorting or version merging, call the conflict resolution strategy to automatically merge through predefined rules. At the same time, use smart contracts to record the conflict handling process to ensure that the data change history can be audited and traced later, achieving eventual consistency.

[0104] Step 6, Confirmation Feedback and Audit Record:

[0105] After synchronization is completed, generate confirmation feedback, including the unique identifier of each transaction, synchronization time, and update status of each platform; regularly audit all synchronization operations, and use the immutable feature of the blockchain to ensure that the entire process of data update is traceable, facilitating security monitoring and problem troubleshooting;

[0106] By starting a blockchain event listener, monitor the generation of new blocks and the situation of transactions being added to the blockchain in real time, capture events containing key information such as update request data, digital signatures, timestamps, etc. The real-time listening mechanism ensures that all the latest update requests can be captured and enter the synchronization process in the first time, guaranteeing data timeliness; use the preset version control rules to sort and manage all update requests, so as to determine the final state in case of multiple updates or concurrent operations, ensuring data consistency; take the sorted and verified update data as the authoritative data, and distribute it to each platform via a message queue or direct push. After each platform receives the synchronization data, it updates the local cache, database, or other storage systems to ensure the data consistency of the entire cross-platform system and eliminate the data island problem caused by the distributed environment.

[0107] As Figure 3 shown, a cross-platform intelligent project dynamic information real-time synchronization device includes a request verification module, a service module, a block storage module, and a synchronization coordination module;

[0108] The request verification module communicates with each platform to obtain the latest update requests. The update requests include the requesting platform, the request time, and the request content (the request content here is the content that needs to be updated and synchronized). It performs sensitive parsing on the update requests to evaluate the sensitivity level of the update requests and accordingly adopts different security verification strategies for the update requests;

[0109] The service module selects the optimal service node to serve the update requests by comprehensively analyzing each service node. When an exception occurs during the service process, the circuit breaker strategy is executed;

[0110] The block storage module controls the service node to encrypt and store the update requests in the blockchain, and at the same time executes different encryption methods for update requests of different sensitive types;

[0111] The synchronization and coordination module performs cross-platform synchronization and coordination based on the new blocks.

[0112] The above is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention, according to the technical solution of the present invention and its inventive concept, makes equivalent substitutions or changes, and all should be covered by the protection scope of the present invention.

Claims

1. A cross-platform intelligent project dynamic information real-time synchronization method, characterized in that: include: S1: communicate with each platform to obtain the latest update request, which includes the request platform, request time and request content. Perform sensitive analysis on the update request to assess the sensitivity of the update request and apply different security verification strategies to the update request accordingly. S2: It is assumed that there are several service nodes, and the best service node is selected to distribute the update request; when there is an abnormality in the execution process of the service node, the circuit breaker strategy is executed; the specific steps for implementing the circuit breaker strategy are: Update the total number of requests and failed requests of each service node in each time window in real time, and divide the number of failed requests by the total number of requests and multiply by percentage to get the error rate. If there are consecutive failures ≥ n times in the time window, where n is a positive integer, fast failure fuse is executed; otherwise, the window error rate is calculated and fuse is executed based on the error rate. There is a preset error rate of one. If the error rate is greater than or equal to the preset error rate of one, a high error rate fuse is executed; if the error rate is less than the error rate of one, no fuse is required; S3: The service node encrypts and stores the update request in the blockchain; S4: Perform cross-platform synchronization coordination based on the new block.

2. A cross-platform intelligent project dynamic information real-time synchronization method according to claim 1, characterized in that: The fast failure fuse and high error rate fuse are: Fast failure type fuse: Start the fast failure type fuse with a fuse time of T1. After T1, 10% of the update requests are allowed to pass the detection request. If any subsequent request is successful, the detection is successful, and the counter is restored and reset. If the detection is unsuccessful, the fuse time is extended. High error rate circuit breaker: Start the high error rate circuit breaker and enter the cooling state, that is, all requests directly return failure, start the cooling timer, maintain the cooling time T2, and enter the half-open state after the cooling time ends, allowing 10% of update requests to pass. When the success rate reaches 90%, the high error rate circuit breaker is closed; the cooling time increases each time the detection fails and the circuit breaker enters.

3. A cross-platform intelligent project dynamic information real-time synchronization method according to claim 2, characterized in that: Sensitive parsing for update requests: It is assumed that there is a sensitive word library, in which sensitive words are set by technical personnel in this field according to the actual requirements of each platform. Each sensitive word in the sensitive word library corresponds to a sensitive value. The request content is subjected to deep semantic analysis using NLP technology to obtain the sensitive words involved in the update request content, as well as the number of occurrences of each sensitive word and its corresponding sensitivity value. The number of occurrences of each sensitive word is multiplied by its corresponding sensitivity value to obtain the sensitive cumulative value of the number of occurrences corresponding to the sensitive word. The sensitive cumulative words of each sensitive word are summed up to obtain the total sensitivity value of the update request. If the total sensitivity value is greater than the set upper limit of the sensitivity interval, the update request is marked as a highly sensitive request. If the total sensitivity value is within the set sensitivity range, the update request is marked as a moderately sensitive request; If the total sensitivity value is less than the set lower limit of the sensitivity range, the update request is marked as a slightly sensitive request; If the update request is a mildly sensitive request, it can be directly processed and S2 is executed; If the update request is a moderately sensitive request, the legitimacy of the request source is further confirmed through device fingerprint binding until it passes the verification and executes S2; If the update request is a highly sensitive request, a secondary authentication is triggered until it passes the verification and S2 is executed.

4. A cross-platform intelligent project dynamic information real-time synchronization method according to claim 3, characterized in that: To distribute update requests: Step 1: Sort the update requests in descending order according to their corresponding total sensitivity values ​​to obtain an update request task schedule, and select the update request with the largest total sensitivity value as the target request; Step 2: Collect indicators of each service node to obtain node information, including IP address, heartbeat packet, number of concurrent connections, network delay, packet loss rate, CPU utilization, memory usage and request queue length; set a time window, check the heartbeat packet in the most recent time window from the current time, if there is a missing heartbeat packet, the service node is classified as an unavailable node, if there is no missing heartbeat packet, the service node is marked as an available service node; integrate all available service nodes to form a preliminary list of service nodes; Step 3: Comprehensively analyze each service node in the preliminary service node list based on the node information to generate a service value; Sort the service nodes in the preliminary service node list in descending order according to their corresponding service values, select the service node with the largest service value as the final service node, and send the target request to the final service node. At the same time, the request queue length of the final service node is increased by one; Step 4: Update the preliminary list of service nodes and the node information of each service node in real time, and repeat steps 1 to 3 until all update requests are allocated; each service node processes the update requests in its request queue in sequence according to the request time.

5. A cross-platform intelligent project dynamic information real-time synchronization method according to claim 4, characterized in that: Service value parsing process: Get the IP address where the update request is initiated, and calculate the distance between it and the IP addresses of each service node in the service node preliminary list to obtain the geographical distance, and process the geographical distance to obtain the regional affinity value; The concurrent connection number, network delay, packet loss rate, CPU utilization, memory usage and request queue length of each service node in the preliminary service node list are weightedly calculated to obtain the node performance value, and the node performance value and regional affinity value are weightedly calculated to obtain the service value of the service node.

6. A cross-platform intelligent project dynamic information real-time synchronization method according to claim 5, characterized in that: The service node encrypts the update request and stores it in the blockchain: Step 1: Extract the update request and its sensitive type. For low-sensitivity requests, encryption is not required. The service node and the waiting blockchain network reach consensus on the update request until the request is officially written into the blockchain. Once the confirmation is successful, a unique transaction identifier and timestamp are returned as the proof of data on the chain. If it is a moderately sensitive request, execute step 2; if it is a highly sensitive request, execute step 3. Step 2: Divide the update request according to the block size of AES, and fill the data blocks less than 16 bytes to meet the requirements of block encryption; randomly generate an initialization vector recorded as IV, for the first data block, it is alienated with IV and then encrypted with AES to obtain a ciphertext block, and each subsequent data block is alienated with the previous ciphertext block and then encrypted with AES to obtain a ciphertext block. After the encryption is complete, all ciphertext blocks are combined into the final encrypted data; Step 3: Convert the update request into a numerical sequence according to the character-value mapping table, identify the position of zero in the numerical sequence and record it as zero position, and remove all zero positions to complete the de-zeroing of the numerical sequence; then take the three adjacent numerical values ​​in the numerical sequence as a group of three elements, select the largest value in each group of three elements as the radius of the bottom circle, select the smallest value as the radius of the top circle, and the remaining values ​​as the height to build a truncated cone, so that each group of three elements corresponds to a truncated cone, calculate the volume of the truncated cone, and sort the volumes according to the position order of each group of three elements in the original sequence to form a preliminary encrypted numerical sequence; then invert the initial encrypted numerical sequence into a character sequence according to the character-value mapping table, and then encrypt the character sequence in the same way as step 2 to obtain a secondary ciphertext sequence, and then use the zero position of each zero position and the three elements of each volume as auxiliary information, and integrate the secondary ciphertext and auxiliary information into the final encrypted data; Step 4: After step 1, step 2 or step 3, the service node obtains the final update request data, calculates the data summary using SHA-256 to generate a data fingerprint to ensure data integrity, and collects metadata related to the update request, such as request sensitive type, request time, and service node identifier, and packages it with the final update request data into a standard transaction object; Use the private key of the service node to digitally sign the transaction object and generate signature data; encode and format the transaction object according to the blockchain protocol used to form the final transaction data packet; broadcast the constructed transaction data packet to the entire blockchain network through the blockchain interface or node network; Step 5: After receiving the transaction, each node in the blockchain network verifies the transaction. After verification, the transaction is added to the transaction pool to be packaged. According to the provisions of the blockchain consensus mechanism, the node selects several valid transactions from the transaction pool to be packaged and constructs a candidate block. The candidate block is verified by the consensus algorithm in the network, and all nodes reach a consensus on the legitimacy of the candidate block. Once consensus is reached, the candidate block is formally generated and added to the blockchain; Step 6: When the transaction is successfully packaged into the block, the service node obtains relevant information from the blockchain, including the unique transaction identifier, block number and generation time, and other metadata related to the transaction; and integrates the above information into a storage certificate.

7. A cross-platform intelligent project dynamic information real-time synchronization method according to claim 6, characterized in that: Cross-platform synchronization and coordination based on new blocks: Step 1: Blockchain event monitoring: Start the blockchain event listener to monitor the generation of new blocks and update request transactions recorded in the blocks in real time; Step 2: Data analysis and verification: After extracting the monitored transaction data, parse the data and verify its digital signature, timestamp and data summary; Step 3: Sorting and version management: Sort all captured update requests according to the timestamps in the blockchain and the preset version control rules; Step 4: Synchronous coordination and data distribution: After the final update status is determined, this status is used as authoritative data and update notifications are distributed to each platform through message queues or direct push; each receiving end updates the local cache, database or other storage system based on the received synchronization data. Step 5: Conflict resolution and compensation mechanism: If conflicts are found between different update requests during the sorting or version merging process, the conflict resolution strategy will be called to automatically merge them according to predefined rules. At the same time, the conflict handling process will be recorded using smart contracts. Step 6: Confirm feedback and audit records: After synchronization is completed, confirmation feedback is generated, including the unique identifier of each transaction, synchronization time and update status of each platform; all synchronization operations are audited regularly.

8. A cross-platform intelligent project dynamic information real-time synchronization device, characterized in that A cross-platform intelligent project dynamic information real-time synchronization method applied to any one of claims 1-7, comprising a request verification module, a service module, a block storage module and a synchronization coordination module; The request verification module communicates with each platform to obtain the latest update request, which includes the request platform, request time and request content. It performs sensitive analysis on the update request to assess the sensitivity of the update request and implements different security verification strategies accordingly. The service module analyzes the comprehensiveness of each service node to select the best service node to serve the update request. If there is an exception during the service process, the fuse strategy is executed; The block storage module encrypts and stores the update request to the blockchain by controlling the service node, and implements different encryption methods for update requests of different sensitive types; The synchronization coordination module performs cross-platform synchronization coordination based on the new block.

Images