Asynchronous recalculation method, system and device of distributed billing and storage medium

Abstract

The application provides a distributed asynchronous recalculation method, system, device and storage medium for bills, which comprises the following steps: firstly, receiving a first deduction request of a first sub-hotel, querying a corresponding parent hotel, applying a distributed lock, inserting a first flow record, creating a first recalculation record containing a unique identifier, releasing the lock, triggering a first asynchronous full calculation to update the bill of the parent hotel; during the execution of the first asynchronous full calculation task, receiving a second deduction request of a second sub-hotel, querying the same parent hotel, applying a distributed lock, inserting a second flow record, querying an unfinished first recalculation record, interrupting the first asynchronous task according to the identifier, creating a second recalculation record, releasing the lock, triggering a second asynchronous full calculation, and updating the total amount of the bill of the parent hotel based on the two flow records. The application can solve the problems of concurrent bottleneck and resource waste caused by long-time lock holding in the prior art, and improve the high-concurrency and high-performance capabilities of the distributed accounting system.

Description

Technical Field

[0001] This invention relates to the field of billing settlement, and more specifically, to a method, system, device, and storage medium for asynchronous recalculation of distributed bills. Background Technology

[0002] In the hotel settlement systems of large online travel agencies (OTAs), the business model typically presents a complex hierarchical relationship. A parent hotel (or group hotel) may correspond to multiple subsidiary hotels (or individual hotels, franchised hotels). In the financial settlement process, multiple subsidiary hotels may share and use the same parent hotel's credit line or invoices for expense deduction and settlement. For example, marketing expenses, commissions, or other payables of multiple subsidiary hotels may all be deducted uniformly from the parent hotel's prepayment or credit account.

[0003] In this business scenario, the traditional billing process is as follows: When the first sub-hotel X1 initiates a deduction request of 100 yuan, the system first queries the parent hotel X to which the sub-hotel X1 belongs; then, in order to ensure data consistency and prevent concurrent conflicts, the system applies a distributed lock to the billing record of the parent hotel X; after successfully acquiring the lock, the system inserts a transaction record of -100 yuan into the billing details of the parent hotel X; next, the system needs to recalculate the total billing amount of the parent hotel X. This step usually requires scanning all historical transactions under the parent hotel for full aggregation, and the calculation process may involve a large amount of data and take a long time; finally, after the calculation is completed and the total amount is updated, the system releases the lock on the parent hotel X.

[0004] The aforementioned traditional processing methods have the following significant technical problems: (1) Excessive lock holding time: Since the time-consuming full computation is performed under a locked state, the holding time of the database lock or distributed lock is greatly extended. In the example above, the lock holding time is equal to the "time to insert the log record" plus the "time of full computation". When the full computation takes a long time, lock contention becomes very intense.

[0005] (2) Extremely poor concurrency performance: In large group scenarios, hundreds or thousands of subsidiary hotels may initiate deduction operations on their parent hotel almost simultaneously. When the first request holds the lock and performs a long calculation, subsequent requests to the same parent hotel will fail or get stuck in a long wait when trying to acquire the lock, resulting in request processing timeouts, severely degraded user experience, and extremely low system throughput.

[0006] (3) Severe waste of computing resources: Consider a typical concurrency scenario: Sub-hotel X1's request is performing a time-consuming full computation, and the lock has not yet been released. At this time, sub-hotel X2's request is waiting because it failed to acquire the lock. Once X1's request completes and releases the lock, X2's request immediately acquires the lock and performs the full computation again. This means that the computation that X1 just completed (whose result has become invalid after X2 inserts a new pipeline) is completely wasted. If there are a large number of requests in a short period of time, this invalid computation will increase exponentially, causing a huge waste of CPU and I / O resources.

[0007] (4) Data consistency risk: Although locking ensures short-term consistency, excessively long lock time may lead to more complex business anomalies, such as front-end retries due to request timeouts, which may introduce duplicate data and increase the difficulty of maintaining data consistency.

[0008] In existing technologies, optimizations for such problems typically focus on reducing lock granularity (e.g., locking only the relevant account instead of the entire parent hotel), optimizing lock strategies (e.g., using optimistic locking), or optimizing computational performance (e.g., incremental computation). However, these solutions do not fundamentally solve the core problem of "performing time-consuming calculations during lock holding." Reducing lock granularity is extremely difficult to implement in complex accounting systems and is prone to errors; while incremental computation can reduce computational load under ideal conditions, it still needs to degenerate into full computation when facing scenarios such as complex billing rules and historical data corrections, and cannot completely solve the problem of excessively long lock holding times.

[0009] In view of this, the present invention provides an asynchronous recalculation method, system, device and storage medium for distributed bills. Summary of the Invention

[0010] To address the problems in existing technologies, the present invention aims to provide an asynchronous recalculation method, system, device, and storage medium for distributed invoices. It overcomes the difficulties of existing technologies by removing time-consuming full calculations from the locking period and introducing an interrupt mechanism to manage expired calculation tasks. This completely solves the concurrency bottlenecks and resource waste caused by long-term lock holding in existing technologies, providing a high-performance and highly reliable solution for high-concurrency distributed accounting systems.

[0011] Embodiments of the present invention provide an asynchronous recalculation method for distributed billing, comprising the following steps: S101, Receive the first deduction request from the first sub-hotel; S102. Query the corresponding parent hotel based on the first sub-hotel; S103. Apply a distributed lock to the parent hotel; S104. Insert the first transaction record corresponding to the first deduction request into the bill of the parent hotel; S105. Create and store a first recalculation record corresponding to the first deduction request. The first recalculation record contains at least a first task identifier information for uniquely identifying this recalculation task. S106. Release the distributed lock applied to the parent hotel; S107. After unlocking, trigger the execution of the first asynchronous full calculation task corresponding to the first recalculation record to update the total bill amount of the parent hotel; S108. During the execution of the first asynchronous full calculation task, receive the second deduction request from the second sub-hotel; S109. Query the corresponding parent hotel based on the second sub-hotel; S110. Apply a distributed lock to the parent hotel; S111. Insert a second transaction record corresponding to the second deduction request into the bill of the parent hotel; S112. Based on the parent hotel, query the first recalculation record that is in an incomplete state, obtain its first task identification information, and send an interruption instruction to the first execution entity that is executing the first asynchronous full calculation task according to the first task identification information to interrupt the first asynchronous full calculation task. S113. Create and store a second recalculation record corresponding to the second deduction request. The second recalculation record contains at least a second task identifier information for uniquely identifying this recalculation task. S114. Release the distributed lock applied to the parent hotel; S115. After unlocking, trigger the execution of the second asynchronous full calculation task corresponding to the second recalculation record. The second asynchronous full calculation task performs a full calculation based on the first transaction record and the second transaction record to update the total bill amount of the parent hotel.

[0012] Preferably, the first task identification information and the second task identification information mentioned in steps S105 and S113 include the server IP address and thread ID of the server executing the steps.

[0013] Preferably, in step S112, sending an interrupt instruction to the first execution entity executing the first asynchronous full calculation task according to the first task identification information further includes: locating the target thread executing the first asynchronous full calculation task according to the server IP address and thread ID in the first recalculation record, and sending an interrupt signal to the target thread by calling the thread interrupt method.

[0014] Preferably, the asynchronous full computation task triggered in steps S107 and S115 is executed asynchronously through a message queue.

[0015] Preferably, the method further includes: setting a task status field in the recalculation record, wherein the task status includes pending execution, in execution, completed, and interrupted; before executing the asynchronous full calculation task, updating the status of the corresponding recalculation record to in execution; updating it to completed when the task is completed; and updating it to interrupted when an interruption command is received.

[0016] Preferably, the insertion of transaction records in steps S104 and S111, and the creation and storage of recalculation records in steps S105 and S113, are completed within the same database transaction.

[0017] Preferably, the asynchronous full computation task is idempotent, and when the task fails due to interruption or exception, the system supports retrying the task based on the corresponding recalculation record.

[0018] Embodiments of the present invention also provide an asynchronous recalculation system for distributed invoices, used to implement the above-described asynchronous recalculation method for distributed invoices, wherein the asynchronous recalculation system for distributed invoices includes: The first request module receives the first deduction request from the first sub-hotel. The first query module queries the corresponding parent hotel based on the first child hotel; The first locking module applies a distributed lock to the parent hotel; The first insertion module inserts a first transaction record corresponding to the first deduction request into the bill of the parent hotel; The first recalculation module creates and stores a first recalculation record corresponding to the first deduction request. The first recalculation record contains at least a first task identifier information used to uniquely identify this recalculation task. The first unlocking module releases the distributed lock applied to the parent hotel; After unlocking, the first update module triggers the execution of the first asynchronous full calculation task corresponding to the first recalculation record to update the total bill amount of the parent hotel; The second request module receives the second deduction request from the second sub-hotel during the execution of the first asynchronous full calculation task; The second query module queries the corresponding parent hotel based on the second sub-hotel; The second locking module applies a distributed lock to the parent hotel; The second insertion module inserts a second transaction record corresponding to the second deduction request into the bill of the parent hotel; The interrupt instruction module queries the first recalculation record that is in an incomplete state based on the parent hotel, obtains its first task identifier information, and sends an interrupt instruction to the first execution entity that is executing the first asynchronous full calculation task according to the first task identifier information, so as to interrupt the first asynchronous full calculation task. The second recalculation module creates and stores a second recalculation record corresponding to the second deduction request. The second recalculation record contains at least a second task identifier information used to uniquely identify this recalculation task. The second unlocking module releases the distributed lock applied to the parent hotel; After unlocking, the second update module triggers the execution of the second asynchronous full calculation task corresponding to the second recalculation record. The second asynchronous full calculation task performs a full calculation based on the first transaction record and the second transaction record to update the total bill amount of the parent hotel.

[0019] Embodiments of the present invention also provide an asynchronous recalculation device for distributed billing, comprising: processor; A memory in which executable instructions of the processor are stored; The processor is configured to execute the steps of the above-described asynchronous recalculation method for distributed billing by executing the executable instructions.

[0020] Embodiments of the present invention also provide a computer-readable storage medium for storing a program that, when executed, implements the steps of the above-described asynchronous recalculation method for distributed billing.

[0021] The purpose of this invention is to provide an asynchronous recalculation method, system, device, and storage medium for distributed invoices. By removing time-consuming full calculations from the locking period and introducing an interrupt mechanism to manage expired calculation tasks, this invention completely solves the concurrency bottleneck and resource waste problems caused by long-term lock holding in the prior art, providing a high-performance and highly reliable solution for high-concurrency distributed accounting systems. Attached Figure Description

[0022] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0023] Figure 1 This is a flowchart of the asynchronous recalculation method for distributed billing of the present invention.

[0024] Figure 2 This is a system architecture diagram of the asynchronous recalculation system for distributed billing of the present invention.

[0025] Figure 3This is a schematic diagram of the structure of the asynchronous recalculation device for distributed billing of the present invention.

[0026] Figure 4 This is a schematic diagram of the structure of a computer-readable storage medium according to an embodiment of the present invention. Detailed Implementation

[0027] The following specific examples illustrate the implementation methods of this application. Those skilled in the art can easily understand the other advantages and effects of this application from the content disclosed herein. This application can also be implemented or applied through other different specific embodiments, and various details in this application can be modified or changed according to different viewpoints and application systems without departing from the spirit of this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0028] The embodiments of this application will now be described in detail with reference to the accompanying drawings, so that those skilled in the art can easily implement the application. This application may be embodied in many different forms and is not limited to the embodiments described herein.

[0029] In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics represented in connection with that embodiment or example, which are included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics represented may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate different embodiments or examples represented in this application, as well as features of different embodiments or examples.

[0030] Furthermore, the terms "first" and "second" are used for illustrative purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the representation of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0031] For the purpose of clearly describing this application, devices that are not relevant to the description are omitted, and the same or similar components throughout the specification are given the same reference numerals.

[0032] Throughout this specification, when it is said that a device is "connected" to another device, this includes not only "direct connection" but also "indirect connection" by placing other components in between. Furthermore, when it is said that a device "comprises" a certain constituent element, unless otherwise stated otherwise, this does not exclude other constituent elements, but rather implies that other constituent elements may be included.

[0033] When we say that a device is "above" another device, this can mean that it is directly above the other device, or it can mean that other devices are present in between. Conversely, when we say that a device is "directly" "above" another device, there are no other devices present in between.

[0034] Although the terms first, second, etc., are used in some instances herein to refer to various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, first interface and second interface, etc., are used. Furthermore, as used herein, the singular forms “a,” “an,” and “the” are intended to also include the plural forms unless the context indicates otherwise. It should be further understood that the terms “comprising,” “including,” indicate the presence of features, steps, operations, elements, components, items, kinds, and / or groups, but do not exclude the presence, occurrence, or addition of one or more other features, steps, operations, elements, components, items, kinds, and / or groups. The terms “or” and “and / or” as used herein are interpreted as inclusive, or mean any one or any combination thereof. Thus, “A, B, or C” or “A, B, and / or C” means “any one of: A; B; C; A and B; A and C; B and C; A, B, and C.” Exceptions to this definition will only occur if the combination of elements, functions, steps, or operations is inherently mutually exclusive in some way.

[0035] The technical terms used herein are for reference only to specific embodiments and are not intended to limit the scope of this application. The singular form used herein includes the plural form unless the statement explicitly indicates otherwise. The word "comprising" as used in the specification means to specify a particular characteristic, region, integer, step, operation, element, and / or component, and does not exclude the presence or addition of other characteristics, regions, integers, steps, operations, elements, and / or components.

[0036] Although not explicitly defined, all terms, including technical and scientific terms used herein, shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. Terms defined in commonly used dictionaries shall be further interpreted as having a meaning consistent with the relevant technical literature and the content of this present application, and shall not be over-interpreted as having an ideal or overly formulaic meaning unless otherwise defined.

[0037] Figure 1This is a flowchart of the asynchronous recalculation method for distributed billing according to the present invention. Figure 1 As shown, the asynchronous recalculation method for distributed billing of the present invention includes the following steps: S101, Receive the first deduction request from the first sub-hotel.

[0038] S102. Query the corresponding parent hotel based on the first child hotel.

[0039] S103, Apply a distributed lock to the parent hotel.

[0040] S104. Insert the first transaction record corresponding to the first deduction request into the bill of the parent hotel.

[0041] S105. Create and store a first recalculation record corresponding to the first deduction request. The first recalculation record shall contain at least a first task identifier information used to uniquely identify this recalculation task.

[0042] S106. Release the distributed lock applied to the parent hotel.

[0043] S107. After unlocking, trigger the execution of the first asynchronous full calculation task corresponding to the first recalculation record to update the total bill amount of the parent hotel.

[0044] S108. During the execution of the first asynchronous full calculation task, receive the second deduction request from the second sub-hotel.

[0045] S109. Query the corresponding parent hotel based on the second sub-hotel.

[0046] S110, Apply a distributed lock to the parent hotel.

[0047] S111. Insert the second transaction record corresponding to the second deduction request into the parent hotel's bill.

[0048] S112. Based on the parent hotel, query the first recalculation record that is in an incomplete state, obtain its first task identifier information, and send an interrupt instruction to the first execution entity that is executing the first asynchronous full calculation task according to the first task identifier information to interrupt the first asynchronous full calculation task.

[0049] S113. Create and store a second recalculation record corresponding to the second deduction request. The second recalculation record shall contain at least a second task identifier information used to uniquely identify this recalculation task.

[0050] S114. Release the distributed lock applied to the parent hotel.

[0051] S115. After unlocking, trigger the execution of the second asynchronous full calculation task corresponding to the second recalculation record. The second asynchronous full calculation task performs a full calculation based on the first transaction record and the second transaction record to update the total bill amount of the parent hotel.

[0052] This invention cleverly solves the long-standing performance bottlenecks and resource waste problems in traditional distributed accounting systems through two core innovations: "asynchronous recalculation" and "interruption mechanism." It maintains the granularity of locks within a range that does not affect concurrency, while ensuring that computing resources are always used for the latest and most efficient tasks through interruption. Thus, while guaranteeing eventual data consistency, it achieves a double leap in system concurrency and resource utilization, making it particularly suitable for business scenarios with a large number of high-concurrency accounting operations, such as large accommodation business groups.

[0053] In a preferred embodiment, the first task identification information and the second task identification information in steps S105 and S113 include the server IP address and thread ID of the executing step. This embodiment defines the specific composition of the task identification information. When the system creates a recalculation record, it automatically captures and stores the server IP address of the currently processing request and the thread ID of the thread executing the operation. These two combine to form a globally unique identifier in a distributed environment, used to accurately locate a specific computing task that is running or waiting to be executed. This embodiment provides a technical basis for subsequent precise task interruption by refining the coarse-grained task identification into a combination of "server IP + thread ID". This allows interrupt commands to be positioned like "precision-guided missiles" directly to a specific thread on a specific server in the cluster, avoiding the resource waste and false interruption risks caused by broadcast interrupts, and improving the accuracy and efficiency of task management.

[0054] In a preferred embodiment, step S112, sending an interrupt instruction to the first execution entity executing the first asynchronous full computation task based on the first task identifier information, further includes: locating the target thread executing the first asynchronous full computation task based on the server IP address and thread ID in the first recalculation record, and sending an interrupt signal to the target thread by calling the thread interrupt method. This embodiment, based on the previous embodiment, specifies the execution method of the interrupt instruction. After the interrupt module obtains the target IP and thread ID, it notifies the thread management component on the target server through an internal communication mechanism (such as RPC) or shared memory. The component finds the corresponding running thread based on the thread ID and calls its interrupt() method to send an interrupt signal to the thread. This embodiment implements a "cooperative interrupt." It does not forcibly terminate the thread, but rather allows the target thread to stop itself at a predefined checkpoint by sending an interrupt signal and perform necessary resource cleanup work (such as closing database connections, rolling back transactions, etc.). This ensures data consistency and system stability, avoiding data corruption or resource leakage problems that may be caused by the violent termination of threads.

[0055] In a preferred embodiment, the asynchronous full computation task triggered in steps S107 and S115 is executed asynchronously via a message queue. This embodiment defines the triggering method for asynchronous tasks. After unlocking, the system does not directly call the full computation method, but instead encapsulates the key information required for the computation task (such as the parent hotel ID, recalculation record ID, etc.) into a message and sends it to a highly available message queue (such as Kafka, RabbitMQ). The backend computation service, acting as a consumer, pulls the message from the queue and performs the actual full computation. This embodiment introduces a message queue to achieve complete decoupling between the producer and consumer. On the one hand, the deduction request processing flow (producer) can return immediately after sending the message without waiting for the computation to complete, further improving the response speed. On the other hand, the message queue can serve as a huge "buffer pool" to smooth out sudden peaks in computation tasks. Even if the downstream computation service is temporarily unavailable, messages will not be lost, thereby greatly improving the resilience and reliability of the entire system.

[0056] In a preferred embodiment, the method further includes: setting a task status field in the recalculation record, where the task status includes pending execution, in execution, completed, and interrupted; updating the status of the corresponding recalculation record to in execution before executing the asynchronous full calculation task; updating it to completed when the task is completed; and updating it to interrupted when an interruption command is received. This embodiment introduces full lifecycle status management for the recalculation record. The system tracks the current status of each recalculation task through a status field. For example, when a task is first created, it is "pending execution," updated to "in execution" before calculation begins, completed normally, and interrupted by a subsequent request. The "querying recalculation records in an incomplete state" in step S112 relies on this status field, which typically refers to the "pending execution" or "in execution" status. The status management mechanism of this embodiment makes the entire asynchronous recalculation process transparent and controllable. It provides accurate judgment criteria for task interruption logic, preventing repeated interruptions or interruptions of completed tasks. At the same time, it provides key data for system monitoring, operation and maintenance, and troubleshooting, clearly showing the processing process and final result of each task. For example, by observing tasks that have been "running" for a long time, potential infinite loops or performance issues can be identified and addressed in a timely manner.

[0057] In a preferred embodiment, the insertion of transaction records in steps S104 and S111, and the creation and storage of recalculation records in steps S105 and S113, are completed within the same database transaction. This embodiment ensures the consistency of the two critical write operations through local database transactions. During the locking process of the deduction request, the system binds the operations of "inserting transaction records" and "creating corresponding recalculation records" within the same database transaction. Transactions are atomic; either all transactions are successfully committed, or all transactions fail and are rolled back. This fundamentally guarantees eventual data consistency. It ensures that every newly added transaction necessarily corresponds to an asynchronous recalculation task that needs to be executed, and conversely, any recalculation task must be generated because of a specific transaction change. This eliminates the risk of data inconsistency caused by system anomalies (such as power outages or service crashes), resulting in "transaction records without recalculation" (invoice amounts are always incorrect) or "recalculation without transaction records" (calculation out of thin air), providing the most basic guarantee for the correctness of the system.

[0058] In a preferred embodiment, the asynchronous full computation task is idempotent. When a task fails due to an interruption or exception, the system supports retrying the task based on the corresponding recalculation record. This embodiment ensures task recoverability. Idempotency means that whether a task is executed once, twice, or multiple times, its final impact on the system is the same. This is typically achieved using optimistic locking when updating the master invoice. When a task fails due to an interruption or system exception (status: "interrupted" or "pending execution" for a long time), a separate compensation or scheduling service periodically scans these unfinished recalculation records and re-triggers the corresponding asynchronous computation task. The combination of idempotency and the retry mechanism gives the system strong fault tolerance and self-healing capabilities. Even in the event of frequent high-concurrency interruptions or temporary failures of some computing nodes, all computation tasks that should be executed will ultimately be reliably completed, ensuring the final correctness of the accounting data. This greatly improves the system's robustness and ease of operation and maintenance, allowing recovery from various abnormal states without manual intervention.

[0059] First, combined Figure 1 The technical problems to be solved by the present invention will be described in detail. Figure 1 A flowchart of a traditional distributed billing method is shown. (For example...) Figure 1 As shown, the process begins when Sub-Hotel X1 initiates a request for a 100 RMB discount: Receive the deduction request for Sub-Hotel X1.

[0060] Find the parent hotel X corresponding to this sub-hotel.

[0061] Lock the parent hotel X. This is to prevent other requests from simultaneously modifying the parent hotel X's accounting data.

[0062] Insert transaction record, that is, add a transaction record with an amount of -100 yuan to the bill of the parent hotel X.

[0063] Perform a full calculation. This step requires reading all historical transaction records under the parent hotel X, re-aggregating them, and calculating the new total bill amount. This step is extremely time-consuming and may involve scanning tens of thousands of data entries and complex business logic calculations.

[0064] Unlock and release the lock on the mother hotel X.

[0065] from Figure 1As can be clearly seen, from the successful locking in step 103 to the unlocking in step 106, there are two time-consuming steps: step 104 (inserting the flow, which takes a short time) and step 105 (full computation, which takes a very long time). Therefore, the lock holding time is almost equal to the full computation time. During this long lock period, if the sub-hotel X2 also initiates a request for the same parent hotel X, it will fail when attempting to lock in step 103, causing the request to be blocked or fail directly, severely impacting the system's concurrent processing capabilities and user experience. Furthermore, if X2's request successfully acquires the lock after X1 unlocks and performs its own full computation, the full computation result just completed by X1 (excluding X2's flow) will be immediately invalidated, resulting in a complete waste of computational resources.

[0066] To address the aforementioned problems, this invention provides an innovative solution. Its core idea is to remove the time-consuming "full computation" operation from the locked scope and introduce an "interrupt mechanism" to manage any "expired computation tasks" that may result from this.

[0067] The following is combined with Figure 2 and Figure 3 The technical solution of the present invention will be described in detail below. Figure 2 The basic asynchronous recalculation process of the method of the present invention in a single request scenario is shown, while Figure 3 This demonstrates the optimized process of introducing an interrupt mechanism in high-concurrency scenarios.

[0068] Example 1: Basic Asynchronous Recalculation Scheme

[0069] like Figure 2 As shown in the figure, this embodiment describes the processing flow of the present invention when only one sub-hotel X1 initiates a request.

[0070] Step S201: The system receives the first deduction request initiated by the first sub-hotel (e.g., sub-hotel X1), requesting a deduction amount of 100 yuan.

[0071] Step S202: The system queries the parent hotel to which sub-hotel X1 belongs based on the preset hotel relationship mapping table, and records it as parent hotel X.

[0072] Step S203: The system attempts to apply a distributed lock to the parent hotel X. This can be achieved in various ways, such as a Redis-based distributed lock or a database row lock. The purpose of locking is to prevent other requests from simultaneously modifying the parent hotel X's basic accounting data (mainly transaction records) in subsequent steps.

[0073] Step S204: After successfully acquiring the lock, the system inserts a first transaction record corresponding to the first deduction request into the bill details table of the parent hotel X, recording the deduction amount as -100 yuan. This transaction record is the original voucher for the accounting change.

[0074] Step S205: This is one of the key innovative steps of the present invention. The system creates and stores a first recalculation record corresponding to the first deduction request. This record contains at least first task identification information that can uniquely identify this recalculation task, such as the server IP address that generated this recalculation task and the ID of the execution thread. In addition, the recalculation record may also contain fields such as parent hotel ID, request ID, and task status (e.g., "pending execution"). This record is equivalent to a "voucher" indicating that a full recalculation needs to be performed for parent hotel X to include the newly inserted transaction in the general ledger.

[0075] Step S206: After inserting the transaction record and recalculation record, the system immediately releases the distributed lock applied to the parent hotel X. At this point, the lock holding process for this request ends. Key point: From locking in step S203 to unlocking in step S206, only steps S204 (inserting the transaction record, quickly) and S205 (inserting the recalculation record, quickly) are executed, while the most time-consuming "full calculation" is completely removed from the lock's protected area. This reduces the lock holding time from "seconds or even hundreds of milliseconds" in traditional schemes to "milliseconds," greatly reducing the probability of lock conflicts.

[0076] Step S207: After the lock is released, the system triggers the execution of the first asynchronous full calculation task corresponding to the first recalculation record. This task can be a Runnable task submitted to the thread pool, or a message sent to a message queue (such as RabbitMQ or Kafka). This task is executed asynchronously in the background, and its content is: to read all valid transaction records of the parent hotel X (including the recently inserted -100 yuan transaction record), perform a full summary calculation, and finally write the calculated new total bill amount back to the parent hotel X's main bill record. Since this process is executed outside the lock, even if it takes a long time, it will not block any subsequent deduction requests for the parent hotel X.

[0077] As can be seen from Example 1, even if new requests arrive subsequently, they can quickly acquire the lock, complete their own pipeline insertion and recalculation record insertion, and immediately release the lock, without waiting for the lock for a long time because the full calculation of the previous request has not yet been completed. The system's concurrent processing capability is fundamentally improved. However, the process in Example 1 does not completely solve the problem of "wasted computing resources". Imagine that if the full calculation task of sub-hotel X1 (step S207) has not been completed, and a request from sub-hotel X2 arrives and completes its fast locking process, inserting new pipelines and recalculation records, then the full calculation being performed by X1 becomes invalid because it does not include X2's pipeline, which still results in wasted computing resources.

[0078] Example 2: Optimized scheme with interrupt mechanism (preferred implementation)

[0079] To address the aforementioned problem of resource waste, this invention introduces an innovative "interruption mechanism" based on Embodiment 1. Figure 3 A flowchart of this preferred embodiment is shown, which is a continuation of the flowchart of Embodiment 1, describing a scenario where a second request arrives and triggers an interruption before the asynchronous task of the first request has been completed.

[0080] Suppose that before step S207 (the first asynchronous full calculation task) of Example 1 is completed, the system receives a second deduction request from a second sub-hotel (e.g., sub-hotel X2), requesting a deduction of 90 yuan. At this time, the process is as follows: Figure 3 As shown: Step S301: The system receives the second deduction request from the second sub-hotel X2.

[0081] Step S302: Query the corresponding parent hotel based on child hotel X2. In this scenario, the query result is also the parent hotel X.

[0082] Step S303: The system attempts to apply a distributed lock to the parent hotel X. Since the lock was released in step S206 by the previous request (X1), the lock can be acquired immediately without any blocking.

[0083] Step S304: Inside the lock, the system inserts a second transaction record corresponding to the second deduction request into the bill of the parent hotel X, with an amount of -90 yuan.

[0084] Step S305: This is another core innovation of the invention—interrupting the preceding task. Before inserting its own recalculation record, the system queries whether there is a recalculation record associated with the parent hotel X that is in an "incomplete" state (e.g., "pending execution" or "in execution") based on the parent hotel X's identifier. At this point, it finds the first recalculation record. The system obtains the first task identifier information in this record (e.g., server IP 10.0.0.1 and thread ID 123). Then, the interrupt control module sends an interrupt command to the first execution entity executing the first asynchronous full computation task based on this identifier information. Specifically, this can be done by notifying the thread with thread ID 123 on the 10.0.0.1 server via a remote procedure call (RPC), or more simply, if the task supports checking the interrupt flag, it can be done by setting a globally shared interrupt flag (such as a key in Redis). The ultimate goal is to allow the first asynchronous full computation task to stop execution as early and gracefully as possible.

[0085] Step S306: After successfully sending an interrupt command or marking an interrupt, the system creates and stores a second recalculation record corresponding to the second deduction request. This new record contains second task identification information (such as the IP address of the current server and the ID of the current thread) to identify this new task.

[0086] Step S307: After all operations are completed, the system releases the distributed lock on the parent hotel X.

[0087] Step S308: Outside the lock, the system triggers the execution of the second asynchronous full calculation task corresponding to the second recalculation record. This new task, during the full calculation, reads all transaction records under the parent hotel X, including the first transaction record (-100 yuan) and the second transaction record (-90 yuan). Therefore, it will correctly calculate the new total bill amount (original amount Y -100 - 90) and update the main bill. Since the first task has been interrupted, no old task will overwrite this correct result.

[0088] By introducing an interrupt mechanism, this invention achieves the ideal effect of "whoever is latest calculates, and calculates only once." Subsequent interrupt requests ensure that all incomplete or outdated computational tasks are terminated in a timely manner, thereby completely avoiding the waste of CPU, memory, and database I / O caused by invalid computations.

[0089] Compared with the prior art, the technical solution proposed in this invention has the following significant advantages: It achieves a high degree of automation, greatly improving operational efficiency. The complex troubleshooting and repair process, which originally required specialized knowledge and multiple steps, has been simplified into a "one-click run" or a fully automated background process. Ordinary users can resolve common DNS-related issues without needing to understand network details, significantly lowering the technical barrier and manual intervention costs, and enabling fault recovery within minutes or even seconds.

[0090] The detection mechanism is scientific, comprehensive, and accurate. By combining network layer (ICMP Ping) and application layer (TCP / HTTP) detection, it overcomes the limitations of single-protocol detection (such as false positives caused by ICMP being blocked by firewalls). Enhanced Ping (multi-packet) improves the accuracy of basic network quality parameters (packet loss rate, latency) measurements. The multi-dimensional comprehensive evaluation model (threshold grading, weighted calculation) can more scientifically and comprehensively reflect the true health status of the network, avoiding arbitrary judgments based on a single indicator.

[0091] The repair strategy is flexible, intelligent, and effective. The introduction of a "tiered DNS strategy" and a log-based "state persistence" mechanism enables the system to remember and perform hierarchical attempts. It does not give up after the first failed switch, nor does it blindly loop between several DNS addresses. Instead, it attempts according to a preset priority order and records the attempt status in the log, thereby improving the final success rate of the repair.

[0092] It possesses excellent observability and traceability. The system automatically generates detailed reports containing rich information, such as egress IP, carrier information, raw detection data for each domain name, calculated score level, specific reasons for triggering the switchover, executed switchover actions, and verification results. These logs provide valuable data support for subsequent network quality trend analysis, root cause location of faults, and strategy optimization.

[0093] It has a wide range of applications and flexible deployment. The method and system of this invention mainly run on user terminals (such as Windows PCs) without changing existing network infrastructure (such as routers and firewalls). It can be deployed as a standalone operation and maintenance tool or integrated into a unified enterprise operation and maintenance management platform to quickly improve the network experience of end users.

[0094] Figure 2 This is a system architecture diagram of the browser connector service in the asynchronous recalculation system of distributed billing of the present invention. Figure 2 As shown, the asynchronous recalculation system 5 for distributed billing of the present invention includes: The first request module 501 receives the first deduction request from the first sub-hotel; The first query module 502 queries the corresponding parent hotel based on the first child hotel; The first locking module 503 applies a distributed lock to the parent hotel; The first insertion module 504 inserts a first transaction record corresponding to the first deduction request into the bill of the parent hotel; The first recalculation module 505 creates and stores a first recalculation record corresponding to the first deduction request. The first recalculation record contains at least a first task identifier information used to uniquely identify this recalculation task. The first unlocking module 506 releases the distributed lock applied to the parent hotel; After unlocking, the first update module 507 triggers the execution of the first asynchronous full calculation task corresponding to the first recalculation record to update the total bill amount of the parent hotel. The second request module 508 receives the second deduction request from the second sub-hotel during the execution of the first asynchronous full calculation task; The second query module 509 queries the corresponding parent hotel based on the second sub-hotel; The second locking module 510 applies a distributed lock to the parent hotel; The second insertion module 511 inserts a second transaction record corresponding to the second deduction request into the bill of the parent hotel; The interrupt instruction module 512, based on the parent hotel, queries the first recalculation record that is in an incomplete state, obtains its first task identifier information, and sends an interrupt instruction to the first execution entity that executes the first asynchronous full calculation task according to the first task identifier information, so as to interrupt the first asynchronous full calculation task. The second recalculation module 513 creates and stores a second recalculation record corresponding to the second deduction request. The second recalculation record contains at least a second task identifier information used to uniquely identify this recalculation task. The second unlocking module 514 releases the distributed lock applied to the parent hotel; After unlocking, the second update module 515 triggers the execution of a second asynchronous full calculation task corresponding to the second recalculation record. The second asynchronous full calculation task performs a full calculation based on the first transaction record and the second transaction record to update the total bill amount of the parent hotel.

[0095] These modules work together to form a complete, high-performance distributed accounting processing loop.

[0096] In summary, the asynchronous recalculation system for distributed billing of the present invention can completely solve the concurrency bottleneck and resource waste problems caused by long-term lock holding in the prior art by removing the time-consuming full calculation from the locking period and introducing an interrupt mechanism to manage expired calculation tasks, thus providing a high-performance and high-reliability solution for high-concurrency distributed accounting systems.

[0097] This invention also provides an asynchronous recalculation device for distributed invoices, including a processor and a memory storing executable instructions for the processor. The processor is configured to execute steps of an asynchronous recalculation method for distributed invoices via the executable instructions.

[0098] As shown above, the asynchronous recalculation device for distributed billing of this invention in this embodiment can completely solve the concurrency bottleneck and resource waste problems caused by long-term lock holding in the prior art by removing the time-consuming full calculation from the locking period and introducing an interrupt mechanism to manage expired calculation tasks, thereby providing a high-performance and high-reliability solution for high-concurrency distributed accounting systems.

[0099] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "platform."

[0100] Figure 3 This is a schematic diagram of the asynchronous recalculation device for distributed billing of the present invention. See below for reference. Figure 3 To describe an electronic device 600 according to this embodiment of the present invention. Figure 3 The electronic device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0101] like Figure 3 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different platform components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0102] The storage unit stores program code, which can be executed by the processing unit 610 to perform the steps described in the method section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 610 can perform actions such as... Figure 1 The steps are shown in the figure.

[0103] Storage unit 620 may include readable media in the form of volatile storage units, such as random access memory (RAM) 6201 and / or cache memory 6202, and may further include read-only memory (ROM) 6203.

[0104] Storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0105] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the multiple bus structures.

[0106] Electronic device 600 can also communicate with one or more external devices 700 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage platforms.

[0107] This invention also provides a computer-readable storage medium for storing a program, which, when executed, implements the steps of an asynchronous recalculation method for distributed billing. In some possible implementations, various aspects of the invention can also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the above-described method section of this specification according to various exemplary embodiments of the invention.

[0108] As shown above, the asynchronous recalculation system for distributed billing of this invention in this embodiment can completely solve the concurrency bottleneck and resource waste problems caused by long-term lock holding in the prior art by removing the time-consuming full calculation from the locking period and introducing an interrupt mechanism to manage expired calculation tasks, thereby providing a high-performance and high-reliability solution for high-concurrency distributed accounting systems.

[0109] Figure 4 This is a schematic diagram of the structure of the computer-readable storage medium of the present invention. (Reference) Figure 4 As shown, a program product 800 for implementing the above-described method according to an embodiment of the present invention is described. It may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0110] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0111] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0112] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0113] In summary, the purpose of this invention is to provide an asynchronous recalculation method, system, device, and storage medium for distributed invoices. By removing time-consuming full calculations from the locking period and introducing an interrupt mechanism to manage expired calculation tasks, this invention completely solves the concurrency bottlenecks and resource waste caused by long-term lock holding in the prior art, providing a high-performance and highly reliable solution for high-concurrency distributed accounting systems.

[0114] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. An asynchronous recalculation method for distributed invoices, characterized in that, Includes the following steps: S101, Receive the first deduction request from the first sub-hotel; S102. Query the corresponding parent hotel based on the first sub-hotel; S103. Apply a distributed lock to the parent hotel; S104. Insert the first transaction record corresponding to the first deduction request into the bill of the parent hotel; S105. Create and store a first recalculation record corresponding to the first deduction request. The first recalculation record contains at least a first task identifier information for uniquely identifying this recalculation task. S106. Release the distributed lock applied to the parent hotel; S107. After unlocking, trigger the execution of the first asynchronous full calculation task corresponding to the first recalculation record to update the total bill amount of the parent hotel; S108. During the execution of the first asynchronous full calculation task, receive the second deduction request from the second sub-hotel; S109. Query the corresponding parent hotel based on the second sub-hotel; S110. Apply a distributed lock to the parent hotel; S111. Insert a second transaction record corresponding to the second deduction request into the bill of the parent hotel; S112. Based on the parent hotel, query the first recalculation record that is in an incomplete state, obtain its first task identification information, and send an interruption instruction to the first execution entity that is executing the first asynchronous full calculation task according to the first task identification information to interrupt the first asynchronous full calculation task. S113. Create and store a second recalculation record corresponding to the second deduction request. The second recalculation record contains at least a second task identifier information for uniquely identifying this recalculation task. S114. Release the distributed lock applied to the parent hotel; S115. After unlocking, trigger the execution of the second asynchronous full calculation task corresponding to the second recalculation record. The second asynchronous full calculation task performs a full calculation based on the first transaction record and the second transaction record to update the total bill amount of the parent hotel.

2. The asynchronous recalculation method for distributed billing according to claim 1, characterized in that, The first task identification information and the second task identification information mentioned in steps S105 and S113 include the server IP address and thread ID of the server executing the steps.

3. The asynchronous recalculation method for distributed billing according to claim 2, characterized in that, In step S112, sending an interrupt instruction to the first execution entity executing the first asynchronous full calculation task according to the first task identification information further includes: locating the target thread executing the first asynchronous full calculation task according to the server IP address and thread ID in the first recalculation record, and sending an interrupt signal to the target thread by calling the thread interrupt method.

4. The asynchronous recalculation method for distributed billing according to claim 1, characterized in that, The asynchronous full computation tasks triggered in steps S107 and S115 are executed asynchronously through a message queue.

5. The asynchronous recalculation method for distributed billing according to claim 1, characterized in that, Also includes: In the recalculation record, a task status field is set, and the task status includes pending execution, in execution, completed, and interrupted. Before executing the asynchronous full computation task, the status of the corresponding recalculation record is updated to "in progress"; when the task is completed, it is updated to "completed"; when an interrupt command is received, it is updated to "interrupted".

6. The asynchronous recalculation method for distributed billing according to claim 1, characterized in that, The insertion of transaction records in steps S104 and S111, and the creation and storage of recalculation records in steps S105 and S113, are completed within the same database transaction.

7. The asynchronous recalculation method for distributed billing according to claim 1, characterized in that, The asynchronous full computation task is idempotent. When the task fails due to interruption or exception, the system supports retrying the task based on the corresponding recalculation record.

8. An asynchronous recalculation system for distributed invoices, used to implement the asynchronous recalculation method for distributed invoices as described in claim 1, characterized in that, include: The first request module receives the first deduction request from the first sub-hotel. The first query module queries the corresponding parent hotel based on the first child hotel; The first locking module applies a distributed lock to the parent hotel; The first insertion module inserts a first transaction record corresponding to the first deduction request into the bill of the parent hotel; The first recalculation module creates and stores a first recalculation record corresponding to the first deduction request. The first recalculation record contains at least a first task identifier information used to uniquely identify this recalculation task. The first unlocking module releases the distributed lock applied to the parent hotel; After unlocking, the first update module triggers the execution of the first asynchronous full calculation task corresponding to the first recalculation record to update the total bill amount of the parent hotel; The second request module receives the second deduction request from the second sub-hotel during the execution of the first asynchronous full calculation task; The second query module queries the corresponding parent hotel based on the second sub-hotel; The second locking module applies a distributed lock to the parent hotel; The second insertion module inserts a second transaction record corresponding to the second deduction request into the bill of the parent hotel; The interrupt instruction module queries the first recalculation record that is in an incomplete state based on the parent hotel, obtains its first task identifier information, and sends an interrupt instruction to the first execution entity that is executing the first asynchronous full calculation task according to the first task identifier information, so as to interrupt the first asynchronous full calculation task. The second recalculation module creates and stores a second recalculation record corresponding to the second deduction request. The second recalculation record contains at least a second task identifier information used to uniquely identify this recalculation task. The second unlocking module releases the distributed lock applied to the parent hotel; After unlocking, the second update module triggers the execution of the second asynchronous full calculation task corresponding to the second recalculation record. The second asynchronous full calculation task performs a full calculation based on the first transaction record and the second transaction record to update the total bill amount of the parent hotel.

9. An asynchronous recalculation device for distributed billing, characterized in that, include: processor; A memory in which executable instructions of the processor are stored; The processor is configured to perform the steps of the asynchronous recalculation method for distributed billing according to any one of claims 1 to 7 by executing the executable instructions.

10. A computer-readable storage medium for storing a program, characterized in that, When the program is executed by the processor, it implements the steps of the asynchronous recalculation method for distributed billing as described in any one of claims 1 to 7.

Images