A distributed multithreaded scheduling method and system for real estate registration business

CN122963724APending Publication Date: 2026-10-23广东省国土资源技术中心(广东省基础地理信息中心) +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611097901.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-23
Publication Date
2026-10-23

AI Technical Summary

Technical Problem

[0004]本发明实施例提供了一种面向不动产登记业务的分布式多线程调度方法及系统,能够解决现有技术中未考虑各执行节点的实际处理能力差异,导致任务分配与节点承载能力严重不匹配的问题,提高不动产批量登记业务效率,实现去中心化无锁跨节点批量事务一致性保障

Benefits of technology

本发明通过执行节点接收路由网关下发的节点任务信息,包括若干子任务以及子任务数量;其中,节点任务信息由路由网关基于预设的负载均衡策略,对各客户端发起的不动产登记业务的批量处理请求进行分发得到,利用路由网关实现批量登记请求的初步分流,避免单一节点请求过载。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122963724A_ABST
    Figure CN122963724A_ABST
Patent Text Reader

Abstract

The application discloses a kind of distributed multithreading scheduling methods and systems for real estate registration business, it is related to real estate registration technical field, method includes: receiving node task information issued by routing gateway;For subtask, the node repeats execution real estate registration business task scheduling process: real-time acquisition node state data, send to multithreaded task scheduler, multithreaded task scheduler is assumed by any other execution node in system, realize the unification of decentralized scheduling and task execution;According to node state data and node task information, calculate task allocation, and then redistribute subtask;Receive the subtask to be executed issued by multithreaded task scheduler, execute real estate registration business task, node task is completed, and is on standby, without waiting for global synchronization, realize the asynchronous continuous processing of task. Through the implementation of the application, the problem of task allocation imbalance and batch transaction inconsistency is solved, and the efficiency of real estate high-concurrency batch registration business is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of real estate registration technology, and in particular to a distributed multi-threaded scheduling method and system for real estate registration business. Background Technology

[0002] With the deepening of digital government construction, real estate registration services have gradually achieved online and integrated management, significantly improving efficiency and user experience. Currently, real estate registration services generally adopt a centralized architecture of a scheduling center (Master) and execution nodes (Client). That is, after receiving batch registration requests, the scheduling center splits the tasks according to preset rules (such as polling, minimum number of node connections) and distributes them to the execution nodes; after the execution nodes complete the tasks, they summarize the results to the scheduling center, which then completes the batch data entry.

[0003] However, in real estate registration business based on centralized architecture, the scheduling center only completes the task splitting and distribution according to the preset static rules, without taking into account the differences in the actual processing capabilities of each execution node. This results in a serious mismatch between task allocation and node carrying capacity, with high-load nodes continuously accumulating tasks and low-load nodes having idle resources, making it difficult to adapt to the needs of batch real estate registration business. Summary of the Invention

[0004] This invention provides a distributed multi-threaded scheduling method and system for real estate registration business, which can solve the problem in the prior art that does not consider the differences in the actual processing capabilities of each execution node, resulting in a serious mismatch between task allocation and node carrying capacity, improve the efficiency of real estate batch registration business, and achieve decentralized lock-free cross-node batch transaction consistency guarantee.

[0005] One embodiment of the present invention provides a distributed multi-threaded scheduling method for real estate registration business, applicable to each execution node in a distributed multi-threaded scheduling system; the distributed multi-threaded scheduling system further includes: several clients and a routing gateway; Distributed multithreaded scheduling methods include: Receive node task information sent by the routing gateway; the node task information includes: several subtasks and the number of subtasks; wherein, the node task information is obtained by the routing gateway based on a preset load balancing strategy to distribute the batch processing requests for real estate registration business initiated by each client; For each subtask, repeat the real estate registration business task scheduling process until all subtasks have been traversed: The real estate registration business task scheduling process includes: real-time collection of node status data, and sending the node status data and node task information to a multi-threaded task scheduler, so that the multi-threaded task scheduler can calculate the node availability capacity of the current execution node based on the node status data and node task information of the current execution node; receiving the node availability capacity of other execution nodes in the distributed multi-threaded scheduling system; calculating the total available capacity capacity of the cluster based on the node availability capacity of each execution node and a preset node performance weight coefficient; calculating the task allocation amount of the current execution node based on the total number of subtasks, the node availability capacity of the current execution node, and the total available capacity capacity of the cluster; the total number of subtasks is the sum of the number of subtasks in the batch processing request; and reallocating the subtasks of the current execution node according to the task allocation amount of the current execution node to obtain the subtasks to be executed by the current execution node; wherein, the multi-threaded task scheduler is any other execution node in the distributed multi-threaded scheduling system; Receive subtasks to be executed from the multi-threaded task scheduler; Based on the sub-tasks to be executed, perform real estate registration business tasks.

[0006] Furthermore, load balancing strategies include: round-robin strategy, connection count strategy, or random strategy; Based on a preset load balancing strategy, batch processing requests for real estate registration services initiated by each client are distributed to obtain the following: Based on a preset polling strategy, the batch processing requests for real estate registration services initiated by each client are distributed according to the order of the requests initiated by each client. Alternatively, based on a preset connection count strategy, the connection count of each execution node can be obtained, and the batch processing requests for real estate registration initiated by each client can be distributed in ascending order of connection count. Alternatively, based on a preset random strategy, batch processing requests for real estate registration initiated by each client can be randomly distributed.

[0007] Furthermore, the node status data includes: CPU availability, memory availability, thread pool availability, task queue availability, and the average time of the previous task; the node task information also includes: the real estate registration business type corresponding to each subtask. Based on the node status data and task information of the currently executing node, calculate the node availability capacity of the currently executing node, including: The available capacity of the basic node is calculated based on the CPU availability, memory availability, thread pool availability, and task queue availability of the current execution node. Based on the real estate registration business type corresponding to each subtask contained in the current execution node, and the preset correspondence table, determine the business complexity correction coefficient; Based on the average time of the previous task and the preset average time of the baseline task, determine the time correction coefficient for the preceding task. Based on the business complexity correction factor and the preceding task time correction factor, the available capacity of the basic node is corrected to obtain the available capacity of the currently executing node.

[0008] Furthermore, the types of real estate registration services include: initial registration, change registration, transfer registration, cancellation registration, correction registration, objection registration, preliminary registration, and seizure registration.

[0009] Furthermore, based on the node availability capacity of each execution node and the preset node performance weighting coefficient, the total available capacity capacity of the cluster is calculated, including: Based on the preset node performance weight coefficients, the available capacity of each execution node is weighted and summed, and then divided by the sum of the node performance weight coefficients of all execution nodes to obtain the total available capacity of the cluster.

[0010] Furthermore, based on the total number of subtasks, the node availability capacity of the current executing node, and the total cluster availability capacity, the task allocation for the current executing node is calculated, including: The total number of subtasks is allocated proportionally based on the proportion of the current execution node's available capacity to the total available capacity of the cluster, thus obtaining the task allocation amount for the current execution node.

[0011] Furthermore, after receiving the subtasks to be executed from the multi-threaded task scheduler, it also includes: Based on a pre-defined standardized verification rule engine, the subtask to be executed is verified; Based on the verification results, the subtasks to be executed are filtered to obtain the filtered subtasks to be executed.

[0012] Furthermore, based on the sub-tasks to be executed, after executing the real estate registration business task, it also includes: The execution results of all subtasks to be executed in the same batch processing request are summarized and organized to obtain the execution result data; The execution result data is uploaded to the multi-threaded task scheduler so that the multi-threaded task scheduler can perform transaction consistency verification on the execution result data of all execution nodes. If the transaction consistency verification passes, the execution result data of all execution nodes is written to the real estate registration database in batches. If the transaction consistency verification fails, an entry failure signal is generated.

[0013] Based on the above method embodiments, the present invention provides a corresponding system embodiment, including: a plurality of clients, a routing gateway, and a plurality of execution nodes; Each client is used to initiate a batch processing request for real estate registration business; and uploads the batch processing request for real estate registration business to the routing gateway; The routing gateway is used to distribute batch processing requests for real estate registration business based on a preset load balancing strategy, obtain the node task information of each execution node, and send the node task information of each execution node to the corresponding execution node. The node task information includes: several subtasks and the number of subtasks. Each execution node is used to repeatedly execute the real estate registration business task scheduling process for each subtask until all subtasks are traversed. The real estate registration business task scheduling process includes: real-time collection of node status data and sending the node status data and node task information to the multi-threaded task scheduler, so that the multi-threaded task scheduler can calculate the node availability capacity of the current execution node based on the node status data and node task information of the current execution node; receiving the node availability capacity of other execution nodes in the distributed multi-threaded scheduling system; and calculating the node availability capacity of each execution node and a preset node performance weight coefficient. The system calculates the total available capacity of the cluster; based on the total number of subtasks, the available capacity of the current execution node, and the total available capacity of the cluster, it calculates the task allocation amount for the current execution node; the total number of subtasks is the sum of the number of subtasks in the batch processing requests; based on the task allocation amount of the current execution node, it reallocates the subtasks of the current execution node to obtain the subtasks to be executed for the current execution node; the multi-threaded task scheduler is any other execution node in the distributed multi-threaded scheduling system; it receives the subtasks to be executed issued by the multi-threaded task scheduler; and based on the subtasks to be executed, it executes the real estate registration business task.

[0014] Furthermore, each execution node is also used to verify the subtasks to be executed based on a preset standardized verification rule engine; and to filter the subtasks to be executed based on the verification results, thereby obtaining the filtered subtasks to be executed.

[0015] Compared with the prior art, the beneficial effects of this embodiment are as follows: This invention enables the execution node to receive node task information from the routing gateway, including several subtasks and the number of subtasks. The node task information is obtained by the routing gateway based on a preset load balancing strategy, which distributes batch processing requests for real estate registration services initiated by each client. The routing gateway is used to achieve initial distribution of batch registration requests and avoid overload of requests to a single node.

[0016] Next, for each subtask, the following real estate registration business task scheduling process is repeated until all subtasks are traversed: the execution node collects node status data in real time and sends the node status data and node task information to the multi-threaded task scheduler. The multi-threaded task scheduler is any other execution node in the distributed multi-threaded scheduling system. In this way, each execution node in the system has both task scheduling and business execution capabilities. There is no dedicated fixed scheduling center node. Any execution node can be selected as the multi-threaded task scheduler to undertake scheduling functions, realizing a decentralized distributed architecture for task scheduling and business execution.

[0017] The multi-threaded task scheduler calculates the available capacity of the current execution node based on its node status data and task information, quantifying the node's actual processing capacity. It receives available capacity data from other execution nodes in the distributed multi-threaded scheduling system. Based on the available capacity of each execution node and preset node performance weight coefficients, it calculates the total available capacity of the cluster, achieving global quantification of the entire application cluster's processing capacity. Based on the total number of subtasks, the available capacity of the current execution node, and the total available capacity of the cluster, it calculates the task allocation for the current execution node, achieving precise matching between task allocation and the node's actual capacity. This maximizes cluster resource utilization without increasing additional resource overhead, adapting to the differentiated processing needs of different types of registration services while avoiding node overload or resource idleness, ensuring stable and orderly execution of batch services. The multi-threaded task scheduler reallocates subtasks of the current execution node based on its task allocation, resulting in unexecuted subtasks for the current execution node. This eliminates the problem of high-load node backlog and low-load node idleness, improving the overall resource utilization of the cluster. The execution node receives the subtasks to be executed from the multi-threaded task scheduler and executes the real estate registration business tasks based on the subtasks to be executed.

[0018] In summary, this invention achieves a match between the task allocation and the actual processing capacity of the nodes by collecting and reporting node status in real time and dynamically calculating the task allocation using a multi-threaded task scheduler. This solves the problem in the prior art where the differences in the actual processing capacity of each execution node were not considered, resulting in a serious mismatch between task allocation and node carrying capacity, and improves the efficiency of bulk real estate registration. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating a distributed multi-threaded scheduling method for real estate registration services provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of a distributed multi-threaded scheduling system for real estate registration business provided in an embodiment of the present invention; Figure 3This is a flowchart illustrating a single-node multi-threaded task scheduling process according to an embodiment of the present invention; Figure 4 This is another flowchart illustrating a distributed multi-threaded scheduling method for real estate registration services provided in an embodiment of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] In the description of this invention, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0022] like Figure 1 As shown, to address the problem in existing technologies that fail to consider the differences in actual processing capabilities of each execution node, leading to a severe mismatch between task allocation and node capacity, an embodiment of this invention provides a distributed multi-threaded scheduling method for real estate registration services, applicable to each execution node in a distributed multi-threaded scheduling system; as shown... Figure 2 As shown, the distributed multi-threaded scheduling system also includes several clients and a routing gateway.

[0023] Distributed multi-threaded scheduling methods include at least the following steps: Step S1: Receive node task information sent by the routing gateway; the node task information includes: several sub-tasks and the number of sub-tasks; wherein, the node task information is obtained by the routing gateway based on the preset load balancing strategy to distribute the batch processing requests for real estate registration business initiated by each client. In a preferred embodiment, the node task information further includes: the real estate registration business type corresponding to each sub-task; For step S1, in the distributed multi-threaded scheduling system, the real estate registration personnel initiate a batch processing request for real estate registration business through the client. The batch processing request includes several sub-tasks, and each sub-task includes real estate information, applicant information, business requirements information, and rights information.

[0024] It should be noted that the real estate information includes ownership information, natural condition information, and transaction contract information related to land, houses, and other real estate objects, used to characterize the attributes and transaction background of the real estate object corresponding to this registration business; the applicant information includes the identity information of the right holder and obligor corresponding to this registration business, used to clarify the subject qualification and the subject of ownership of the business; the business requirement information includes the basic compliance supporting documents required for handling the corresponding real estate registration business, including identity documents, ownership documents, legal compliance documents, fee payment documents, and other essential documents for handling the business, used to ensure the legal compliance of the registration business; and the previous rights information includes the historical ownership information of the corresponding real estate.

[0025] Batch processing requests initiated by the client are transmitted to the routing gateway via the network. In this embodiment, the routing gateway is an Nginx gateway, which is used to uniformly receive batch service requests sent by various clients.

[0026] After receiving a batch processing request, the routing gateway distributes the batch processing requests for real estate registration services initiated by each client based on a preset load balancing strategy. It assigns an execution node to each batch service request in turn, and determines the task content and scale to be undertaken by each execution node through allocation, forming the node task information corresponding to each execution node, including several sub-tasks, the number of sub-tasks, and the real estate registration service type corresponding to each sub-task. Subsequently, the routing gateway sends the node task information of each execution node to the corresponding execution node, completing the request distribution process.

[0027] In a preferred embodiment, the types of real estate registration services include eight categories: initial registration, change registration, transfer registration, cancellation registration, correction registration, objection registration, preliminary registration, and seizure registration.

[0028] It should be noted that the eight types of real estate registration services listed above are basic service types. In practice, real estate registration service types can be expanded to other derivative registration service types according to local real estate registration regulations.

[0029] By using the above-mentioned load-balanced request distribution method, batch business requests from multiple clients can be evenly distributed to different execution nodes for processing. This avoids the problem of excessive task backlog and high load on a single execution node due to the initial request distribution being too concentrated, ensuring that the load of each execution node is balanced and the overall system operation is stable.

[0030] In a preferred embodiment, the load balancing strategy includes: a round-robin strategy, a connection count strategy, or a random strategy; Based on a preset load balancing strategy, batch processing requests for real estate registration services initiated by each client are distributed to obtain the following: Based on a preset polling strategy, the batch processing requests for real estate registration services initiated by each client are distributed according to the order of the requests initiated by each client. Alternatively, based on a preset connection count strategy, the connection count of each execution node can be obtained, and the batch processing requests for real estate registration initiated by each client can be distributed in ascending order of connection count. Alternatively, based on a preset random strategy, batch processing requests for real estate registration initiated by each client can be randomly distributed.

[0031] In one embodiment of the present invention, the load balancing strategy includes three optional scheduling methods: round-robin strategy, connection number strategy, and random strategy. Only one strategy needs to be selected. The specific strategy can be flexibly configured according to the system deployment architecture and business operation status to achieve the optimal load balancing effect in different scenarios.

[0032] When distributing requests based on a preset polling strategy, the routing gateway distributes the requests to each execution node in the order in which each client initiates batch processing requests. This strategy has a simple scheduling logic and fair allocation. It does not require additional collection of node load status and is suitable for scenarios where the hardware configuration of each execution node is consistent and the business load is relatively stable. It can quickly achieve uniform distribution of requests.

[0033] In this embodiment, the routing gateway uses a round-robin strategy as the default load balancing distribution method.

[0034] When distributing requests based on a preset connection number strategy, the routing gateway collects the current connection number (i.e., the amount of tasks allocated) of each execution node in real time, and distributes batch processing requests to the execution node with the lowest current load according to the connection number from smallest to largest. This strategy can dynamically sense changes in node load and allocate requests accordingly, effectively avoiding overload of a single node due to concentrated tasks. It is suitable for scenarios where the performance of each execution node is different and the business load fluctuates greatly, ensuring dynamic balance of the overall cluster load.

[0035] When distributing requests based on a preset random strategy, the routing gateway randomly distributes batch processing requests initiated by the client to the execution nodes. There is no need to maintain the request order and node status, resulting in extremely low scheduling overhead. It is suitable for large-scale cluster scenarios with high request concurrency and overall balanced node load, and can quickly complete request distribution, thereby improving the system's high-concurrency processing efficiency.

[0036] The execution node receives node task information from the routing gateway, providing a basis for task execution for the distributed processing of subsequent batch business requests.

[0037] Step S2: For each subtask, repeat the real estate registration business task scheduling process until all subtasks are traversed. The real estate registration business task scheduling process includes: real-time collection of node status data and sending the node status data and node task information to the multi-threaded task scheduler, so that the multi-threaded task scheduler can calculate the node availability capacity of the current execution node based on the node status data and node task information of the current execution node; receiving the node availability capacity of other execution nodes in the distributed multi-threaded scheduling system; and calculating the node availability capacity of each execution node based on the node availability capacity of each execution node and the preset node performance weight coefficient. Calculate the total available capacity of the cluster; calculate the task allocation amount for the current execution node based on the total number of subtasks, the node available capacity of the current execution node, and the total available capacity of the cluster; the total number of subtasks is the sum of the number of subtasks in the batch processing requests; reallocate the subtasks of the current execution node according to the task allocation amount of the current execution node to obtain the subtasks to be executed for the current execution node; the multi-threaded task scheduler is any other execution node in the distributed multi-threaded scheduling system; receive the subtasks to be executed issued by the multi-threaded task scheduler; and execute the real estate registration business task based on the subtasks to be executed.

[0038] In a preferred embodiment, the node status data includes: CPU availability, memory availability, thread pool availability, task queue availability, and average time of the previous task; For step S2, after receiving the node task information sent by the routing gateway, each execution node cyclically executes the real estate registration business task scheduling process for a batch of sub-tasks until all sub-tasks are processed.

[0039] During the scheduling of a single real estate registration task, the execution node collects current node status data in real time through the built-in scheduler Client. This node status data includes CPU availability, memory availability, thread pool availability, task queue availability, and the average time of the previous task. After completing the node status data collection, the execution node synchronously stores the complete node status data in a distributed cache. Through the high availability and sharing characteristics of the distributed cache, a globally unified and real-time accessible node status data source is provided to the multi-threaded task scheduler.

[0040] The aforementioned node status data and node task information are uniformly sent to the multi-threaded task scheduler Master. The multi-threaded task scheduler Master serves as the scheduling core for the currently executing node and can be any other execution node in the distributed multi-threaded scheduling system besides the currently executing node. Therefore, each execution node in this invention's architecture possesses the dual functions of master scheduling and task execution, eliminating the need for a separate dedicated scheduling center and forming a decentralized distributed task scheduling operation.

[0041] It should be noted that the execution node acting as the Master of the multi-threaded task scheduler has the ability to switch roles. When the load of the execution node acting as the Master of the multi-threaded task scheduler is lower than a preset threshold, it will no longer assume the global scheduling function of the Master, but will only act as a task execution role to process the assigned sub-tasks.

[0042] Preferably, the node status data also includes node health status, which reflects whether the node is operating normally. When the node health status is determined to be abnormal, i.e., the node cannot operate normally, the multi-threaded task scheduler will immediately trigger the abnormal node isolation mechanism to isolate the abnormal node and prevent it from being assigned any new sub-tasks, thus ensuring the stability of batch processing of real estate registration business. In addition, the multi-threaded task scheduler will also generate node abnormality alarm information so that maintenance personnel can promptly troubleshoot node failures.

[0043] When the current execution node is in normal health status, the multi-threaded task scheduler calculates the node availability rate of the current execution node based on the node status data and node task information. This indicator is used to quantify the ability of a single execution node to currently handle new tasks.

[0044] In a preferred embodiment, the available capacity of the current execution node is calculated based on the node status data and node task information of the current execution node, including: The available capacity of the basic node is calculated based on the CPU availability, memory availability, thread pool availability, and task queue availability of the current execution node. Based on the real estate registration business type corresponding to each subtask contained in the current execution node, and the preset correspondence table, determine the business complexity correction coefficient; Based on the average time of the previous task and the preset average time of the baseline task, determine the time correction coefficient for the preceding task. Based on the business complexity correction factor and the preceding task time correction factor, the available capacity of the basic node is corrected to obtain the available capacity of the currently executing node.

[0045] In one embodiment of the present invention, the hardware resource availability rate is calculated based on the CPU availability rate and memory availability rate of the current execution node using the following formula, which reflects the remaining carrying capacity of the node server's core hardware (CPU, memory): ; in, express Weight, Indicates memory weight, express The sum of the weights and the memory weights, i.e. In this embodiment, Weight 30%, memory weight 30%, The sum of weights and memory weights It is 60%.

[0046] Based on the thread pool availability and task queue availability, the task processing resource availability is calculated using the following formula, which reflects the remaining capacity of the node's multi-threaded operation (thread pool, task queue): ; in, Indicates the thread pool availability weight. Indicates the task queue availability weight. This represents the sum of the thread pool availability weight and the task queue availability weight. In this embodiment, the thread pool availability weight... The task queue availability weight is 20%. The weight is 20%, which is the sum of the thread pool availability weight and the task queue availability weight. It is 40%.

[0047] The availability of hardware resources and the availability of task processing resources are weighted and summed to obtain the basic node availability capacity, thus achieving a comprehensive quantification of the hardware performance of the execution node and the multi-threaded running status. The specific formula is as follows: ; Based on this, in order to meet the differentiated processing needs of real estate registration business, a business complexity correction coefficient and a preceding task time correction coefficient are introduced to correct the available capacity of basic nodes, so as to ensure that the finally calculated available capacity of nodes can truly and comprehensively reflect the actual task handling capacity of the execution nodes in the current business scenario.

[0048] The business complexity correction coefficient is determined based on the real estate registration business type corresponding to the sub-task undertaken by the current execution node, combined with the pre-set correspondence table between real estate registration business types and business complexity correction coefficients (as shown in Table 1). It is used to quantify the differences in complexity of different real estate registration businesses, such as initial registration, transfer registration, and seizure registration, in terms of processing flow, data volume, and verification rules. This corrects the limitation that the available capacity rate of the basic node does not consider the differences in business types and avoids the deviation in capacity assessment caused by different business complexities.

[0049] Table 1. Correspondence between Real Estate Registration Business Types and Business Complexity Correction Coefficients In this embodiment, change registration, cancellation registration, and correction registration are classified as simple business processes, with a corresponding business complexity correction coefficient set to 1.0. These business processes are concise, have fewer verification steps, and shorter processing time, resulting in lower node resource consumption. Therefore, a base coefficient of 1.0 is used as the basic reference for calculating carrying capacity. Objection registration and pre-registration are classified as medium-complexity business processes, with a corresponding business complexity correction coefficient set to 0.9. These business processes involve additional ownership verification and stakeholder review, resulting in higher processing complexity and resource consumption than simple business processes. Therefore, a coefficient of 0.9 is used to appropriately lower the available carrying capacity of the basic nodes to avoid overloading the nodes due to handling medium-complexity business processes. Initial registration, transfer registration, and seizure registration are classified as high-complexity business processes, with a corresponding business complexity correction coefficient set to 0.8. These business processes involve complete ownership investigation, material review, and multi-system linkage verification, resulting in significantly higher data processing volume and resource consumption. Therefore, a coefficient of 0.8 is used to further lower the available carrying capacity of the basic nodes to ensure stable processing of high-complexity business processes within the node's carrying capacity.

[0050] It should be noted that the coefficients in the corresponding relationship table are empirical optimization results and can be dynamically adjusted according to the actual business processing scenarios and cluster operation status to adapt to the differentiated processing needs of real estate registration business in different regions and ensure that the business complexity correction coefficient always matches the resource consumption characteristics of actual business processing.

[0051] To quantify the real-time operating efficiency of nodes when processing corresponding business, a correction coefficient for the time consumption of preceding tasks is introduced. The multi-threaded task scheduler first obtains the actual average time consumption of the task group of the current execution node, and at the same time reads the preset average time consumption of the baseline task. The average time consumption of the baseline task is set according to the type of real estate registration business. That is, for different core businesses such as first registration and change registration, the normal processing time range of the corresponding standard task volume (such as 50 business in a single group) is preset respectively.

[0052] The correction factor for the time consumption of the preceding task is calculated using the following formula: ; It should be noted that the value range of the correction coefficient for the time consumption of the preceding task needs to be limited to [0.7, 1.2] to avoid the influence of extreme values.

[0053] Finally, based on the business complexity correction factor and the preceding task time correction factor, the available capacity of the basic node is corrected using the following formula to obtain the corresponding available capacity of the node: ; The available capacity of nodes, corrected by the aforementioned business complexity correction coefficient and preceding task time correction coefficient, can truly and comprehensively reflect the actual task-bearing capacity of the current execution node in the current real estate registration business scenario. This effectively avoids the load imbalance problem caused by relying solely on hardware parameters and ignoring the differences in business needs and node operating efficiency in traditional capacity calculations.

[0054] Next, the multi-threaded task scheduler corresponding to the current execution node also synchronously receives the node availability capacity reported by each of the other execution nodes in the distributed multi-threaded scheduling system. The node availability capacity of each of the other execution nodes is calculated by its own corresponding multi-threaded task scheduler, Master.

[0055] In a preferred embodiment, the total available capacity of the cluster is calculated based on the node availability capacity of each execution node and a preset node performance weighting coefficient, including: Based on the preset node performance weight coefficients, the available capacity of each execution node is weighted and summed, and then divided by the sum of the node performance weight coefficients of all execution nodes to obtain the total available capacity of the cluster.

[0056] In one embodiment of the present invention, after receiving the node availability capacity rate sent by other execution nodes in the distributed multi-threaded scheduling system, the multi-threaded task scheduler obtains the node availability capacity rate of all execution nodes. Combining the node availability capacity rate of each execution node with a preset node performance weight coefficient, the total cluster availability capacity rate of the entire application cluster is calculated, thereby characterizing the overall task capacity limit of the cluster. The specific calculation formula is as follows: ; Among them, the node performance weight coefficient is used to distinguish the performance differences of nodes with different hardware configurations, ensuring that the contribution of high-performance nodes to the total cluster capacity is more realistic, avoiding the deviation in cluster capacity assessment caused by differences in hardware configuration, and enabling the total available capacity of the cluster to truly and comprehensively reflect the overall task capacity of the entire distributed cluster.

[0057] In a preferred embodiment, the task allocation amount for the current execution node is calculated based on the total number of subtasks, the node availability capacity of the current execution node, and the total cluster availability capacity, including: The total number of subtasks is allocated proportionally based on the proportion of the current execution node's available capacity to the total available capacity of the cluster, thus obtaining the task allocation amount for the current execution node.

[0058] In one embodiment of the present invention, the multi-threaded task scheduler uses the total number of subtasks as the allocation benchmark, and combines the node availability capacity of the current execution node with the total cluster availability capacity to calculate the task allocation amount for the current execution node through a proportional allocation algorithm, ensuring that the task allocation matches the node's capacity. The specific formula is as follows: ; It should be noted that the total number of subtasks is the sum of the number of all subtasks included in a single batch processing request.

[0059] Finally, the multi-threaded task scheduler reallocates the subtasks currently being handled by the current execution node based on the calculated task allocation amount of the current execution node, adjusts the subtask size of the current node, and ultimately obtains the subtasks to be executed corresponding to the current execution node, thus completing the dynamic load balancing scheduling process.

[0060] The current execution node receives the subtasks to be executed from the corresponding multi-threaded task scheduler through the built-in scheduler Client, and starts the multi-threaded execution process based on the local thread pool management mechanism of the current execution node.

[0061] In this embodiment, the execution node is an independent computing unit deployed on a physical / virtual server, which combines main scheduling and task execution, and serves as the running carrier for threads. A thread is the smallest scheduling / execution unit within the process of the execution node that can independently execute batch registered tasks. A single execution node manages multiple threads to achieve parallel processing of tasks, thereby improving business processing efficiency.

[0062] In a preferred embodiment, after receiving the subtask to be executed from the multi-threaded task scheduler, the method further includes: Based on a pre-defined standardized verification rule engine, the subtask to be executed is verified; Based on the verification results, the subtasks to be executed are filtered to obtain the filtered subtasks to be executed.

[0063] In one embodiment of the present invention, in order to ensure the compliance and validity of the subtasks to be executed and to avoid invalid tasks occupying node thread resources, after receiving the subtasks to be executed from the corresponding multi-threaded task scheduler, the current execution node performs a full-dimensional legality check on the subtasks to be executed based on a preset standardized verification rule engine. The verification content covers the completeness of business requirements, permission compliance, and data format standardization. The specific verification process is as follows: First, a completeness check of business requirements is performed. For each registration business type corresponding to the sub-task (such as initial registration, seizure registration, etc.), the pre-set list of required requirements is compared with the list of required requirements. The core data of the ownership certificate, identity certificate and other core requirements attached to the sub-task are checked one by one to ensure that there are no missing core fields or missing requirements, thus ensuring the executability of the task from the business process level. Secondly, conduct permission compliance verification by calling the system's unified permission verification interface to verify whether the qualifications and permission level of the task initiator (handling agency / operator) match the operation permissions for this type of registration business, thus preventing business risks caused by unauthorized operations. Finally, data format compliance is verified. Based on the unified data standard for real estate registration, technical means such as regular expressions and format verification rules are used to verify whether the field length, data type, and encoding rules of key data such as real estate unit number and certificate number are compliant, thus ensuring the accuracy of business processing from the data level.

[0064] After the current execution node completes the above verification, it filters the subtasks to be executed based on the verification results. Only subtasks that pass all three verifications are included in the subsequent multi-threaded execution process. Subtasks that fail the verification are directly intercepted and marked as exceptions. This completely avoids invalid tasks occupying node thread resources and ensures the accuracy and efficiency of batch real estate registration business processing.

[0065] The current execution node performs a multi-threaded execution process for real estate registration business based on the filtered subtasks to be executed, which is implemented through the following steps: First, based on the real estate registration business type corresponding to the subtask, match the corresponding interface implementation method, such as the initial registration processing interface and the seizure registration processing interface. Then, according to the principle of prioritizing the allocation of core threads and filling in the gaps with idle threads, allocate appropriate execution threads to the subtask to ensure that the task starts under a resource environment with reasonable node load. During the process of thread execution registration business, the task execution status (including initialization, processing, execution success or execution failure) and the time consumed by key nodes are recorded in real time and synchronized to the scheduler client of the execution node, so that the multi-threaded task scheduler can keep abreast of the running status and task progress of each node in real time. For tasks that fail to execute, a local retry mechanism is initiated. If the retry fails, the task is marked as an abnormal task and reported to the multi-threaded task scheduler. At the same time, other nodes are terminated from processing the same request to avoid invalid resource consumption and data conflicts, and the real estate registration business task of the subtask is finally completed.

[0066] After executing the real estate registration business task based on the sub-task to be executed, the node releases its local resources and directly enters the "pending allocation" state. It can directly enter the standby state and take over the next round of sub-tasks without waiting for the task processing results of other nodes or global synchronization instructions. The above real estate registration business task scheduling process is repeated. The decentralized scheduling architecture eliminates the synchronization waiting overhead between nodes, realizes lock-free asynchronous parallel processing, effectively avoids the performance bottleneck caused by global locks, and greatly improves the concurrent processing efficiency and task flow speed of the cluster.

[0067] In a preferred embodiment, after executing the real estate registration business task based on the sub-task to be executed, the process further includes: The execution results of all subtasks to be executed in the same batch processing request are summarized and organized to obtain the execution result data; The execution result data is uploaded to the multi-threaded task scheduler so that the multi-threaded task scheduler can perform transaction consistency verification on the execution result data. If the transaction consistency verification passes, the execution result data is written to the real estate registration database in batches. If the transaction consistency verification fails, an entry failure signal is generated.

[0068] In one embodiment of the present invention, after the current execution node completes the real estate registration business, the built-in scheduler Client summarizes and organizes the execution results of all sub-tasks in the same batch processing request, collects the result data of the same batch request, and classifies and summarizes them according to the business object to ensure that the results are traceable.

[0069] For successfully executed tasks, complete execution result data including registration result information, process logs, and electronic vouchers is compiled; for failed tasks, the reasons for failure and detailed logs are attached, and finally, complete execution result data is obtained and uploaded to the corresponding multi-threaded task scheduler.

[0070] After receiving the execution result data from all execution nodes, the multi-threaded task scheduler initiates a transaction consistency verification process, including execution result integrity verification and data logic consistency verification. The specific implementation is as follows: First, retrieve the original task breakdown list of the batch request as the verification benchmark, which includes the number of all subtasks under the batch request, the subtask IDs, and the business object mapping relationships.

[0071] For the integrity verification of execution results, it is verified that there are no missing business objects, the number of reported sub-tasks is consistent with the total number of splits, and all receiving nodes have completed the reporting; for the consistency verification of data logic, it is verified that the core fields are compliant according to the real estate registration business rules, there is no duplication of cross-node data, and the status codes and timestamps are logically consistent.

[0072] Only when all dimensions pass the verification will the qualified result data be written to the real estate registration database in batches. During the data entry process, atomic operations are performed to ensure that all data of all sub-tasks under the same request are either all successfully entered into the database or all are rolled back. If any dimension verification fails or data writing fails during the data entry process, a data entry failure signal is generated, triggering a global rollback mechanism to cancel the associated data that has been entered into the database and notify the corresponding execution node to re-execute the relevant sub-tasks. This ensures the integrity, consistency and accuracy of batch real estate registration business processing.

[0073] After the data entry is completed, a batch registration business processing receipt is generated, which includes the total number of transactions, the number of successful transactions, the number of failed transactions, and a list of transaction numbers. The batch registration business processing receipt is then synchronized to the client, and the system business status log is updated, completing the scheduling and processing loop of the entire batch registration task.

[0074] like Figure 3 The diagram illustrates the process of single-node multi-threaded task scheduling. On the client side, multiple clients, such as A, B, C, and N, initiate batch processing requests. Each client corresponds to a batch registration service request containing several sub-tasks. All batch requests from clients are uniformly aggregated at the routing layer. The routing gateway distributes the complete client requests to execution nodes such as Node 1, Node 2, Node 3, and Node N in the cluster layer using a preset load balancing strategy, including round-robin, connection count, or random strategies. The default strategy is round-robin. For example, Node 1 handles the service request from Client B, Node 2 handles the service request from Client C, Node 3 handles the service request from Client A, and Node N handles the service request from Client N. Each execution node independently processes all batch services for its corresponding client, meaning a single node fully undertakes all sub-tasks of a client and completes the full service processing of that client's request through its own multi-threading capabilities.

[0075] like Figure 4 The diagram shows another flowchart of the distributed multi-threaded scheduling method for real estate registration business according to the present invention. On the client side, multiple clients such as A, B, C, and N initiate batch processing requests respectively. All batch requests from clients are uniformly converged to the routing layer. The routing gateway distributes the requests to execution nodes such as node 1, node 2, node 3, and node N in the cluster layer through a preset load balancing strategy.

[0076] Taking node 1 as an example, after receiving the assigned task, node 1 reports its node status information to the multi-threaded task scheduler Master through the built-in scheduler Client. In this embodiment, node X1 acts as the multi-threaded task scheduler Master. Node X1 can be one of the execution nodes such as node 2, node 3, and node N. Similarly, node 2 can also have node X2 in the system act as its corresponding multi-threaded task scheduler Master. Node X2 can be one of the execution nodes such as node 1, node 3, and node N. And so on. The system does not need to deploy a fixed global central scheduling node. Any execution node can dynamically act as the multi-threaded task scheduler Master. Other nodes access the collaboration as scheduler clients. Each node can flexibly switch between scheduling and execution, forming a mesh distributed collaborative architecture. This completely breaks away from the constraints of the traditional centralized scheduling architecture and naturally avoids the risk of single point of failure of the central node.

[0077] The Master allocates the optimal task load to Node 1 based on a real-time dynamic task allocation strategy. Node 1 then independently executes its assigned subtasks using a single-node, multi-threaded approach, without waiting for the execution results of other nodes in the same batch. After task execution is complete, Node 1's scheduler Client summarizes and organizes the execution results of all subtasks and asynchronously sends the execution status, node available load, and health status back to the Master or distributed cache. This avoids synchronous blocking while waiting for global summarization and database entry to complete before releasing resources, achieving lock-free contention scheduling. Finally, the Master initiates transaction consistency verification and batch database entry processes, writing data to the database in batches, ultimately completing the closed-loop processing of the entire batch registration task.

[0078] After Node 1 completes the processing of its current sub-task and provides asynchronous status feedback, it immediately releases its local computing resources and automatically enters the task-awaiting state. This process of node status feedback, entering the waiting state, and waiting for the next round of task allocation is repeated cyclically, enabling the orderly execution of batch tasks in rounds. Each node independently completes its own task loop and state transition, and there are no conflicts between them in terms of task preemption or resource queuing, effectively avoiding cross-node competition interference.

[0079] The registration process of this invention achieves efficient parallel processing of provincial-level real estate batch registration business through distributed multi-threaded scheduling. Combined with load balancing, dynamic task allocation, transaction consistency verification and transaction consistency guarantee mechanism, it greatly improves the processing efficiency, resource utilization and data accuracy of batch business, solves the technical pain points of low processing efficiency of traditional single nodes and poor data consistency in distributed scenarios, and ensures the stable, efficient and reliable operation of provincial-level real estate batch registration business.

[0080] Based on the above method embodiments, corresponding system embodiments are provided; One embodiment of the present invention provides a distributed multi-threaded scheduling system for real estate registration business, comprising: several clients, a routing gateway, and several execution nodes; Each client is used to initiate a batch processing request for real estate registration business; and uploads the batch processing request for real estate registration business to the routing gateway; The routing gateway is used to distribute batch processing requests for real estate registration business based on a preset load balancing strategy, obtain the node task information of each execution node, and send the node task information of each execution node to the corresponding execution node. The node task information includes: several subtasks and the number of subtasks. Each execution node is used to repeatedly execute the real estate registration business task scheduling process for each subtask until all subtasks are traversed. The real estate registration business task scheduling process includes: real-time collection of node status data and sending the node status data and node task information to the multi-threaded task scheduler, so that the multi-threaded task scheduler can calculate the node availability capacity of the current execution node based on the node status data and node task information of the current execution node; receiving the node availability capacity of other execution nodes in the distributed multi-threaded scheduling system; calculating the total available capacity of the cluster based on the node availability capacity of each execution node and a preset node performance weight coefficient; calculating the task allocation amount of the current execution node based on the total number of subtasks, the node availability capacity of the current execution node, and the total available capacity of the cluster; the total number of subtasks is the sum of the number of subtasks in the batch processing request; and reallocating the subtasks of the current execution node according to the task allocation amount of the current execution node to obtain the subtasks to be executed by the current execution node. The multi-threaded task scheduler is any other execution node in the distributed multi-threaded scheduling system. Each execution node is also used to receive subtasks to be executed from the multi-threaded task scheduler; and to execute real estate registration business tasks based on the subtasks to be executed.

[0081] In a preferred embodiment, each execution node is further configured to verify the subtask to be executed based on a preset standardized verification rule engine; and to filter the subtask to be executed according to the verification results to obtain the filtered subtask to be executed.

[0082] It is understood that the above system item embodiments correspond to the method item embodiments of the present invention, and can implement the distributed multi-threaded scheduling method for real estate registration business provided by any of the above method item embodiments of the present invention.

[0083] It should be noted that the system embodiments described above are merely illustrative, and some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the system embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0084] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A distributed multi-threaded scheduling method for real estate registration business, characterized in that, Applicable to each execution node in a distributed multithreaded scheduling system; The distributed multi-threaded scheduling system also includes: several clients and routing gateways; The distributed multi-threaded scheduling method includes: Receive node task information sent by the routing gateway; the node task information includes: several subtasks and the number of subtasks; wherein, the node task information is obtained by the routing gateway distributing batch processing requests for real estate registration business initiated by each client based on a preset load balancing strategy; For each subtask, repeat the real estate registration business task scheduling process until all subtasks have been traversed: The real estate registration business task scheduling process includes: real-time collection of node status data, and sending the node status data and node task information to a multi-threaded task scheduler, so that the multi-threaded task scheduler can calculate the node availability capacity of the current execution node based on the node status data and node task information of the current execution node; receiving the node availability capacity of other execution nodes in the distributed multi-threaded scheduling system; calculating the total available capacity capacity of the cluster based on the node availability capacity of each execution node and a preset node performance weight coefficient; calculating the task allocation amount of the current execution node based on the total number of subtasks, the node availability capacity of the current execution node, and the total available capacity capacity of the cluster; the total number of subtasks is the sum of the number of subtasks in the batch processing request; and reallocating the subtasks of the current execution node according to the task allocation amount of the current execution node to obtain the subtasks to be executed by the current execution node; wherein, the multi-threaded task scheduler is any other execution node in the distributed multi-threaded scheduling system; Receive subtasks to be executed from the multi-threaded task scheduler; Based on the sub-tasks to be executed, perform real estate registration business tasks.

2. The distributed multi-threaded scheduling method for real estate registration business according to claim 1, characterized in that, The load balancing strategies include: round-robin strategy, connection number strategy, or random strategy; The method of distributing batch processing requests for real estate registration services initiated by each client based on a preset load balancing strategy includes: Based on a preset polling strategy, the batch processing requests for real estate registration services initiated by each client are distributed according to the order of the requests initiated by each client. Alternatively, based on a preset connection count strategy, the connection count of each execution node can be obtained, and the batch processing requests for real estate registration initiated by each client can be distributed in ascending order of connection count. Alternatively, based on a preset random strategy, batch processing requests for real estate registration initiated by each client can be randomly distributed.

3. The distributed multi-threaded scheduling method for real estate registration business according to claim 1, characterized in that, The node status data includes: CPU availability, memory availability, thread pool availability, task queue availability, and average time consumption of the previous task; the node task information also includes: the real estate registration business type corresponding to each subtask; The step of calculating the available capacity of the current execution node based on the node status data and node task information includes: The available capacity of the basic node is calculated based on the CPU availability, memory availability, thread pool availability, and task queue availability of the current execution node. Based on the real estate registration business type corresponding to each subtask contained in the current execution node, and the preset correspondence table, determine the business complexity correction coefficient; Based on the average time of the previous task and the preset average time of the baseline task, determine the time correction coefficient for the preceding task. Based on the business complexity correction factor and the preceding task time correction factor, the available capacity of the basic node is corrected to obtain the available capacity of the currently executing node.

4. The distributed multi-threaded scheduling method for real estate registration business according to claim 1, characterized in that, Real estate registration services include: initial registration, change registration, transfer registration, cancellation registration, correction registration, objection registration, preliminary registration, and seizure registration.

5. The distributed multi-threaded scheduling method for real estate registration business according to claim 1, characterized in that, The total available capacity of the cluster is calculated based on the node availability capacity of each execution node and the preset node performance weighting coefficient, including: Based on the preset node performance weight coefficients, the available capacity of each execution node is weighted and summed, and then divided by the sum of the node performance weight coefficients of all execution nodes to obtain the total available capacity of the cluster.

6. The distributed multi-threaded scheduling method for real estate registration business according to claim 1, characterized in that, Based on the total number of subtasks, the node availability rate of the current executing node, and the total cluster availability rate, calculate the task allocation for the current executing node, including: The total number of subtasks is allocated proportionally based on the proportion of the current execution node's available capacity to the total available capacity of the cluster, thus obtaining the task allocation amount for the current execution node.

7. The distributed multi-threaded scheduling method for real estate registration business according to claim 1, characterized in that, After receiving the subtasks to be executed from the multi-threaded task scheduler, the process also includes: Based on a pre-defined standardized verification rule engine, the subtask to be executed is verified; Based on the verification results, the subtasks to be executed are filtered to obtain the filtered subtasks to be executed.

8. The distributed multi-threaded scheduling method for real estate registration business according to claim 1, characterized in that, After executing the real estate registration business task based on the sub-tasks to be executed, the following also includes: The execution results of all subtasks to be executed in the same batch processing request are summarized and organized to obtain the execution result data; The execution result data is uploaded to the multi-threaded task scheduler so that the multi-threaded task scheduler can perform transaction consistency verification on the execution result data of all execution nodes. If the transaction consistency verification passes, the execution result data of all execution nodes is written to the real estate registration database in batches. If the transaction consistency verification fails, an entry failure signal is generated.

9. A distributed multi-threaded scheduling system for real estate registration business, characterized in that, include: Several clients, routing gateways, and several execution nodes; Each client is used to initiate batch processing requests for real estate registration services; Batch processing requests for real estate registration are uploaded to the routing gateway; The routing gateway is used to distribute batch processing requests for real estate registration business based on a preset load balancing strategy, and obtain the node task information of each execution node. The node task information of each execution node is sent to the corresponding execution node; the node task information includes: several subtasks and the number of subtasks; Each execution node is used to repeatedly execute the real estate registration business task scheduling process for each subtask until all subtasks are traversed. The real estate registration business task scheduling process includes: real-time collection of node status data and sending the node status data and node task information to the multi-threaded task scheduler, so that the multi-threaded task scheduler calculates the node availability capacity of the current execution node based on the node status data and node task information; receiving the node availability capacity of other execution nodes in the distributed multi-threaded scheduling system; and calculating the node availability capacity of each execution node based on the node availability capacity and a preset node performance weight coefficient. Calculate the total available capacity of the cluster; calculate the task allocation amount for the current execution node based on the total number of subtasks, the node available capacity of the current execution node, and the total available capacity of the cluster; the total number of subtasks is the sum of the number of subtasks in the batch processing request; reallocate the subtasks of the current execution node according to the task allocation amount of the current execution node to obtain the subtasks to be executed for the current execution node; wherein, the multi-threaded task scheduler is any other execution node in the distributed multi-threaded scheduling system; receive the subtasks to be executed issued by the multi-threaded task scheduler; and execute the real estate registration business task based on the subtasks to be executed.

10. The distributed multi-threaded scheduling system for real estate registration business according to claim 9, characterized in that, Each execution node is also used to verify the subtasks to be executed based on a preset standardized verification rule engine; and to filter the subtasks to be executed based on the verification results to obtain the filtered subtasks to be executed.