Ride-hailing distributed ledger processing method and apparatus, electronic device, and storage medium

Abstract

The application relates to the technical field of online car hailing, and discloses an online car hailing distributed account processing method and device, an electronic device and a storage medium, wherein, in response to an online car hailing account processing request, a globally unique identifier corresponding to the online car hailing account processing request is generated, a distributed lock is acquired based on the globally unique identifier, and a database transaction is started after the distributed lock is successfully acquired; in the database transaction, an active account voucher and a plurality of sub-active account vouchers are created according to the online car hailing account processing request; an account state corresponding to subject information is processed according to the type of the sub-active account voucher to obtain an account processing result, an asynchronous notification message corresponding to the account processing result is generated, the database transaction is submitted and the distributed lock is released, and the account processing result is pushed to a target business account based on the asynchronous notification message; the application avoids the problem of repeated account entry, solves the problem of data consistency between active account processing and subsequent operations, and realizes complete tracing from overall business to details of each party.

Description

Technical Field

[0001] This invention relates to the field of ride-hailing technology, specifically to a distributed accounting method, apparatus, electronic device, and storage medium for ride-hailing services. Background Technology

[0002] With the rapid development of the platform economy, the ride-hailing industry has evolved from a single point-to-point travel service into a comprehensive travel service platform encompassing multiple business lines such as ride-hailing, freight, chauffeur services, and carpooling. Simultaneously, ride-hailing platforms generally adopt a Software as a Service (SaaS) model, providing standardized dispatching, settlement, and account management services to small and medium-sized travel companies. Under this model, the platform needs to support multi-tenant, multi-entity, multi-scenario, and high-frequency fund settlement and accounting. Therefore, how to build an efficient, reliable, and scalable accounting system has become one of the core technological challenges of ride-hailing SaaS platforms.

[0003] For ride-hailing service accounting needs, a common technical approach is to separate the business system from the accounting module. The business system performs the clearing and calculation, then pushes the results to the independent accounting module for posting and balance updates. The accounting processing results are then sent directly to downstream systems via a message queue. However, this approach has the following problems in practical applications: accounting requests are prone to being processed repeatedly due to network retries in high-concurrency scenarios; there is a lack of unified transaction management between accounting processing and subsequent accounting, notification, and other operations, making it difficult to guarantee data consistency when any link fails; furthermore, a single ride-hailing service transaction often involves multiple parties, and the lack of a mandatory link between the overall transaction and the detailed accounts of each party makes it difficult to achieve complete traceability from business documents to the details of each party.

[0004] Therefore, there is an urgent need for a ride-hailing accounting method to prevent duplicate processing of accounting requests, ensure transactional consistency of accounting data, and enable the correlation and traceability of master and sub-accounts. Summary of the Invention

[0005] This invention provides a distributed accounting processing method, apparatus, electronic device, and storage medium for ride-hailing services to solve at least one problem existing in related technologies.

[0006] In a first aspect, the present invention provides a distributed accounting processing method for ride-hailing services, the method comprising the following steps: In response to a ride-hailing billing request, a globally unique identifier corresponding to the ride-hailing billing request is generated, wherein the ride-hailing billing request includes at least subject information; A distributed lock is acquired based on the globally unique identifier, and a database transaction is started after the distributed lock is successfully acquired. The distributed lock is used to prevent the same ride-hailing billing processing request from being processed repeatedly. In the database transaction, an active accounting voucher and several sub-accounting vouchers are created according to the ride-hailing accounting processing request. The account status corresponding to the main information is processed according to the type of the sub-accounting vouchers to obtain the accounting processing result, and an asynchronous notification message corresponding to the accounting processing result is generated. The association between the active accounting voucher and each sub-accounting voucher is established based on the globally unique identifier. Submit the database transaction and release the distributed lock; The accounting processing result is pushed to the target business account based on the asynchronous notification message.

[0007] This invention ensures that the same accounting request is processed only once in the entire distributed system by generating a globally unique identifier and combining it with a distributed lock, thus avoiding duplicate accounting problems caused by network retries or duplicate message consumption. By completing the creation of active accounting vouchers, sub-active accounting vouchers, account status updates, and asynchronous notification message generation within the same database transaction, it guarantees that these operations either all succeed or all roll back, solving the data consistency problem between accounting processing and subsequent operations. By establishing the association between active accounting vouchers and sub-active accounting vouchers based on the globally unique identifier, it achieves complete traceability from the overall business to the details of each party.

[0008] In one optional implementation, the active account voucher is used to record the total amount and business type of the business corresponding to the ride-hailing accounting request; the sub-active account voucher is used to record the details of fund changes or virtual value changes of each entity in the ride-hailing accounting request.

[0009] This invention records the total amount and type of a business transaction through active ledger vouchers, and records the details of fund changes or virtual value changes of each entity through sub-led ledger vouchers. This makes the overall information of a business transaction and the detailed information of each participant clearly separated at the data structure level, which facilitates subsequent reconciliation, auditing and problem investigation.

[0010] In one optional implementation, after creating an active accounting voucher and several sub-accounting vouchers corresponding to the ride-hailing billing request, the method further includes: Based on the globally unique identifier, the active account voucher and several sub-account vouchers are stored in separate tables to ensure the association between the active account voucher and each of the sub-account vouchers.

[0011] This invention uses globally unique identifiers to store active account vouchers and sub-active account vouchers in separate tables. While ensuring that the relationship between the two is not lost, the data is distributed to different physical storage locations, reducing the amount of data in a single table, improving read and write performance in large-scale concurrent scenarios, and avoiding query delays caused by excessively large single tables.

[0012] In conjunction with the first aspect or its corresponding implementation method, in one implementation method, the type of the sub-account entry voucher includes at least information flow account, escrow fund account, and non-escrow fund account, and the step of updating the account status according to the type of the sub-account entry voucher specifically includes: If the type of the sub-account voucher is the information flow account, then update the main virtual account in the main information and generate account transaction information; If the type of the sub-accounting voucher is the escrow fund transaction, then a real fund transfer request is initiated, and after the fund transfer is successful, the distributed lock is obtained again through the callback interface to process the fund transfer result, so as to prevent repeated requests to the callback interface after the fund transfer is successful. If the type of the sub-accounting voucher is the non-escrow fund transaction, then the payee bank information corresponding to the ride-hailing accounting processing request is recorded, and the payee bank information is handed over to the background task to process the fund transfer request.

[0013] This invention subdivides sub-account vouchers into three types: information flow accounts, escrow fund accounts, and non-escrow fund accounts, and defines processing methods for each type. Information flow accounts only update the virtual account balance without triggering real fund transfers, avoiding misjudging virtual income as real payments. Escrow fund accounts acquire the distributed lock again through a callback interface, preventing callback requests from being processed repeatedly after successful fund transfers. Non-escrow fund accounts entrust the payee's bank information to background tasks for processing, avoiding blocking and waiting for real-time transfers. The differentiation and processing of these three types together achieve accurate separation of information flow and fund flow.

[0014] In conjunction with the first aspect or its corresponding implementation method, in one implementation method, the information flow ledger is used to affect the virtual cash balance of the virtual account of the subject in the subject information, without triggering real fund transfers; the escrow fund flow ledger is used for real fund transfers between escrow accounts; and the non-escrow fund flow ledger is used for fund transfers between platform accounts and external bank accounts or third-party payment accounts.

[0015] This invention further defines the essential differences between the three types of transaction flows: information flow flows only affect virtual cash balances and do not involve real funds; escrow fund flows occur between escrow accounts and are controllable by the platform; non-escrow fund flows involve external banks or third-party payment accounts, with more uncontrollable factors. This limitation allows for different fault tolerance strategies to be adopted at the design level based on different types.

[0016] In an optional implementation, the ride-hailing billing request further includes a business type and a business event type; after obtaining the billing result by updating the account status according to the type of the sub-accounting voucher, it further includes: Based on the business type, the business event type, and the subject information, the accounting scenario configuration is searched, a double-entry bookkeeping entry matching the accounting scenario configuration is generated, and the double-entry bookkeeping entry is written into the accounting voucher table.

[0017] This invention finds the corresponding accounting scenario configuration and generates double-entry bookkeeping entries, realizing the mapping from business events to accounting vouchers. It eliminates the need for manual maintenance of the mapping relationship between business scenarios and accounting subjects, and avoids the problem of discrepancies between accounts and actual records caused by manual configuration errors.

[0018] In conjunction with the first aspect or its corresponding implementation, in one implementation, generating double-entry bookkeeping entries that match the bookkeeping scenario configuration specifically includes: The debit and credit accounts, as well as the lending and borrowing amounts between the debit and credit accounts, are determined based on the accounting scenario configuration.

[0019] This invention automatically determines the debit and credit accounts and the debit and credit amounts based on the accounting scenario, ensuring that each accounting transaction can automatically generate debit and credit entries that comply with accounting standards, thus avoiding the debit and credit imbalance problem caused by manual entry or configuration errors in traditional solutions.

[0020] Secondly, the present invention provides a distributed accounting processing device for ride-hailing services, the device comprising: The request-response module is used to respond to a ride-hailing billing processing request and generate a globally unique identifier corresponding to the ride-hailing billing processing request, wherein the ride-hailing billing processing request includes at least subject information; The transaction initiation module is used to acquire a distributed lock based on the globally unique identifier, and to initiate a database transaction after the distributed lock is successfully acquired. The distributed lock is used to prevent the same ride-hailing billing processing request from being processed repeatedly. The transaction processing module is used to create an active account voucher and several sub-active account vouchers according to the ride-hailing accounting processing request in the database transaction, process the account status corresponding to the main information according to the type of the sub-active account vouchers to obtain the accounting processing result, and generate an asynchronous notification message corresponding to the accounting processing result. The association between the active account voucher and each sub-active account voucher is established based on the globally unique identifier. The transaction commit module is used to commit the database transaction and release the distributed lock; The message push module is used to push the accounting processing results to the target business account based on the asynchronous notification message.

[0021] Thirdly, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the ride-hailing distributed accounting processing method described in the first aspect or any corresponding embodiment.

[0022] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the ride-hailing distributed accounting method described in the first aspect or any corresponding embodiment thereof.

[0023] Fifthly, the present invention provides a computer program product, including computer instructions, which are used to cause a computer to execute the ride-hailing distributed accounting method described in the first aspect or any corresponding embodiment. Attached Figure Description

[0024] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0025] Figure 1 This is a schematic diagram of an application scenario according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the distributed accounting method for ride-hailing services according to an embodiment of the present invention. Figure 3 This is an activity diagram of the accounting processing request flow according to an embodiment of the present invention; Figure 4 This is a structural block diagram of a distributed accounting device for ride-hailing services according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, 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.

[0027] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0028] 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. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0029] As an optional application scenario of this invention, such as Figure 1 As shown, application 101 is installed in terminal device 110, and user 130 can interact with application 101 through terminal device 110 and / or access device of terminal device 110.

[0030] For example, application 101 can be any application that provides question-and-answer related services. For instance, application 101 could be a question-and-answer interactive application, such as a text-to-text application, an image-to-text application, etc. Figure 1 In the application scenario shown, if application 101 is active, the terminal device 110 can display the interface 102 of application 101. The interface 102 may include various pages that application 101 can provide, such as interactive pages, settings pages, query pages, etc.

[0031] In some embodiments, terminal device 110 is communicatively connected to server 120 to provide services to application 101. Terminal device 110 may be a mobile terminal, fixed terminal, or portable terminal, etc., including but not limited to mobile phones, desktop computers, laptop computers, multimedia tablets, e-book devices, gaming devices, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. In some embodiments, terminal device 110 may also support any type of interface, and server 120 may be various types of computing systems or servers capable of providing computing power, including but not limited to mainframes, edge computing nodes, computing devices in cloud environments, etc.

[0032] It should be noted that, Figure 1 This is merely an example of an application scenario and does not limit the scope of protection of this invention.

[0033] The embodiments of the present invention will now be described with reference to the accompanying drawings. It should be understood that the pages shown in the drawings are merely examples, and various page designs are possible in practice. The various graphic elements on the page may have different arrangements and different visual representations; one or more elements may be omitted or replaced, and one or more other elements may also be present, without any limitation in the embodiments of the present invention. Furthermore, the embodiments described below primarily pertain to terminal device 110. It should be understood that the actions described relative to terminal device 110 can be performed by application 101 on terminal device 110, or can be performed by application 101 in conjunction with its server (e.g., server 120).

[0034] According to an embodiment of the present invention, an embodiment of a distributed accounting method for ride-hailing services is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] This embodiment provides a distributed accounting method for ride-hailing services, which can be used on the aforementioned mobile terminals, such as mobile phones and tablets. Figure 2 This is a flowchart of a distributed accounting method for ride-hailing services according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps: Step S201: In response to the ride-hailing billing request, generate a globally unique identifier corresponding to the ride-hailing billing request, wherein the ride-hailing billing request includes at least subject information.

[0036] Step S202: Obtain a distributed lock based on a globally unique identifier, and start a database transaction after successfully acquiring the distributed lock. The distributed lock is used to prevent the same ride-hailing billing processing request from being processed repeatedly. Step S203: In the database transaction, an active account voucher and several sub-active account vouchers are created according to the ride-hailing accounting processing request. The accounting processing result is obtained according to the account status corresponding to the processing subject information based on the type of the sub-active account voucher, and an asynchronous notification message corresponding to the accounting processing result is generated. The association between the active account voucher and each sub-active account voucher is established based on a globally unique identifier. Step S204: Commit the database transaction and release the distributed lock; Step S205: Push the accounting processing results to the target business account based on asynchronous notification messages.

[0037] The distributed accounting processing method for ride-hailing services provided in this invention ensures that the same accounting processing request is processed only once in the entire distributed system by generating a globally unique identifier and combining it with a distributed lock, thus avoiding duplicate accounting problems caused by network retries or duplicate message consumption. By completing the creation of active accounting vouchers, sub-active accounting vouchers, account status updates, and asynchronous notification message generation within the same database transaction, it ensures that these operations either all succeed or all roll back, solving the data consistency problem between accounting processing and subsequent operations. By establishing the association between active accounting vouchers and sub-active accounting vouchers based on the globally unique identifier, complete traceability from the overall business to the details of each party is achieved.

[0038] The steps described above will be explained in detail below.

[0039] In step S201, in response to the ride-hailing billing processing request, a globally unique identifier corresponding to the ride-hailing billing processing request is generated, wherein the ride-hailing billing processing request includes at least subject information.

[0040] In this context, a ride-hailing accounting request refers to an account movement protocol issued by the clearing and settlement system within a ride-hailing SaaS platform. This request triggers one or more changes in financial or virtual value transactions. Entity information refers to the identifier of the economic entity participating in this accounting process, including entity type and unique identifier, such as the platform, driver, passenger, or channel partner. A globally unique identifier is a string that uniquely identifies an accounting request within the entire distributed environment; this identifier is used for subsequent lock control, voucher association, and data traceability.

[0041] Specifically, after the ride-hailing SaaS platform's clearing and settlement system completes order clearing, it sends a ride-hailing accounting request to the accounting system. In one embodiment of this invention, upon receiving the accounting request, a globally unique identifier is assigned to the request, and the principal information carried in the request is extracted for use in subsequent steps. This globally unique identifier is used throughout the entire accounting process; subsequent distributed lock acquisition, association of active and sub-active accounting vouchers, and table partitioning all rely on this identifier. The ride-hailing accounting request must contain principal information because this information determines which participants' account statuses need to be updated.

[0042] Taking a ride-hailing order settlement as an example, after a passenger pays 50 yuan to complete an order, the clearing and settlement system calculates that the platform takes a 10 yuan commission and the driver receives 40 yuan. At this point, the clearing and settlement system sends a ride-hailing accounting processing request. The main information carried in this request includes the platform identifier PLAT_001 and the driver identifier DRV_888. After receiving the ride-hailing accounting processing request from the clearing and settlement system, a globally unique identifier is generated based on the request content, such as ORDER_20251226_001. This identifier is unique throughout the distributed environment; even if tens of thousands of ride-hailing accounting processing requests flood in at the same time, each request will obtain a different globally unique identifier.

[0043] By generating a globally unique identifier for each ride-hailing accounting request, a basic identifier is provided for subsequent anti-duplicate processing, master-sub-document association, and data traceability. The generation of this identifier enables the entire distributed accounting method to distinguish between different requests, creating the prerequisite for implementing distributed lock anti-duplicate and master-sub-document association.

[0044] In step S202, a distributed lock is acquired based on a globally unique identifier, and a database transaction is started after the distributed lock is successfully acquired. The distributed lock is used to prevent the same ride-hailing billing processing request from being processed repeatedly.

[0045] Distributed locks are resource access coordination mechanisms across multiple service instances, ensuring that only one processing thread can hold a lock based on a specific identifier at any given time. Acquiring a distributed lock involves sending a request to the distributed lock service using a globally unique identifier as the lock identifier. A successful return indicates that the current request has obtained exclusive processing rights to the resource corresponding to that identifier. A database transaction refers to a group of database operations bound together into an indivisible execution unit. The operations within this unit either all succeed and are committed or all fail and are rolled back. Starting a database transaction means issuing a transaction start instruction to the database; thereafter, all database operations executed within this transaction are within the same atomic unit.

[0046] In one embodiment of this invention, a globally unique identifier is first used as the lock key to request a lock from a Redis-based distributed lock service. If the acquisition fails, it indicates that the same ride-hailing billing processing request is being processed by other nodes, and the current request should choose to wait for a retry or abandon it directly according to the business strategy. If the distributed lock is successfully acquired, the current request obtains exclusive processing rights and can continue to execute subsequent operations. After successfully acquiring the distributed lock, a database transaction is immediately started, and subsequent credential creation, account updates, and message writing will be completed within this transaction. Redis is an open-source in-memory data structure storage system that can be used as a database, cache, and message broker. Redis supports various data structures such as strings, hashes, lists, sets, and sorted sets, and has advantages such as high performance and low latency. In addition, it provides atomic operation commands that can efficiently implement distributed locks. This invention uses a business-unique identifier as the lock key, and multiple service nodes use Redis to achieve mutual exclusion control when accessing ride-hailing billing processing, avoiding duplicate processing.

[0047] Distributed locks are used in conjunction with database transactions. Distributed locks are responsible for preventing the same request from being processed repeatedly at the business level, while database transactions are responsible for ensuring the atomicity of data operations at the storage level.

[0048] Using the order ORDER_20251226_001 as an example, the globally unique identifier for this order is ORDER_20251226_001. When the accounting system prepares to process this request, it first requests a lock from the Redis distributed lock service using ORDER_20251226_001 as the lock identifier. Assume that the order is sent twice due to network jitter. The first request successfully acquires the lock identified by ORDER_20251226_001. The second request attempting to acquire the lock with the same identifier will fail because the lock has already been held by the first request. After successfully acquiring the lock, the system immediately issues an instruction to the database to start a transaction. Subsequent operations such as creating vouchers, updating account balances, and writing to the message table will be executed within this transaction. If a database failure occurs during the transaction execution, the entire transaction will be rolled back, and the acquired distributed lock will be released after the transaction ends.

[0049] By employing a dual protection mechanism of distributed locks and database transactions, the same accounting processing request is prevented from being processed repeatedly in high-concurrency scenarios.

[0050] In step S203, within the database transaction, an active accounting voucher and several sub-accounting vouchers are created based on the ride-hailing accounting processing request. The accounting processing result is obtained by processing the account status corresponding to the subject information based on the type of the sub-accounting voucher, and an asynchronous notification message corresponding to the accounting processing result is generated. The association between the active accounting voucher and each sub-accounting voucher is established based on a globally unique identifier.

[0051] In one embodiment, the active account voucher is used to record the total amount and business type of the business corresponding to the ride-hailing accounting request; the sub-account voucher is used to record the details of fund changes or virtual value changes of each entity in the ride-hailing accounting request.

[0052] Among them, the active account voucher refers to the master voucher directly corresponding to a ride-hailing accounting request. This voucher represents a complete business document and is used to record the overall information of the transaction. The total amount in the active account voucher refers to the cumulative value of the changes in funds or virtual value of all participants in a ride-hailing transaction. This value is equal to the sum of the amounts in all sub-account vouchers. The business type in the active account voucher refers to the category of business corresponding to the ride-hailing accounting request, used to distinguish the accounting rules and processing procedures of different businesses, such as order settlement, withdrawal, recharge, fines, or reward distribution. Sub-account vouchers refer to the detailed vouchers subordinate to the active account voucher. Each sub-account voucher corresponds to a participating entity and is used to record the changes in funds or virtual value of that entity in this accounting transaction. The details of fund changes in the sub-account voucher refer to the specific amount and direction of an entity's actual fund income or expenditure in this accounting transaction. The details of virtual value changes in the sub-account voucher refer to the specific amount and direction of an entity's increase or decrease in virtual balance in this accounting transaction. This change is not accompanied by the transfer of real funds. Account status processing refers to adding or reducing the account balance corresponding to the main account information based on the change type and amount recorded in the sub-accounting voucher. Accounting processing result refers to the final status information obtained after the account status update, including a comparison of the account balances before and after the change and whether the processing was successful. Asynchronous notification messages mean that the message corresponding to the accounting processing result is not sent immediately, but waits for subsequent steps to push it to the target business account asynchronously.

[0053] Specifically, in the database transaction initiated in the aforementioned steps, this invention first creates an active accounting voucher based on the ride-hailing billing request. This active accounting voucher uses a globally unique identifier as its primary key or association key. Subsequently, based on the number of participants involved in the ride-hailing billing request, a corresponding number of sub-accounting vouchers are created. Each sub-accounting voucher also carries a globally unique identifier to ensure its association with the active accounting voucher. The account status of the corresponding entity is processed according to the type of each sub-accounting voucher; different types of accounting vouchers trigger different account update logic. After all account status updates are completed, an asynchronous notification message containing the billing processing result is generated. This message is not sent immediately but is instead prepared to be written to a message table for subsequent processing.

[0054] In one embodiment, after creating an active accounting voucher and several sub-accounts corresponding to the ride-hailing billing request, the method further includes: Based on globally unique identifiers, active account vouchers and several sub-active account vouchers are stored in separate tables to ensure the association between active account vouchers and each sub-active account voucher.

[0055] In this context, table partitioning refers to distributing data across multiple database tables with identical structures according to preset partitioning rules. The active account voucher table is a database table specifically used to store active account voucher records, with each table containing only active account voucher data. The sub-active account voucher table is a database table specifically used to store sub-active account voucher records, with each table containing only sub-active account voucher data. Active account vouchers and their corresponding sub-active account vouchers are associated with each other through a globally unique identifier. This association ensures that all corresponding sub-active account voucher records can be accurately retrieved from a single active account voucher record.

[0056] In one embodiment of the present invention, table partitioning is performed after the creation of active ledger vouchers and sub-active ledger vouchers. Based on the value of the globally unique identifier, the active ledger voucher is written to a specific partition in the active ledger voucher table, and simultaneously, each sub-active ledger voucher corresponding to that active ledger voucher is written to its corresponding partition in the sub-active ledger voucher table. The same globally unique identifier will be routed to the same partition in both the active ledger voucher table and the sub-active ledger voucher table. After table partitioning is completed, the association between active ledger vouchers and sub-active ledger vouchers remains intact through the globally unique identifier and will not be lost due to the dispersion of physical storage locations.

[0057] Continuing with the example of order ORDER_20251226_001, in which the platform takes a 10 yuan commission and the driver earns 40 yuan, this invention first creates an active account voucher. For example, the active account voucher records a total amount of 50 yuan, and the business type is recorded as order settlement. The associated field of the active account voucher is set to the globally unique identifier ORDER_20251226_001. Then, two sub-account vouchers are created. The first sub-account voucher corresponds to the platform entity and records the platform's 10 yuan commission; the second sub-account voucher corresponds to the driver entity and records the driver's 40 yuan income. The associated field of both sub-account vouchers is also set to ORDER_20251226_001, thus establishing a connection with the active account voucher.

[0058] After the active account voucher and sub-active account voucher are created, the active account voucher is written to a specific sub-table of the active account voucher table based on the value of the globally unique identifier. In one embodiment of the invention, a sub-table rule of hash modulo on the globally unique identifier is adopted. For example, the hash value of the globally unique identifier can be modulo 10. Continuing with the above example, assuming that the hash value of ORDER_20251226_001 is modulo 10 and the result is 3, this result indicates that the data needs to be stored in the third sub-table. The active account voucher is written to the active account voucher table_03, and the sub-active account vouchers corresponding to the platform and the drivers are written to the sub-active account voucher table_03 respectively. When it is necessary to query all voucher data of order ORDER_20251226_001 later, the same hash modulo rule is used to calculate the sub-table number 3, and the active account voucher is queried in the active account voucher table_03, and the corresponding sub-active account voucher is queried in the sub-active account voucher table_03. As ride-hailing platform business grew, the amount of voucher data reached hundreds of millions of records. All data was distributed across 10 partitioned tables, with each partitioned table carrying only one-tenth of the data.

[0059] By using a nested structure of active ledger vouchers and sub-active ledger vouchers, the active ledger vouchers record overall business information, while the sub-active ledger vouchers record detailed changes by each party. The two are forcibly linked by a globally unique identifier, which solves the problem of the disconnect between the overall business and the detailed ledger in the traditional solution. When an accounting anomaly occurs, it is possible to quickly trace back to which specific business transaction and which participant has the problem.

[0060] In one embodiment, the types of sub-account entry vouchers include at least information flow accounts, escrow fund accounts, and non-escrow fund accounts. Updating the account status based on the type of sub-account entry voucher specifically includes: If the type of the sub-account voucher is information flow account, then update the main virtual account in the main information and generate account flow information; If the type of the sub-account voucher is escrow fund transaction, then a real fund transfer request is initiated, and after the fund transfer is successful, the distributed lock is acquired again through the callback interface to process the fund transfer result, so as to prevent repeated requests to the callback interface after the fund transfer is successful. If the type of the sub-account voucher is non-escrow fund transaction, then record the payee bank information corresponding to the ride-hailing accounting request, and hand over the payee bank information to the back-end task to process the fund transfer request.

[0061] In one embodiment, the information flow ledger is used to affect the virtual cash balance of the virtual account of the subject in the subject information, without triggering real fund transfers; the escrow fund flow ledger is used for real fund transfers between escrow accounts; and the non-escrow fund flow ledger is used for fund transfers between the platform account and external bank accounts or third-party payment accounts.

[0062] Among them, information flow ledger refers to an accounting operation type that only affects the virtual account balance without triggering the transfer of funds to real bank accounts, used to record virtual fund transfers within the platform; escrow fund flow ledger refers to a real fund transfer operation type that occurs between fund accounts escrowed by the account platform, used to record the transfer of actual currency between different escrow accounts; non-escrow fund flow ledger refers to fund actions where one party is a platform escrow account and the other party is an external bank account or third-party payment account, involving fund outflows from the platform's controllable escrow system. Account transaction information refers to a detailed record of every balance change in a virtual account, each transaction record may specifically include the balance before the change, the amount of the change, the balance after the change, and the reason for the change. In this invention, background tasks refer to background processing programs that run independently of the main accounting processing flow, and these programs are responsible for the scheduling and execution of non-real-time fund transfer requests.

[0063] In its specific implementation, this invention defines different account status update logics based on the characteristics of each type. Specifically, when the sub-account voucher is an information flow account, only the virtual cash balance of the main virtual account is updated and account transaction information is generated; the entire process does not involve any real fund transfer. When the sub-account voucher is a custodial fund transaction, a real fund transfer request is initiated to the payment channel. After the fund transfer is successful, the external payment channel will actively call back the accounting system. The callback interface will then obtain the distributed lock again to process the fund transfer result, preventing the same callback request from being processed repeatedly. When the sub-account voucher is a non-custodial fund transaction, the payee's bank information is recorded and this information is handed over to the background task for processing. The background task independently completes the fund transfer request to the external account.

[0064] Continuing with the example of order ORDER_20251226_001, the sub-account voucher type corresponding to the platform's commission of 10 yuan is information flow account. In the specific implementation of this invention, only the virtual cash balance in the platform's main virtual account is updated by 10 yuan, and an account transaction record is generated showing the balance before the change, the increase of 10 yuan, the balance after the change, and the reason for the change as order commission. The sub-account voucher type corresponding to the driver's income of 40 yuan is escrow account. In the specific implementation, a request to transfer 40 yuan from the platform's escrow account to the driver's escrow account is initiated to the bank payment interface. After the transfer is successful, the bank calls back to the accounting system. The callback interface uses ORDER_20251226_001 as the lock identifier to acquire the distributed lock again. After confirming that the callback has not been processed, the driver's escrow account balance is updated. If a driver withdraws 40 yuan to their personal bank card, the corresponding sub-transaction voucher type is non-escrow funds transaction, which records the driver's bank card number, bank information, and withdrawal amount of 40 yuan. This information is written into the withdrawal task table and sent to the back-end task scheduler for execution. The back-end task independently completes the transfer from the platform's escrow account to the driver's bank card.

[0065] In one embodiment of the present invention, an account balance table can also be maintained to store the account balance information of each entity. The account balance table includes at least the following fields: entity identifier, account type, city code, and current balance. The account types include virtual accounts and escrow accounts. Virtual accounts are used to record the virtual value allocation within the platform and are not bound to a real payment account; escrow accounts are used to record the fund balance in the actual escrow account and are bound to the corresponding payment channel account. The account balance table is used in conjunction with the account transaction record. The account balance table stores the latest balance snapshot, while the account transaction record stores the historical record of each balance change. The two are linked through the entity identifier and account type.

[0066] When the type of the sub-account voucher is information flow account, update the current balance of the corresponding virtual account in the account balance table, and simultaneously generate a change record in the account transaction table, recording the balance before the change, the amount of the change, the balance after the change, and the reason for the change.

[0067] When the type of the sub-account entry voucher is escrow fund entry, before initiating a real fund transfer request, the balance of the corresponding entity's escrow fund account in the account balance table is checked first. The transfer is only initiated after confirming sufficient available balance. After a successful fund transfer, the current balance of the corresponding entity's escrow fund account in the account balance table is updated, and a corresponding fund change record is generated in the account transaction log.

[0068] This embodiment achieves precise separation of information flow and fund flow through differentiated processing of three types of transaction flows. Information flow transactions only update virtual balances without triggering real fund transfers, avoiding false alarms and fund mismatches caused by misjudging virtual revenue allocations within the platform as real payments. Custodial fund transactions employ a callback locking mechanism to process fund transfer results. The callback interface acquires a distributed lock again to ensure that even if the same fund transfer result is called back multiple times, it will only be processed once, preventing duplicate increases in driver account balances. Non-custodial fund transactions delegate fund transfers from external accounts to background tasks. The main accounting process does not need to wait for external bank interface responses, avoiding prolonged database transaction suspensions due to slow external interface responses.

[0069] In one embodiment, the ride-hailing billing request further includes a business type and a business event type; after updating the account status according to the type of the sub-accounting voucher to obtain the billing result, it also includes: The system searches for accounting scenario configurations based on business type, business event type, and subject information, generates double-entry bookkeeping entries that match the accounting scenario configuration, and writes the double-entry bookkeeping entries into the accounting voucher table.

[0070] In one embodiment, generating double-entry bookkeeping entries that match the bookkeeping scenario configuration specifically includes: The debit and credit accounts, as well as the debit and credit amounts between the debit and credit accounts, are determined based on the accounting scenario configuration.

[0071] Among them, business event type refers to the specific business action identifier that triggers accounting processing under a certain business type, which can distinguish the accounting rules corresponding to different triggering reasons within the same business line. Accounting scenario configuration refers to pre-established configuration data, which defines the mapping relationship of accounting subjects that should be generated under specific business types, specific business event types, and specific subject combinations. Double-entry bookkeeping entry refers to the accounting record generated according to the double-entry bookkeeping principle. Each record includes debit account, credit account, and debit / credit amount, with the total debit amount equal to the total credit amount. Accounting voucher table is a database table specifically used to store double-entry bookkeeping entries, with each double-entry bookkeeping entry written as a row in this table.

[0072] This process is executed after the account status update is complete. To connect the accounting and bookkeeping processes, this invention extracts the business type and business event type from the ride-hailing accounting request and combines them with the existing entity information in the request as query conditions to match the accounting scenario configuration. In one embodiment of this invention, the accounting scenario configuration pre-sets debit and credit accounts corresponding to different business types, different business event types, and different entities. After finding a matching accounting scenario configuration, one or more double-entry bookkeeping entries are automatically generated according to the account mapping relationship defined in the configuration. Each double-entry bookkeeping entry conforms to the debit-credit balance principle. The generated double-entry bookkeeping entries are written into the accounting voucher table, completing the automated conversion from accounting events to accounting vouchers.

[0073] Continuing with the example of order ORDER_20251226_001, the ride-hailing accounting request carries the business type as ride-hailing, the business event type as order settlement, and the main information as platform entity PLAT_001 and driver entity DRV_888. In the specific implementation, firstly, the accounting scenario configuration is searched using ride-hailing, order settlement, and platform entity as conditions. The found configuration is a credit entry of 10 yuan into the main business revenue account. Then, the accounting scenario configuration is searched again using ride-hailing, order settlement, and driver entity as conditions. The found configuration is a credit entry of 40 yuan into the accounts payable account. Therefore, two double-entry bookkeeping entries are generated. The first entry is a debit entry of 50 yuan into the accounts receivable account, and the second entry is a credit entry of 10 yuan into the main business revenue account and a credit entry of 40 yuan into the accounts payable account. The total debit amount of 50 yuan equals the total credit amount of 50 yuan. It should be noted that the 50 yuan debit entry in the accounts receivable account belongs to the platform entity. Two double-entry bookkeeping entries are written into the accounting voucher form, and accounting personnel can then directly derive accounting vouchers from the accounting voucher form.

[0074] In step S204, the database transaction is committed and the distributed lock is released.

[0075] Committing a database transaction means permanently saving all data modifications performed within the current transaction to the database. Once successfully committed, these modifications are visible to other database transactions and will not be lost due to subsequent failures. Releasing a distributed lock means returning the distributed lock held by the current request to the distributed lock service. After the lock is returned, other requests waiting for the same lock can acquire the lock and begin processing.

[0076] In a specific implementation of this invention, after the creation of active ledger vouchers, creation of sub-active ledger vouchers, updating of account status, and generation of asynchronous notification messages are all successfully executed, a commit command is first issued to the database, permanently saving all the aforementioned data modification operations to the database at once. Since all operations are within the same database transaction, the commit operation guarantees the atomicity of these data modifications, meaning they all take effect simultaneously. After the database transaction is successfully committed, the distributed lock identified by a globally unique identifier is immediately released, releasing the exclusive protection of the resource corresponding to the request.

[0077] Continuing with the example of order ORDER_20251226_001, after the active account voucher is created, the two sub-account vouchers are created, the platform virtual account balance is updated, the driver's fund transfer request is initiated, and the asynchronous notification message is generated, the database transaction commit instruction is executed. The database writes the active account voucher record, the two sub-account voucher records, the platform virtual account balance change record, and the asynchronous notification message record corresponding to order ORDER_20251226_001 to disk at once and saves them permanently. After successful commit, assuming the database suddenly loses power, these committed data will still exist after restarting and will not be lost. After the transaction commit is completed, a request to release the lock is immediately sent to the distributed lock service, returning the lock corresponding to ORDER_20251226_001. At this time, if another duplicate request for the same order is still queuing for the lock due to network reasons, the duplicate request will immediately acquire the lock, but in subsequent processing, it will detect that the order has been processed and actively abandon it.

[0078] In step S205, the accounting processing result is pushed to the target business account based on the asynchronous notification message.

[0079] Asynchronous notification messages refer to notification data generated within a database transaction but not immediately sent upon generation. These messages contain all information about the accounting processing results and await subsequent asynchronous delivery. The target business account refers to the business entity account receiving the accounting processing results, such as a driver's wallet account for receiving order revenue.

[0080] In a specific implementation of this invention, the asynchronous notification message generated in the database transaction is first read, and the accounting processing result is extracted from it. Then, the result is actively transmitted to the target business account. It should be noted that this step does not block the main accounting processing flow. Even if the target business account is temporarily unavailable or experiences network instability, it will not affect the already completed voucher creation, account status update, and database transaction commit. The accounting processing result is persistently stored in the message table when the transaction is committed. This invention uses an independent background mechanism to scan and push messages, and can automatically retry until successful if the push fails.

[0081] In one embodiment of the present invention, the accounting processing result can be written to a local message table. A scheduled task scans the message table for messages in the pending state, pushes the message content to the interface corresponding to the target business account, updates the message status to sent upon successful push, and retains the status and retryes at preset intervals if the push fails. In another embodiment of the present invention, a transactional sender box combined with a message queue can be used. Specifically, the accounting processing result is written to the sender box table in a database transaction. A database change capture component listens to the sender box table, and after capturing a new record, sends the message to the message queue, which is the message in the service consumption message queue of the target business account. In another embodiment of the present invention, a database change capture component can listen to the message table log. Specifically, after the accounting processing result is written to the message table, the transaction is committed directly. The database change capture component listens to the binlog or WAL log of the message table, and after capturing the log event of a new record, sends the event content to the message queue, which is the message in the service consumption message queue of the target business account.

[0082] Following the example of order ORDER_20251226_001, after the database transaction is committed and the distributed lock is released, the asynchronous notification message records the transaction result of adding 40 yuan to the virtual account of driver subject DRV_888. Reading this asynchronous notification message confirms that the target business account is driver 888's wallet account. A network request is then made to push this transaction result to driver 888's wallet service. Upon receiving the notification, the wallet service updates the displayed wallet balance for driver 888. Assuming that the driver wallet service is currently restarting due to a version upgrade and the push request fails, it will wait for a period of time according to the preset retry strategy and try pushing again until the driver wallet service recovers and successfully receives the notification. When the driver opens the application, the wallet balance will have been updated to include the latest balance of 40 yuan.

[0083] This embodiment solves the problem of reliable communication between accounting processing results and downstream business by asynchronous push. The accounting processing results are persistently stored when the database transaction is committed and will not be lost due to network failures or unavailability of the target business account during the subsequent push process.

[0084] In one embodiment of the present invention, canary configuration and dynamic routing are also supported, allowing canary release of transaction event rules by tenant ID to improve system evolution security. The implementation of canary configuration and dynamic routing is jointly completed by the configuration center and the rule routing engine.

[0085] In one embodiment of the invention, the configuration center can be Apollo or Nacos, used to centrally store the mapping relationship between tenant IDs and the versions of transaction event processing rules, and to support dynamic configuration refresh without restarting the service. Canary deployment configuration can be organized at the tenant level, with each tenant independently bound to a rule version, while a default version is set for tenants that have not been explicitly configured. When a new transaction processing rule needs to be released, operations personnel only point a portion of test tenants or a small number of production tenants to the new rule version in the configuration center, while the remaining tenants continue to use the old version, thus achieving fine-grained canary deployment control at the tenant level.

[0086] For example, after an account activity request enters the processing chain, the tenant ID to which the current request belongs is first parsed from the request. Then, the gray-scale router is called to query the configuration center based on the tenant ID to obtain the rule version identifier that the current tenant should use. The routing component dynamically selects the corresponding account activity event handler based on the version identifier and distributes the request to the handler to complete subsequent business logic such as account allocation, reconciliation, or settlement. During this process, if it is necessary to adjust the gray-scale range or if a problem is found with the new rule requiring an emergency rollback, the operations and maintenance personnel only need to modify the version mapping of the corresponding tenant in the configuration center or switch it back to the old version. The configuration change takes effect in real time, and subsequent requests will be automatically routed to the target version without the need to restart the service or release new code.

[0087] In one embodiment of the present invention, it also supports dynamically creating fund accounts and binding them to different payment accounts based on dimensions such as city, adapting to regionalized operation strategies. Specifically, the city code field is extended in the account balance table maintained in the aforementioned steps of the present invention. The accounting processing request carries the city code information. When it is necessary to create a fund account for a certain entity in a specific city, the system retrieves the corresponding payment channel information from the configuration center based on the city code, calls the API (Application Programming Interface) of the payment channel to complete the creation of the fund account, and writes the binding relationship between the city code and the payment account into the escrow fund account record of the entity in the account balance table. During subsequent transaction processing, the system queries the corresponding entity's escrow fund account number from the account balance table based on the city code in the sub-transaction voucher to complete the fund transfer.

[0088] This embodiment effectively adapts to the regional operation strategies of ride-hailing platforms in different cities, meeting the needs of differentiated fund management.

[0089] The above process will be illustrated with a specific numerical example below. Figure 3The flowchart illustrates the accounting request process. Accounting requests submitted by external systems can include one or more of the following: information flow accounts, escrow fund flow accounts, and non-escrow fund flow accounts. The accounting request first undergoes parameter validation through the API gateway, which parses information such as business type and business event type, assigning a globally unique identifier (UUID) to the request. Using the assigned UUID as the key, a lock is requested from the distributed lock service. Upon successful acquisition, a database transaction is initiated. Within the database transaction, active account vouchers and sub-account vouchers are created, and corresponding operations are performed based on the account type. When the account type is an information flow account, the virtual account balance is updated and a transaction record is generated. When the account type is an escrow account, a payment request is initiated by calling the payment agent, and the payment result is notified via an asynchronous callback. Upon successful callback, the voucher status is updated. When the account type is a non-escrow account, external account information is recorded, and asynchronous disbursement is triggered after the transaction is committed. After the above accounting operations are completed, the accounting service is called, and different posting rules are matched according to the account event to generate formal master and sub-account vouchers. Simultaneously, messages to be sent are pre-written to a local message table. After the database transaction is committed, the asynchronous message processor pushes the messages to the driver's wallet or reporting system. Finally, the system releases the distributed lock. If an exception occurs during processing, the system will roll back the database transaction and release the distributed lock to ensure data consistency.

[0090] The distributed accounting processing method for ride-hailing services provided in this embodiment ensures that the same accounting processing request is processed only once in the entire distributed system by generating a globally unique identifier and combining it with a distributed lock, thus avoiding duplicate accounting problems caused by network retries or duplicate message consumption. By completing the creation of active accounting vouchers, sub-active accounting vouchers, account status updates, and asynchronous notification message generation within the same database transaction, it ensures that these operations either all succeed or all roll back, solving the data consistency problem between accounting processing and subsequent operations. By establishing the association between active accounting vouchers and sub-active accounting vouchers based on the globally unique identifier, it achieves complete traceability from the overall business to the details of each party.

[0091] This embodiment also provides a distributed accounting device for ride-hailing services, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0092] This embodiment provides a distributed accounting processing device for ride-hailing services, such as... Figure 4 As shown, it includes: The request response module 401 is used to respond to a ride-hailing billing processing request and generate a globally unique identifier corresponding to the ride-hailing billing processing request, wherein the ride-hailing billing processing request includes at least subject information; The transaction initiation module 402 is used to acquire a distributed lock based on the globally unique identifier, and to initiate a database transaction after successfully acquiring the distributed lock. The distributed lock is used to prevent the same ride-hailing billing processing request from being processed repeatedly. The transaction processing module 403 is used to create an active account voucher and several sub-active account vouchers according to the ride-hailing accounting processing request in the database transaction, process the account status corresponding to the main information according to the type of the sub-active account vouchers to obtain the accounting processing result, and generate an asynchronous notification message corresponding to the accounting processing result. The association between the active account voucher and each sub-active account voucher is established based on the globally unique identifier. Transaction commit module 404 is used to commit the database transaction and release the distributed lock; The message push module 405 is used to push the accounting processing result to the target business account based on the asynchronous notification message.

[0093] In some optional implementations, the active account voucher is used to record the total amount and business type of the business corresponding to the ride-hailing accounting request; the sub-active account voucher is used to record the details of fund changes or virtual value changes of each entity in the ride-hailing accounting request.

[0094] In some alternative implementations, the transaction processing module 403 includes: The partitioned storage unit is used to partition and store the active account voucher and several sub-active account vouchers according to the globally unique identifier, so as to ensure the association between the active account voucher and each of the sub-active account vouchers.

[0095] In some optional implementations, the types of sub-account vouchers include at least information flow accounts, escrow fund accounts, and non-escrow fund accounts. The transaction processing module 403 includes: The first classification processing unit is used to update the main virtual account in the main information and generate account flow information if the type of the sub-account voucher is the information flow account. The second classification processing unit is used to initiate a real fund transfer request if the type of the sub-account voucher is the escrow fund account transaction, and to obtain the distributed lock again through the callback interface after the fund transfer is successful in order to process the fund transfer result, so as to prevent repeated requests to the callback interface after the fund transfer is successful. The third classification processing unit is used to record the payee bank information corresponding to the ride-hailing accounting processing request if the type of the sub-accounting voucher is the non-custodial fund transaction, and then hand over the payee bank information to the background task to process the fund transfer request.

[0096] In some optional implementations, the information flow ledger is used to affect the virtual cash balance of the virtual account of the subject in the subject information, without triggering real fund transfers; the escrow fund flow ledger is used for real fund transfers between escrow accounts; and the non-escrow fund flow ledger is used for fund transfers between platform accounts and external bank accounts or third-party payment accounts.

[0097] In some optional implementations, the ride-hailing billing request further includes a business type and a business event type. The transaction processing module 403 includes: The double-entry bookkeeping unit is used to search for the bookkeeping scenario configuration based on the business type, the business event type, and the subject information, generate double-entry bookkeeping entries that match the bookkeeping scenario configuration, and write the double-entry bookkeeping entries into the bookkeeping voucher table.

[0098] In some alternative implementations, the double-entry bookkeeping unit includes: The double-entry bookkeeping sub-unit is used to configure and determine debit and credit accounts, as well as the lending and borrowing amounts between the debit and credit accounts, according to the bookkeeping scenario.

[0099] The ride-hailing distributed accounting processing device provided in this embodiment of the invention can execute the ride-hailing distributed accounting processing method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0100] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0101] The following is a detailed reference. Figure 5 The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes based on a program stored in a read-only memory (i.e., ROM 502) or a program loaded from memory 508 into random access memory (i.e., RAM 503). The RAM 503 also stores various programs and data required for the operation of the electronic device. The processor 501, ROM 502, and RAM 503 are interconnected via a bus 504. Input / output (i.e., I / O interface 505) is also connected to the bus 504.

[0102] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0103] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a memory 508, or installed from a ROM 502. When the computer program is executed by the processor 501, it performs the functions defined in the ride-hailing distributed accounting method of the embodiments of the present invention.

[0104] Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.

[0105] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the distributed accounting method for ride-hailing services shown in the above embodiments is implemented.

[0106] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0107] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A distributed accounting method for ride-hailing services, characterized in that, The method includes the following steps: In response to a ride-hailing billing request, a globally unique identifier corresponding to the ride-hailing billing request is generated, wherein the ride-hailing billing request includes at least subject information; A distributed lock is acquired based on the globally unique identifier, and a database transaction is started after the distributed lock is successfully acquired. The distributed lock is used to prevent the same ride-hailing billing processing request from being processed repeatedly. In the database transaction, an active accounting voucher and several sub-accounting vouchers are created according to the ride-hailing accounting processing request. The account status corresponding to the main information is processed according to the type of the sub-accounting vouchers to obtain the accounting processing result, and an asynchronous notification message corresponding to the accounting processing result is generated. The association between the active accounting voucher and each sub-accounting voucher is established based on the globally unique identifier. Submit the database transaction and release the distributed lock; The accounting processing result is pushed to the target business account based on the asynchronous notification message.

2. The method according to claim 1, characterized in that, The active account voucher is used to record the total amount and business type of the business corresponding to the ride-hailing accounting request; the sub-active account voucher is used to record the details of fund changes or virtual value changes of each entity in the ride-hailing accounting request.

3. The method according to claim 1, characterized in that, After creating an active accounting voucher and several sub-active accounting vouchers corresponding to the ride-hailing accounting request, the process also includes: Based on the globally unique identifier, the active account voucher and several sub-account vouchers are stored in separate tables to ensure the association between the active account voucher and each of the sub-account vouchers.

4. The method according to any one of claims 1-3, characterized in that, The types of sub-account movement vouchers include at least information flow accounts, escrow fund accounts, and non-escrow fund accounts. The step of updating the account status based on the type of the sub-account movement voucher specifically includes: If the type of the sub-account voucher is the information flow account, then update the main virtual account in the main information and generate account transaction information; If the type of the sub-account voucher is the escrow fund account, then a real fund transfer request is initiated, and after the fund transfer is successful, the distributed lock is obtained again through the callback interface to process the fund transfer result, so as to prevent repeated requests to the callback interface after the fund transfer is successful. If the type of the sub-accounting voucher is the non-escrow fund transaction, then the payee bank information corresponding to the ride-hailing accounting processing request is recorded, and the payee bank information is handed over to the background task to process the fund transfer request.

5. The method according to claim 4, characterized in that, The information flow ledger is used to affect the virtual cash balance of the virtual account of the subject in the subject information, without triggering real fund transfers; the escrow fund flow ledger is used for real fund transfers between escrow accounts; the non-escrow fund flow ledger is used for fund transfers between platform accounts and external bank accounts or third-party payment accounts.

6. The method according to claim 1, characterized in that, The ride-hailing billing request also includes business type and business event type; After obtaining the accounting result by updating the account status according to the type of the sub-account entry voucher, the process further includes: Based on the business type, the business event type, and the subject information, the accounting scenario configuration is searched, a double-entry bookkeeping entry matching the accounting scenario configuration is generated, and the double-entry bookkeeping entry is written into the accounting voucher table.

7. The method according to claim 6, characterized in that, The generation of double-entry bookkeeping entries that match the bookkeeping scenario configuration specifically includes: The debit and credit accounts, as well as the lending and borrowing amounts between the debit and credit accounts, are determined based on the accounting scenario configuration.

8. A distributed accounting processing device for ride-hailing services, characterized in that, The device includes: The request-response module is used to respond to a ride-hailing billing processing request and generate a globally unique identifier corresponding to the ride-hailing billing processing request, wherein the ride-hailing billing processing request includes at least subject information; The transaction initiation module is used to acquire a distributed lock based on the globally unique identifier, and to initiate a database transaction after the distributed lock is successfully acquired. The distributed lock is used to prevent the same ride-hailing billing processing request from being processed repeatedly. The transaction processing module is used to create an active account voucher and several sub-active account vouchers according to the ride-hailing accounting processing request in the database transaction, process the account status corresponding to the main information according to the type of the sub-active account vouchers to obtain the accounting processing result, and generate an asynchronous notification message corresponding to the accounting processing result. The association between the active account voucher and each sub-active account voucher is established based on the globally unique identifier. The transaction commit module is used to commit the database transaction and release the distributed lock; The message push module is used to push the accounting processing results to the target business account based on the asynchronous notification message.

9. An electronic device, characterized in that, include: The system includes a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the ride-hailing distributed accounting method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the ride-hailing distributed accounting method according to any one of claims 1 to 7.

Images