Account book processing method and device, equipment, medium and program product
By dividing the ledger into sub-ledgers and processing them in parallel, the problem of low ledger processing efficiency in IoT business is solved, and the system's processing capacity and stability are improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA MOBILE INFORMATION TECHNOLOGY CO LTD
- Filing Date
- 2026-02-12
- Publication Date
- 2026-05-08
AI Technical Summary
In IoT business, existing ledger processing methods are inefficient when dealing with large volumes of business, leading to locking timeout failures and impacting system performance and stability.
By dividing the target ledger into multiple sub-ledger shards based on user identification parameters, business requests for each shard are processed in parallel, avoiding locking conflicts.
It improved the efficiency of ledger processing, reduced locking waiting time, eliminated a large number of failures during peak business periods, and ensured system stability.
Smart Images
Figure CN121998637A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to a ledger processing method, apparatus, device, medium, and program product. Background Technology
[0002] In the current booming development of the Internet of Things (IoT) business, which is often a group-based operation, hundreds of thousands, or even millions, of IoT SIM cards often share the same group account. The conventional account ledger processing flow is as follows: when performing operations on the ledger, it is first locked; after the operation is completed and the corresponding modifications are made, the ledger is unlocked. When performing billing and deduction operations, if the above processing flow is used, due to the large number of cards involved, a large number of concurrent requests will simultaneously attempt to lock the ledger. This leads to frequent locking timeout failures, severely hindering system processing performance. Numerous timeout failures not only cause significant delays in the processing flow but may also lead to data inconsistencies, negatively impacting the stable operation of the entire IoT business. Therefore, under high-volume business conditions, the existing ledger processing method suffers from low processing efficiency. Summary of the Invention
[0003] This application provides a ledger processing method, apparatus, equipment, medium, and program product that can solve the problem of low processing efficiency of existing ledger processing methods when the business volume is large.
[0004] In a first aspect, embodiments of this application provide a ledger processing method, the method comprising: Upon receiving a business request, the system obtains the number of users associated with the target group account and the identifier parameter of the target user associated with the business request. The target group account is associated with a target ledger. The business request is used to request an operation on the account balance of the target user in the target ledger. If the number of users is greater than a preset number, a target sub-ledger fragment is determined from the target ledger based on the identification parameters of the target user, wherein the target sub-ledger fragment is a portion of the ledger fragments in the target ledger; The server executes the operation corresponding to the business request on the target sub-ledger shard, wherein the server can operate on different shards included in the target ledger at the same time.
[0005] Optionally, determining the target sub-ledger fragment from the target ledger based on the target user's identifier parameters includes: Calculate the target hash value corresponding to the identifier parameter of the target user; If the target ledger includes a sub-ledger fragment corresponding to the target hash value, the sub-ledger fragment corresponding to the target hash value is determined as the target sub-ledger fragment; If the target ledger does not include a sub-ledger shard corresponding to the target hash value, the target sub-ledger shard is created in the target ledger based on the target hash value.
[0006] Optionally, the number of sub-ledger shards included in the target ledger is related to the number of users associated with the target group account, wherein the larger the value of the number of users associated with the target group account, the lower the growth rate of the sub-ledger shards of the target ledger.
[0007] Optionally, if the operation corresponding to the business request is to update the account balance of the target user, the step of executing the operation corresponding to the business request on the target sub-ledger shard includes: Lock the target sub-ledger fragment; If the target subledger segment is successfully locked, the target user's account balance is updated in the target subledger segment.
[0008] Optionally, after obtaining the number of users associated with the target group account and the identifier parameters of the target user associated with the business request, the method further includes: If the number of users is less than or equal to the preset number, the operation corresponding to the business request is executed on the target ledger.
[0009] Optionally, when the operation corresponding to the business request is to query the account balance of the target user, the step of executing the operation corresponding to the business request on the target sub-ledger shard includes: Obtain the total ledger balance of the target ledger after the last account balance update, and obtain first deduction information and second deduction information, wherein the first deduction information includes: deduction information generated by the target sub-ledger segment after the last account balance update of the target ledger; the second deduction information includes: deduction information generated by other sub-ledger segments of the target ledger besides the target sub-ledger segment after the last account balance update of the target ledger; The balance of the general ledger is offset against the first deduction information and the second deduction information to obtain the balance of the target ledger after offsetting.
[0010] Secondly, embodiments of this application also provide a ledger processing apparatus, the apparatus comprising: The acquisition module is used to acquire, upon receiving a business request, the number of users associated with a target group account and the identifier parameters of the target user associated with the business request, wherein the target group account is associated with a target ledger, and the business request is used to request to operate on the account balance of the target user in the target ledger; The judgment module is used to determine a target sub-ledger fragment from the target ledger based on the identification parameters of the target user when the number of users is greater than a preset number, wherein the target sub-ledger fragment is a portion of the ledger fragments in the target ledger; The execution module is used to perform the operation corresponding to the business request on the target sub-ledger shard, wherein the server can operate on different shards included in the target ledger at the same time.
[0011] Thirdly, embodiments of this application also provide an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the ledger processing method as described in the first aspect.
[0012] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the ledger processing method as described in the first aspect.
[0013] Fifthly, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the ledger processing method as described in the first aspect.
[0014] In this embodiment, upon receiving a business request, the server obtains the number of users associated with a target group account and the identifier parameters of the target user associated with the business request. The target group account is associated with a target ledger. The business request requests to operate on the account balance of the target user in the target ledger. If the number of users exceeds a preset number, a target sub-ledger fragment is determined from the target ledger based on the identifier parameters of the target user. The target sub-ledger fragment is a subset of the target ledger fragments. The operation corresponding to the business request is executed on the target sub-ledger fragment. The server can operate on different fragments included in the target ledger simultaneously. Compared to the related technology's method of "the server operates on the target ledger upon receiving a business request," in this embodiment, the server operates on the target sub-ledger fragment upon receiving a business request. Furthermore, if the server receives concurrent business requests for other fragments besides the target sub-ledger fragment, it can process them in parallel, thereby improving the efficiency of ledger processing. Attached Figure Description
[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0016] Figure 1 It is the functional architecture of the billing system in related technologies; Figure 2 It refers to the account ledger processing architecture in related technologies; Figure 3 This refers to the billing process in related technologies; Figure 4 This is one of the flowcharts of the ledger processing method provided in the embodiments of this application; Figure 5 This is the account ledger processing architecture provided in the embodiments of this application; Figure 6 This is one of the flowcharts illustrating the process of updating the account balance of the target user in the ledger processing method provided in this application embodiment; Figure 7 This is the second schematic diagram of the process for updating the account balance of the target user in the ledger processing method provided in this application embodiment; Figure 8 This is one of the flowcharts illustrating the process of querying the account balance of a target user in the ledger processing method provided in this application embodiment; Figure 9 This is the second flowchart illustrating the process of querying the account balance of a target user in the ledger processing method provided in this application embodiment; Figure 10 This is the second flowchart of the ledger processing method provided in the embodiments of this application; Figure 11 This is a structural diagram of the ledger processing apparatus provided in the embodiments of this application; Figure 12 This is a structural diagram of the electronic device provided in the embodiments of this application. Detailed Implementation
[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0018] This application provides a ledger processing method. To clarify the difference between the ledger processing method of this application and related technologies, the ledger processing methods of related technologies are described below: like Figure 1 The diagram illustrates a typical billing system architecture. The billing system includes a data acquisition and parsing module, a data management module, a billing and pricing module, and a billing list management module. The data acquisition and parsing module obtains user usage records (call detail records) from network elements in the core network of the communication network, and parses and converts their formats. The billing and pricing module analyzes the call detail records processed by the data acquisition and parsing module, matches and obtains user information and product tariffs, calculates costs according to tariff rules, and outputs a billed list. The billing list management module stores the billed list in a database for user querying and statistical analysis. The data management module stores and manages user information, order details, product tariffs, and other information used in the pricing process.
[0019] In billing systems targeting individual users, the number of users linked to a single individual account is limited, generally not exceeding five; even for family accounts, the number of users typically does not exceed a few dozen. Given the small number of users per account, each account's various balance ledgers, such as ordinary cash ledgers, various special fund ledgers, and grant ledgers, contain only one record. In this situation, the pressure on the account's balance ledgers is relatively small, whether it's pre-deduction operations during billing and pricing or credit control simulation deductions.
[0020] like Figure 2The diagram shows a typical account ledger processing architecture. Based on this architecture, a common ledger processing mechanism is as follows: when performing an operation on the ledger, the ledger is first locked, and then unlocked after the operation is completed, i.e., after the corresponding modifications are made.
[0021] like Figure 3 The diagram shows a common billing process, including: 1. The pricing process requires deductions when processing call detail records; or the credit control process requires fictitious deductions.
[0022] 2. If it is a query request, the specified ledger balance will be retrieved directly.
[0023] 3. If it is a deduction request, a lock request is sent to the corresponding ledger on the account to ensure the exclusivity of the operation and data consistency.
[0024] 4. If the lock request fails, wait for a certain period of time; if the waiting time exceeds the preset time threshold, the business process is deemed to have failed and the process is terminated.
[0025] 5. Once the lock request is successful, execute the lock operation to avoid concurrent conflicts.
[0026] 6. Adjust the ledger balance according to business logic to accommodate billing requirements.
[0027] 7. After completing all operations, perform an unlock operation on the ledger to release resources and restore the ledger to a normal accessible state.
[0028] In typical scenarios where a single account is associated with a limited number of users, the concurrency of call detail records (CDRs) in this type of billing balance processing flow remains low. Locking and unlocking operations on a single ledger are infrequent, and locking timeout failures are extremely rare. Therefore, this process can meet the system's performance requirements in most scenarios. However, when a single account is associated with a large number of account ledgers, such as those with millions of users, and assuming an estimated 10 CDRs per user per day, once the group's free resources are exhausted, a pre-deduction operation must be performed on the ledger for each CDR. Calculations show that the average request processing rate for a single ledger will exceed 115 TPS, and during peak business hours, this pre-deduction operation peaks at 287 TPS, meaning that the combined locking, modification, and unlocking operations on a single ledger will reach 287 times per second. Such a high frequency of operations overwhelms a single ledger, making it a bottleneck for critical business processes such as batch pricing, credit control, and balance inquiries. Observation and analysis of the actual system operation revealed that when the number of users under an account reached millions, the processing efficiency of the balance ledger plummeted during peak business hours. Many operations timed out due to long response times, leading to business processing failures. In extreme cases, the system even became unusable, severely impacting business continuity and stability.
[0029] Please see Figure 4 , Figure 4 This is a flowchart of a ledger processing method provided in an embodiment of this application. The ledger processing method is applied to a server and includes the following steps: Step 401: Upon receiving a business request, obtain the number of users associated with the target group account and obtain the identifier parameters of the target user associated with the business request. The target group account is associated with a target ledger. The business request is used to request an operation on the account balance of the target user in the target ledger.
[0030] In this step, the operation corresponding to the business request can be balance inquiry, deduction, etc. It can be understood that the target of the business request can be the target user. The business request carries the identification parameter and ledger code, and the ledger code is used to indicate the target ledger.
[0031] like Figure 5 The diagram illustrates the account ledger processing architecture of the ledger processing method of this application. The server includes multiple group accounts. Upon receiving a business request, the server can determine the target ledger and the target group account associated with the target ledger (e.g., ...) based on the ledger code carried in the business request. Figure 5As shown, when the ledger indicated by the ledger code is ledger A, the target group account is group account 1), and the account balance of the target user is recorded in the target ledger. After determining the target group account, the number of users associated with the target group account can be obtained, that is, how many users' account balances are recorded in the target ledger.
[0032] Step 402: If the number of users is greater than a preset number, determine a target sub-ledger fragment from the target ledger based on the identifier parameters of the target user, wherein the target sub-ledger fragment is a portion of the ledger fragments in the target ledger.
[0033] In this application, the target ledger can be split into multiple sub-ledger fragments, for example... Figure 5 As shown, ledger A can be split into ledger A1, ledger A2, and ledger An. The sub-ledger sharding can be controlled by parameters, allowing each ledger entry of the same account to be split into multiple sub-ledger shards based on the hash value of the user's identifier parameters (e.g., phone number, specific user code, etc.). Each user operates on their corresponding ledger shard according to the sharding mapping rules, and efficient parallel processing can be achieved between each ledger shard. Based on the identifier parameters of the target user, the target sub-ledger shard corresponding to the hash value of the identifier parameters can be determined from the target ledger.
[0034] Step 403: Execute the operation corresponding to the business request on the target sub-ledger shard, wherein the server can operate on different shards included in the target ledger at the same time.
[0035] like Figure 3 As shown, conventional ledger processing involves executing operations corresponding to business requests on the target ledger. For example, a billing transaction locks the target ledger and then deducts the balance. In this application, however, operations are performed on target sub-ledger fragments. For instance, a billing transaction only requires locking the target sub-ledger fragment and then deducting the balance. While the target sub-ledger fragment is being locked, other fragments of the target ledger remain unlocked. If other concurrent business requests target these other fragments, they can be processed in parallel, thus improving ledger processing efficiency. Understandably, when processing account ledgers with millions of users, conventional ledger processing requires sequentially locking and unlocking the target ledger. However, the method in this application can divide the target ledger into multiple sub-ledger fragments for parallel processing, sequentially locking and unlocking each fragment, significantly reducing waiting time and improving ledger processing efficiency.
[0036] In the ledger processing method provided in this application embodiment, upon receiving a business request, the server obtains the number of users associated with the target group account and the identifier parameters of the target user associated with the business request. If the number of users is greater than a preset number, a target sub-ledger fragment is determined from the target ledger based on the identifier parameters of the target user. The operation corresponding to the business request is executed on the target sub-ledger fragment. The server can operate on different fragments included in the target ledger simultaneously. Compared with the related technology method of "the server operates on the target ledger upon receiving a business request," in the method of this application embodiment, the server operates on the target sub-ledger fragment upon receiving a business request. Furthermore, if the server receives concurrent business requests for other fragments besides the target sub-ledger fragment, it can process them in parallel, thereby improving the efficiency of ledger processing. This avoids a large number of locking conflicts in traditional solutions and prevents a large number of failures during peak business periods.
[0037] Optionally, determining the target sub-ledger fragment from the target ledger based on the target user's identifier parameters includes: Calculate the target hash value corresponding to the identifier parameter of the target user; If the target ledger includes a sub-ledger fragment corresponding to the target hash value, the sub-ledger fragment corresponding to the target hash value is determined as the target sub-ledger fragment; If the target ledger does not include a sub-ledger shard corresponding to the target hash value, the target sub-ledger shard is created in the target ledger based on the target hash value.
[0038] In this embodiment, the target hash value corresponding to the identifier parameter of the target user is calculated. If the target ledger includes a sub-ledger fragment whose ledger has been changed to the target hash value, the sub-ledger fragment corresponding to the target hash value is determined as the target sub-ledger fragment. In this case, it is indicated that the target user is an old user who has performed ledger processing before this business request.
[0039] If the target ledger does not include a sub-ledger shard corresponding to the target hash value, the target sub-ledger shard is created in the target ledger, and the ledger number of the target sub-ledger shard is the target hash value; in this case, it indicates that the target user is a new user who has not performed ledger processing before this business request.
[0040] In this embodiment, the target sub-ledger fragment is created or determined in the target ledger. During the execution of the operation corresponding to the business request, only the target sub-ledger fragment is processed. Other fragments in the target ledger besides the target sub-ledger fragment can be operated in parallel, thereby improving the efficiency of ledger processing.
[0041] Optionally, the number of sub-ledger shards included in the target ledger is related to the number of users associated with the target group account, wherein the larger the value of the number of users associated with the target group account, the lower the growth rate of the sub-ledger shards of the target ledger.
[0042] It's important to note that more shards are not necessarily better. Based on experimental tests and practical data, an excessive number of shards can negatively impact the efficiency of multi-shard aggregation operations. For example, if you need to query the real-time monthly charges for a specific account, you would need to aggregate the charges deducted from each shard across all ledgers under that account. Too many shards will affect the efficiency of this aggregation query operation. Furthermore, analysis of concurrency rates for large customer users shows that as the number of users under a customer increases, user activity and concurrency do not increase linearly. Introducing a sharding model and appropriately setting the number of users each shard can accommodate will help improve system processing performance.
[0043] Taking an account scale of 10 million users as an example, if it is divided into 1,000 to 2,000 shards, the database can stably handle the load, but the efficiency of operations involving summary queries will be significantly reduced.
[0044] This embodiment adopts a segmented and fragmented mode: 1. The design parameter maxsubsnum supports multi-segment configuration. The specific configuration format is as follows: Segment 1: Number of users supported per shard, Number of users enabled in Segment 1; ...; Segment n: Number of users supported per shard, Number of users enabled in Segment n. For example, a configuration of 1000,0;2000,100000;20000,300000 means that for an account with less than 100,000 users, one shard is added for every 1,000 users; for users between 100,000 and 300,000, one shard is added for every 2,000 users; and for users above 300,000, one shard is added for every 20,000 users.
[0045] 2. Set the sharding activation threshold in multi-segment sharding mode: When the number of users is less than the number of shards in the first segment (inclusive), sharding will not be enabled, and shard 0 will be used by default to avoid resource waste and performance loss.
[0046] For example, configuring maxsubsnum to 0, 1000, 2000, 100000; 20000, 300000, etc., represents the following meanings: Users: 10, Sharding not enabled; Users: 1001, Sharding: 2; Users: 11000, Sharding: 11; Users: 100000, Sharding: 100; Users: 101500, Sharding: 100; Users: 102000, Sharding: 101; Users: 300000, Sharding: 200; Users: 305000, Sharding: 200; Users: 320000, Sharding: 201; Users: 6000000, Sharding: 485; Users: 10000000, Sharding: 685. For an account containing 500,000 valid users, the number of shards = (100,000 - 0) ÷ 1,000 + (300,000 - 100,000) ÷ 2,000 + (500,000 - 300,000) ÷ 20,000 = 210.
[0047] By supporting a segmented and sharded mode, the larger the user base, the lower the sharding growth rate, ensuring that the number of shards for very large accounts remains controllable without affecting regular accounts. According to experimental test data, for aggregation operations of large accounts with more than 5 million users, segmented sharding is on average 3-5 times more efficient than average sharding.
[0048] Optionally, if the operation corresponding to the business request is to update the account balance of the target user, the step of executing the operation corresponding to the business request on the target sub-ledger shard includes: Lock the target sub-ledger fragment; If the target subledger segment is successfully locked, the target user's account balance is updated in the target subledger segment.
[0049] like Figure 6 As shown, the process of updating the target user's account balance after sharding the target ledger includes: A customer's IoT SIM card uses data services, generating offline call detail records (CDRs). The system collects call detail records (CDRs) and performs batch pricing. Determine whether the account corresponding to the approved IoT card is in segmented mode. If it is not in segmented mode, follow the original consolidated accounting process according to the approval result. If it is in sharding mode, the hash value of the current IoT card is calculated, and the fee is merged into the corresponding ledger shard (target sub-ledger shard) in the ledger sharding table (subject_deduct) according to the pricing result. This operation only locks one ledger shard, and other ledger shards are not affected. If the target subledger segment is successfully locked, the target user's account balance is updated in the target subledger segment.
[0050] It should be noted that the processes for online billing and pricing consolidation, rental fee consolidation, and offline billing and pricing consolidation are similar (all use...). Figure 6 The process shown in the embodiment is enormous, involving tens of billions of call records per day. Each call record requires the same operation. Therefore, by sharding the ledger, the problem of mutual locking of the main account can be greatly reduced.
[0051] In this embodiment, when the operation corresponding to the business request is a balance update, the process of locking and unlocking the target sub-ledger fragments is carried out using the sharding mode. This avoids a large number of locking conflicts in the traditional solution, which can greatly improve processing efficiency and prevent a large number of failures during peak business periods.
[0052] Optionally, after obtaining the number of users associated with the target group account and the identifier parameters of the target user associated with the business request, the method further includes: If the number of users is less than or equal to the preset number, the operation corresponding to the business request is executed on the target ledger.
[0053] like Figure 7 As shown, the ledger processing flow in this embodiment when the number of users is less than or equal to the preset number is as follows: Figure 6 The "original processing flow" includes: A customer's IoT SIM card uses data services, generating offline call detail records (CDRs). The system collects call detail records (CDRs) and performs batch pricing. Based on the pricing results, the balance management service is invoked to deduct the fees, which means merging and accumulating the pricing fees into the user's corresponding account (general ledger balance sheet subject). This operation requires locking the ledger.
[0054] In this embodiment, if the number of users is less than or equal to the preset number, it indicates that the number of users is small, and there is no need to shard the target account, thus saving the resources required to create shards.
[0055] Optionally, when the operation corresponding to the business request is to query the account balance of the target user, the step of executing the operation corresponding to the business request on the target sub-ledger shard includes: Obtain the total ledger balance of the target ledger after the last account balance update, and obtain first deduction information and second deduction information, wherein the first deduction information includes: deduction information generated by the target sub-ledger segment after the last account balance update of the target ledger; the second deduction information includes: deduction information generated by other sub-ledger segments of the target ledger besides the target sub-ledger segment after the last account balance update of the target ledger; The balance of the general ledger is offset against the first deduction information and the second deduction information to obtain the balance of the target ledger after offsetting.
[0056] like Figure 8 The diagram shows a flowchart for querying the account balance of the target user. The process for querying the account balance of the target user includes the following: Trigger a balance and real-time bill query request from the front end; The balance & real-time billing query service determines whether the requested account is in sharding mode. If it is not in sharding mode, it will be processed according to the non-sharding process. If the corresponding account is in sharding mode, then query the billing deduction information of all shards (including the first deduction information and the second deduction information) in the ledger sharding table (subject_deduct) according to the account code (ACCTID) and ledger code (SUBJECTOID), query the total ledger balance in the general ledger balance table (Subject), and offset the two against each other. Return the balance and billing information of the target ledger after the offset to the front end and display them.
[0057] like Figure 9 The diagram shows the non-fragmented mode, which follows the unfragmented process and includes the following steps: Trigger a balance and real-time bill query request from the front end; The Balance & Real-time Bill Inquiry Service queries the original general ledger balance table (Subject) based on the account ID (ACCTID) and ledger ID (SUBJECTOID), retrieves and summarizes the real-time bill data of all users under the specified account, obtains the balance information of the specified account and ledger, and performs a virtual offset against the total real-time bill amount of all users under the account; Return the balance and billing data to the front end and display them.
[0058] In the relevant technical solutions, the monthly deduction amount is updated using a direct assignment method (example: update subject_deduct set CUR_DEDUCT_AMT = X) during the deduction operation, and data locking is used to avoid operation conflicts. This method can meet the performance requirements of most scenarios when the concurrency of operations is not high.
[0059] However, in scenarios where a single account has millions of users, the average request processing rate for a single ledger will exceed 115 TPS. The high frequency of operations will make locking operations a system bottleneck, leading to a sharp decline in business processing efficiency or even a large number of failures, which will seriously affect business continuity and stability.
[0060] In an optional embodiment, a concurrent update mode without explicit locks is proposed based on sharding. This mode increments the "Monthly Deduction Amount" field of the ledger shard table using the original value, rather than directly assigning a value.
[0061] The specific operation example is as follows: The update command is: `update subject_deduct set CUR_DEDUCT_AMT = CUR_DEDUCT_AMT+X;` where `CUR_DEDUCT_AMT` is the new deduction amount, and `X` is the new deduction amount.
[0062] This mode does not require explicit locking of accounts in the program code to ensure transaction consistency. It uses the native transaction control mechanism of the data's update atomic operation to ensure the exclusivity and consistency of the original value increment, and improves the parallel processing capability when operating on multiple numbers.
[0063] The following combination Figure 10 The ledger processing method of this application embodiment will be described as follows: 1. Front-end programs (pricing, credit control, billing inquiry, etc.) need to deduct or query the account balance, call the balance management service, and start the deduction / query process.
[0064] 2. The balance management service determines whether to follow the ledger sharding mode based on the configuration table information. If the configuration does not follow sharding, the original single ledger processing mode will continue to be used.
[0065] 3. In the case of a sharded mode, the balance management service will call different balance management sub-services for processing based on the different operation categories of the ledger (deduction / query).
[0066] 4. If it is a sub-service for deducting fees, the service will be segmented based on the hash value of the user's number, and the corresponding segment number for deducting fees will be calculated.
[0067] 5. Check if the shard exists. If the shard does not exist, insert a new shard data record.
[0068] 6. Deduct fees from the user's corresponding segment to complete the billing process.
[0069] 7. If it is a query service, it is necessary to summarize the deduction information of all ledger segments under this ledger and calculate the total ledger balance.
[0070] To implement this process, a new ledger shard table (subject_deduct) needs to be added, which mainly contains the following key information: account number, ledger number, ledger shard sequence number, and deduction amount for this month.
[0071] Traditional ledger deduction methods typically have only one record per account for each type of balance ledger (e.g., ordinary cash ledger, various types of special fund ledgers, grant ledgers, etc.). Operations such as pre-deduction for billing and pre-payment, and simulated deductions for credit control, do not place significant pressure on the account's balance ledger. Normally, the ledger is locked during use and unlocked after modification. However, with very large accounts, traditional solutions lead to numerous locking conflicts, causing business failures or even complete business blockage. Production system verification shows that this ledger sharding technology, for accounts with over one million IoT cards, improves processing efficiency by an average of over 30 times compared to the traditional single-ledger model. For large accounts exceeding 5 million, the traditional single-ledger processing model frequently experiences blockages or numerous business failures during peak periods. The ledger sharding model essentially eliminates these blockages and numerous business failures, effectively adapting to accounts with a massive number of users.
[0072] Based on system stress testing and actual data statistics from the production system, the ledger sharding model shows the following improvements in several key metrics: The comparison shows that the ledger processing method in this application can improve processing efficiency.
[0073] See Figure 11 , Figure 11 This is a structural diagram of a ledger processing apparatus provided in an embodiment of this application. For example... Figure 11 As shown, the device 1100 includes: The acquisition module 1101 is used to acquire, upon receiving a business request, the number of users associated with a target group account and the identification parameters of the target user associated with the business request, wherein the target group account is associated with a target ledger, and the business request is used to request to operate on the account balance of the target user in the target ledger; The judgment module 1102 is used to determine a target sub-ledger fragment from the target ledger based on the identification parameters of the target user when the number of users is greater than a preset number, wherein the target sub-ledger fragment is a portion of the ledger fragments in the target ledger; The execution module 1103 is used to perform the operation corresponding to the business request on the target sub-ledger shard, wherein the server can operate on different shards included in the target ledger at the same time.
[0074] Optionally, if the operation corresponding to the service request is to update the account balance of the target user, the determination module 1102 is further configured to: Calculate the target hash value corresponding to the identifier parameter of the target user; If the target ledger includes a sub-ledger fragment corresponding to the target hash value, the sub-ledger fragment corresponding to the target hash value is determined as the target sub-ledger fragment; If the target ledger does not include a sub-ledger shard corresponding to the target hash value, the target sub-ledger shard is created in the target ledger based on the target hash value.
[0075] Optionally, the number of sub-ledger shards included in the target ledger is related to the number of users associated with the target group account, wherein the larger the value of the number of users associated with the target group account, the lower the growth rate of the sub-ledger shards of the target ledger.
[0076] Optionally, the execution module 1103 is also used for: Lock the target sub-ledger fragment; If the target subledger segment is successfully locked, the target user's account balance is updated in the target subledger segment.
[0077] Optionally, the execution module 1103 is also used for: If the number of users is less than or equal to the preset number, the operation corresponding to the business request is executed on the target ledger.
[0078] Optionally, when the operation corresponding to the business request is to query the account balance of the target user, the execution module 1103 is further configured to: Obtain the total ledger balance of the target ledger after the last account balance update, and obtain first deduction information and second deduction information, wherein the first deduction information includes: deduction information generated by the target sub-ledger segment after the last account balance update of the target ledger; the second deduction information includes: deduction information generated by other sub-ledger segments of the target ledger besides the target sub-ledger segment after the last account balance update of the target ledger; The balance of the general ledger is offset against the first deduction information and the second deduction information to obtain the balance of the target ledger after offsetting.
[0079] The ledger processing apparatus 1100 provided in this application embodiment can execute all the steps of the ledger processing method described above and achieve the same beneficial effects. To avoid repetition, it will not be described again here.
[0080] This application also provides an electronic device. Since the principle by which the electronic device solves the problem is similar to the ledger processing method in this application, the implementation of this electronic device can refer to the implementation of the aforementioned ledger processing method; repeated details will not be elaborated further. Figure 12 As shown, the electronic device according to an embodiment of this application includes: a processor 1200, configured to read a program from a memory 1220 and execute the following processes: Upon receiving a business request, the system obtains the number of users associated with the target group account and the identifier parameter of the target user associated with the business request. The target group account is associated with a target ledger. The business request is used to request an operation on the account balance of the target user in the target ledger. If the number of users is greater than a preset number, a target sub-ledger fragment is determined from the target ledger based on the identification parameters of the target user, wherein the target sub-ledger fragment is a portion of the ledger fragments in the target ledger; The server executes the operation corresponding to the business request on the target sub-ledger shard, wherein the server can operate on different shards included in the target ledger at the same time.
[0081] Among them, Figure 12 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 1200) and memory (memory 1220). The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides the interface. Processor 1200 is responsible for managing the bus architecture and general processing, and memory 1220 can store data used by processor 1200 during operation.
[0082] Optionally, the processor 1200 is configured to read the program from the memory 1220 and execute the following processes: Calculate the target hash value corresponding to the identifier parameter of the target user; If the target ledger includes a sub-ledger fragment corresponding to the target hash value, the sub-ledger fragment corresponding to the target hash value is determined as the target sub-ledger fragment; If the target ledger does not include a sub-ledger shard corresponding to the target hash value, the target sub-ledger shard is created in the target ledger based on the target hash value.
[0083] Optionally, the number of sub-ledger shards included in the target ledger is related to the number of users associated with the target group account, wherein the larger the value of the number of users associated with the target group account, the lower the growth rate of the sub-ledger shards of the target ledger.
[0084] Optionally, if the operation corresponding to the service request is to update the account balance of the target user, the processor 1200 is configured to read the program in the memory 1220 and execute the following process: Lock the target sub-ledger fragment; If the target subledger segment is successfully locked, the target user's account balance is updated in the target subledger segment.
[0085] Optionally, the processor 1200 is configured to read the program from the memory 1220 and execute the following processes: If the number of users is less than or equal to the preset number, the operation corresponding to the business request is executed on the target ledger.
[0086] Optionally, if the operation corresponding to the service request is to query the account balance of the target user, the processor 1200 is configured to read the program in the memory 1220 and execute the following process: Obtain the total ledger balance of the target ledger after the last account balance update, and obtain first deduction information and second deduction information, wherein the first deduction information includes: deduction information generated by the target sub-ledger segment after the last account balance update of the target ledger; the second deduction information includes: deduction information generated by other sub-ledger segments of the target ledger besides the target sub-ledger segment after the last account balance update of the target ledger; The balance of the general ledger is offset against the first deduction information and the second deduction information to obtain the balance of the target ledger after offsetting.
[0087] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the above-described ledger processing method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.
[0088] This application also provides a computer program product, including computer instructions. When executed by a processor, the computer instructions implement the various processes of the above-described ledger processing method embodiments and achieve the same technical effects. To avoid repetition, these will not be described again here.
[0089] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0090] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0091] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.
Claims
1. A ledger processing method, applied to a server, characterized in that, The method includes: Upon receiving a business request, the system obtains the number of users associated with the target group account and the identifier parameter of the target user associated with the business request. The target group account is associated with a target ledger. The business request is used to request an operation on the account balance of the target user in the target ledger. If the number of users is greater than a preset number, a target sub-ledger fragment is determined from the target ledger based on the identification parameters of the target user, wherein the target sub-ledger fragment is a portion of the ledger fragments in the target ledger; The server executes the operation corresponding to the business request on the target sub-ledger shard, wherein the server can operate on different shards included in the target ledger at the same time.
2. The method according to claim 1, characterized in that, The step of determining the target sub-ledger fragment from the target ledger based on the identifier parameters of the target user includes: Calculate the target hash value corresponding to the identifier parameter of the target user; If the target ledger includes a sub-ledger fragment corresponding to the target hash value, the sub-ledger fragment corresponding to the target hash value is determined as the target sub-ledger fragment; If the target ledger does not include a sub-ledger shard corresponding to the target hash value, the target sub-ledger shard is created in the target ledger based on the target hash value.
3. The method according to claim 2, characterized in that, The number of sub-ledger shards included in the target ledger is related to the number of users associated with the target group account. The larger the number of users associated with the target group account, the lower the growth rate of the sub-ledger shards of the target ledger.
4. The method according to claim 1, characterized in that, When the operation corresponding to the business request is to update the account balance of the target user, the step of executing the operation corresponding to the business request on the target sub-ledger shard includes: Lock the target sub-ledger fragment; If the target subledger segment is successfully locked, the target user's account balance is updated in the target subledger segment.
5. The method according to any one of claims 1 to 4, characterized in that, After obtaining the number of users associated with the target group account and the identifier parameters of the target user associated with the business request, the method further includes: If the number of users is less than or equal to the preset number, the operation corresponding to the business request is executed on the target ledger.
6. The method according to any one of claims 1 to 4, characterized in that, When the operation corresponding to the business request is to query the account balance of the target user, the step of executing the operation corresponding to the business request on the target sub-ledger shard includes: Obtain the total ledger balance of the target ledger after the last account balance update, and obtain first deduction information and second deduction information, wherein the first deduction information includes: deduction information generated by the target sub-ledger segment after the last account balance update of the target ledger; the second deduction information includes: deduction information generated by other sub-ledger segments of the target ledger besides the target sub-ledger segment after the last account balance update of the target ledger; The balance of the general ledger is offset against the first deduction information and the second deduction information to obtain the balance of the target ledger after offsetting.
7. A ledger processing device, applied to a server, characterized in that, The device includes: The acquisition module is used to acquire, upon receiving a business request, the number of users associated with a target group account and the identifier parameters of the target user associated with the business request, wherein the target group account is associated with a target ledger, and the business request is used to request to operate on the account balance of the target user in the target ledger; The judgment module is used to determine a target sub-ledger fragment from the target ledger based on the identification parameters of the target user when the number of users is greater than a preset number, wherein the target sub-ledger fragment is a portion of the ledger fragments in the target ledger; The execution module is used to perform the operation corresponding to the business request on the target sub-ledger shard, wherein the server can operate on different shards included in the target ledger at the same time.
8. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the ledger processing method as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the ledger processing method as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, Includes computer instructions that, when executed by a processor, implement the steps of the ledger processing method as described in any one of claims 1 to 6.