A service offloading method, device and equipment in a distributed system

Abstract

Embodiments of the present specification disclose a service shunting method, device and equipment in a distributed system. The scheme comprises: obtaining a B2B type of withholding payment order set, the withholding payment indicating that the payee automatically deducts from the payer without the payer actively making a payment operation, and the B2B type indicating that the corresponding payee and payer are both B-end users; performing hash processing on the order number of each withholding payment order in the withholding payment order set, and determining a plurality of order sub-sets in the withholding payment order set according to the result of the hash processing; generating a corresponding virtual payer for each order sub-set; performing sharding processing on each withholding payment order according to the user number of the virtual payer, forming a plurality of service traffic shards, and routing to the corresponding distributed system node for continuous processing in order to complete the payment process.

Description

Technical Field

[0001] This specification relates to the field of Internet technology, and in particular to a service diversion method, apparatus, and device in a distributed system. Background Technology

[0002] With the development of computer and internet technology, many businesses can now be conducted online, promoting the growth of various online business platforms. Among these, direct debit, as a convenient payment method, is widely used in scenarios such as taxi fares, utility bill payments, and membership fee deductions. After a user signs a direct debit agreement with a third-party payment platform, when the user generates a direct debit payment order on the third-party platform, the user does not need to perform any payment operations; the third-party payment platform can automatically process the payment through the payment channel.

[0003] Among them, the business-to-business (B2B) deduction business, applied to a distributed system, can be understood as a platform with enterprise transactions as the main body, which gathers supplier information from various industries. The characteristic of inter-enterprise procurement is that the order volume is generally large.

[0004] Furthermore, for B2B direct debit services, this refers to deducting payments from one B-end account to another. The characteristic of this scenario is that both the payee and the payer are B-end users. In this case, the B-end user payer often connects with multiple C-end users (individual users). These C-end users make payments through this B-end user payer, and the transactions are recorded on that B-end user payer's account. Therefore, a single B-end user payer may generate a large volume of business traffic in a short period. Conversely, for B2C direct debit services, this refers to deducting payments from one B-end account to another C-end account. A single C-end account generally does not generate a large volume of business traffic in a short period.

[0005] Currently, transaction traffic is typically segmented based on the payer's user ID to distribute traffic and alleviate system load, facilitating distributed system processing. However, as mentioned earlier, in B2B direct debit scenarios, a single B-end user may generate significant transaction traffic within a short period. If traffic is segmented based on user ID, this traffic will be concentrated in the same segment, creating a hotspot risk for the entire payment system.

[0006] Therefore, for business traffic splitting in distributed systems, a more effective solution is needed for B2B-type deduction business scenarios. Summary of the Invention

[0007] This specification provides one or more embodiments of a service routing method, apparatus, device, and storage medium in a distributed system to solve the following technical problem: For service routing in a distributed system, a more effective solution is needed for B2B type deduction business scenarios.

[0008] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows:

[0009] This specification provides one or more embodiments of a service traffic splitting method in a distributed system, including:

[0010] Obtain a set of B2B type direct debit payment orders, where direct debit payment means that the payee automatically deducts the payment from the payer without the payer having to actively make the payment, and the B2B type means that both the payee and the payer are B-end users;

[0011] The order number of each debit payment order in the debit payment order set is hashed, and multiple order subsets are determined in the debit payment order set based on the hashing result.

[0012] For each of the aforementioned order subsets, generate a corresponding virtual payment user;

[0013] Based on the user ID of the virtual payment user, each direct debit payment order is segmented into multiple business traffic segments, which are then routed to the corresponding distributed system nodes for further processing to complete the payment process.

[0014] This specification provides one or more embodiments of a service offloading device in a distributed system, comprising:

[0015] The acquisition module acquires a set of B2B type direct debit payment orders. Direct debit payment means that the payee automatically deducts the payment from the payer without the payer having to actively make the payment. The B2B type means that both the payee and the payer are B-end users.

[0016] The hash processing module performs hash processing on the order number of each deducted payment order in the deducted payment order set, and determines multiple order subsets in the deducted payment order set based on the hash processing result;

[0017] The generation module generates corresponding virtual payment users for each of the aforementioned order subsets;

[0018] The first sharding processing module shards each deduction payment order according to the user ID of the virtual payment user, forming multiple business traffic shards, and routes them to the corresponding distributed system nodes for further processing in order to complete the payment process.

[0019] This specification provides one or more embodiments of a service offloading device in a distributed system, comprising:

[0020] At least one processor; and,

[0021] A memory communicatively connected to the at least one processor; wherein,

[0022] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0023] Obtain a set of B2B type direct debit payment orders, where direct debit payment means that the payee automatically deducts the payment from the payer without the payer having to actively make the payment, and the B2B type means that both the payee and the payer are B-end users;

[0024] The order number of each debit payment order in the debit payment order set is hashed, and multiple order subsets are determined in the debit payment order set based on the hashing result.

[0025] For each of the aforementioned order subsets, generate a corresponding virtual payment user;

[0026] Based on the user ID of the virtual payment user, each direct debit payment order is segmented into multiple business traffic segments, which are then routed to the corresponding distributed system nodes for further processing to complete the payment process.

[0027] This specification provides one or more embodiments of a non-volatile computer storage medium for service offloading in a distributed system, storing computer-executable instructions, wherein the computer-executable instructions are configured as follows:

[0028] Obtain a set of B2B type direct debit payment orders, where direct debit payment means that the payee automatically deducts the payment from the payer without the payer having to actively make the payment, and the B2B type means that both the payee and the payer are B-end users;

[0029] The order number of each debit payment order in the debit payment order set is hashed, and multiple order subsets are determined in the debit payment order set based on the hashing result.

[0030] For each of the aforementioned order subsets, generate a corresponding virtual payment user;

[0031] Based on the user ID of the virtual payment user, each direct debit payment order is segmented into multiple business traffic segments, which are then routed to the corresponding distributed system nodes for further processing to complete the payment process.

[0032] The above-described at least one technical solution adopted in one or more embodiments of this specification can achieve the following beneficial effects:

[0033] It can hash the order numbers of each direct debit order in a B2B type direct debit order set, and generate one or more virtual payment users for each order subset based on the hashing result. This allows for the distribution of fixed business traffic more evenly across each segment by breaking down the traffic flow through virtual payment users. By segmenting each direct debit order based on the user number of the virtual payment user, multiple business traffic segments are formed. This balanced distribution of the fragmented business traffic reuses existing payment link settings. Subsequent systems do not need to be aware of this and naturally reuse existing segmentation capabilities, which helps to facilitate subsequent payments and achieves more efficient traffic distribution. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 A schematic diagram of a payment chain system for a B2B type direct debit payment business provided in one or more embodiments of this specification;

[0036] Figure 2 A schematic diagram of a service traffic splitting architecture in a distributed system provided for one or more embodiments of this specification;

[0037] Figure 3 A flowchart illustrating a service routing method in a distributed system provided for one or more embodiments of this specification;

[0038] Figure 4 A schematic diagram of the structure of a service diversion device in a distributed system provided for one or more embodiments of this specification;

[0039] Figure 5 This is a schematic diagram of the structure of a service distribution device in a distributed system, provided for one or more embodiments of this specification. Detailed Implementation

[0040] This specification provides a service offloading method, apparatus, device, and storage medium in a distributed system.

[0041] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0042] In e-commerce payment services, from the perspective of sellers and buyers, e-commerce mainly includes four business models: business to business (B2B), business to consumer (B2C), individual seller to consumer (C2C), and online seller to offline store pickup / exchange (O2O).

[0043] Specifically, B2B platforms can be categorized into several types: B2C, B2C, and O2O. B2B is primarily a platform for business transactions, aggregating supplier information from various industries. B2C involves transactions between businesses / stores and individual users. O2O allows individual users to open shops on the platform and conduct business transactions with other individual users. O2O can be seen as an upgrade to B2C, expanding the scenarios in which users can participate in offline consumption.

[0044] Therefore, in payment services, there exists a type of direct debit service. Direct debit refers to the service provided by qualified third-party payment platforms to businesses or users who have signed a direct debit agreement, allowing them to directly deduct or collect payments, bringing numerous conveniences to both. In other words, direct debit is a payment scheme based on authorization. After the payer authorizes the third-party payment platform, the platform can directly deduct funds from the payer's account in the name of the payee's account without the payer's confirmation.

[0045] Furthermore, for B2B direct debit services, this refers to deducting funds from one B-end account to another. The characteristic of this scenario is that both the payee and the payer are B-end users, and the payer's transaction is recorded in the B-end account. This type typically involves high transaction volume. For B2C direct debit services, this refers to deducting funds from one B-end account to another C-end account. The characteristic of this scenario is that the payee is a B-end user, the payer is a C-end user, and the payer's transaction is recorded in the C-end account. It should be noted that the principles for C2C and O2O services are similar and will not be described in detail here.

[0046] In the distributed systems of third-party payment platforms, such as LDC architecture and payment chain systems, the generated business traffic is typically segmented based on the payer's user ID to achieve business traffic distribution, with the same user ID being distributed to the same business traffic segment. As a B2C type of direct debit, a single payer's C-end account generally doesn't handle many transactions (except in special cases), forming a typical direct debit scenario. In this case, if there are multiple B2C type direct debit payment orders, each direct debit bill will correspond to a different payer. Therefore, business traffic distribution based on the payer's user ID is generally quite effective.

[0047] However, as a B2B type of direct debit, due to the generally large order volume of enterprises, the business traffic of a single payer's B-end account will also be high, resulting in a large wave of business traffic belonging to the same account. In addition, a single payer's B-end account is often used by multiple users, thus continuously generating a large amount of business traffic. For example, the payer is a courier company, and the payee is a courier storage point. Since the courier stores the packages at the courier storage point, he / she needs to pay the storage point for storage fees. In order to save the workload of couriers and facilitate the management of the courier company, the courier company registers a B-end account as a public account. Couriers recharge on this public account, and then deduct the payment to the courier storage point through the public account. When multiple couriers deduct the payment to the courier storage point through the public account, a large wave of business traffic will belong to the public account. At the same time, since the daily volume of courier business is high, the public account will continuously have a large amount of business traffic. Therefore, the public account can be considered a hot account, forming a hot debit scenario.

[0048] More intuitively, Figure 1 This is a schematic diagram of a payment chain system for a B2B type direct debit payment business provided for one or more embodiments of this specification.

[0049] like Figure 1As shown, the payment chain system of a third-party payment platform includes multiple nodes such as the acquiring domain, cashier, unified payment, and product account. The acquiring domain nodes include nodes such as the unified acquiring platform and the transaction core, while the cashier nodes include nodes such as payment acceptance and the cashier core. Each node includes application-layer processing units, namely RZ41, RZ42, RZ43, RZ44, and RZ45. Furthermore, the transaction core node, unified payment node, and product account node include multiple storage areas in a sharded database, namely 00, 01, and 02. For ease of description, the storage unit of each node will be described as RZ41, and the storage area will be described as 01.

[0050] Specifically, the payer can initiate a direct debit request from a terminal device, which has a client installed to run the direct debit program.

[0051] For the unified acquiring platform node, the payer initiates a deduction payment request to the processing unit RZ41 in the unified acquiring platform node. The processing unit RZ41 in the unified acquiring platform node creates a transaction with the processing unit RZ41 in the transaction core node. The processing unit RZ41 in the transaction core node stores the transaction record in storage area 01. The processing unit RZ41 in the unified acquiring platform node submits the deduction payment order to the processing unit RZ41 in the payment acceptance node.

[0052] The processing unit RZ41 in the payment acceptance node interacts with the processing unit RZ41 in the unified payment node based on the entrusted deduction protocol. The processing unit RZ41 in the cashier core node executes the protocol payment and exchanges assets with the processing unit RZ41 in the unified payment node. The processing unit RZ41 in the unified payment node generates a payment order and stores the payment order in storage area 01. It submits a transaction receipt to the transaction core node and sends a payment success message to the processing unit RZ41 in the payment acceptance node.

[0053] The processing unit RZ41 in the payment acceptance node interacts with the processing unit RZ41 in the product ledger to record the product ledger. The processing unit RZ41 in the product ledger node records the ledger to storage area 01.

[0054] In summary, in the aforementioned payment chain system, if the same B-end account of the payer continuously has a large amount of business traffic, it will lead to uneven traffic distribution at the application and database levels. A large amount of business traffic will be concentrated on a fixed shard, resulting in insufficient shard resources and thus stability risks.

[0055] Therefore, segmenting the generated business traffic based on the payer's user ID can lead to a large amount of business traffic concentrating in a few segments, resulting in excessive load on those segments. This poses a hotspot risk to the entire payment system. This excessive load on segments is particularly frequent in B2B direct debit transactions.

[0056] Therefore, in order to support the business volume of the distributed system and avoid risks to the payment chain and database, a more efficient business distribution scheme is needed for more balanced sharding.

[0057] In one or more embodiments of this specification, a hash algorithm is introduced to hash the order number of the payer, resulting in random business traffic shards. Virtual payers corresponding to these business traffic shards create transactions and initiate payments, thus distributing traffic at the application level. This helps to achieve more balanced sharding and improve overall cluster performance. The following explanation is based on this approach.

[0058] Intuitively, such as Figure 2 As shown, Figure 2 This is a schematic diagram of a service traffic splitting architecture in a distributed system provided for one or more embodiments of this specification.

[0059] In this business diversion architecture, the query framework includes the process of business diversion of B2B type debit payment business and B2C type debit payment business in the payment link system. It includes B2B type debit payment business and B2C type debit payment business, and regards B2B type debit payment business as hot debit scenario and B2C type debit payment business as ordinary debit scenario.

[0060] For B2C direct debit payment services, there is no need to generate virtual payment users. Instead, the payment is directly routed to the corresponding business traffic segment of the payer to complete the payment.

[0061] For B2B direct debit payment services, a hash algorithm is introduced to hash the payer's order number, resulting in a virtual payer user. Then, the business traffic corresponding to this virtual payer user is routed to the corresponding business traffic shard, thus completing the payment. This application-level traffic distribution helps to achieve more balanced sharding. To clearly illustrate the implementation method of business traffic distribution for B2B direct debit payment services, the following section will explain... Figure 2 The relevant content will be described in detail.

[0062] Figure 2This document illustrates a process flow diagram of a business traffic splitting method in a distributed system, provided for one or more embodiments. This method can be applied to different payment business domains. The process can be executed by computing devices in the corresponding domain (such as intelligent servers or mobile terminals of third-party payment platforms in e-commerce). Certain input parameters or intermediate results in the process can be manually adjusted to help improve accuracy.

[0063] Figure 3 The process may include the following steps:

[0064] S302: Obtain a set of B2B type direct debit payment orders, where direct debit payment means that the payee automatically deducts the payment from the payer without the payer having to actively make the payment. The B2B type means that both the payee and the payer are B-end users.

[0065] In one or more embodiments of this specification, in a B2B direct debit service, within a certain time period, regardless of whether the payer's B-end account needs to deduct funds from the payee's B-end account multiple times or only once, the service will be routed to the service traffic segment corresponding to the payer's user ID. However, when the payer's B-end account deducts funds from the payee's B-end account, each deduction generates a direct debit payment order for the payer's B-end account. Therefore, within a preset time period, a set of direct debit payment orders for each payer's B-end account will be formed. These sets of direct debit payment orders will then be aggregated to form a B2B direct debit payment order set.

[0066] Since direct debit orders carry an order code, and each direct debit order's order code is unique within the corresponding business system, meaning that multiple direct debit orders do not have the same order code, the direct debit order can identify each direct debit transaction generated by the payer.

[0067] Based on this, direct debit payment orders can be processed accordingly, diverting direct debit payment orders generated by the payer's B-end account to different business traffic segments, instead of diverting direct debit payment orders with the same payer's user ID to the same business traffic segment. This allows for business diversion of the payer's B-end account, achieving shard balance. The following section will describe in detail how to process direct debit payment orders.

[0068] S304: Hash the order number of each deducted payment order in the deducted payment order set, and determine multiple order subsets in the deducted payment order set based on the hashing result.

[0069] In one or more embodiments of this specification, since hashing is one-way, the one-way nature of hash functions determines that forward calculation is highly efficient and reverse calculation is extremely difficult, almost impossible, thus providing a certain level of security. At the same time, when performing hash processing, it is possible to generate multiple hash values ​​for multiple strings respectively. Among these, multiple hash values ​​may have the same hash value, for example, by performing a modulo operation on multiple strings.

[0070] Based on this, the order number of each direct debit payment order in the direct debit payment order set is hashed to obtain multiple hash values. According to preset rules, the multiple hash values ​​are divided into multiple subsets.

[0071] For example, when using the remainder operation, if the number of order numbers is 'a', in order to divide 'a' order numbers into 'b' subsets, the 'a' order number data are divided by 'b' respectively. After taking the remainder, multiple remainders are obtained. Order numbers with the same remainder are assigned to the same order subset. That is, the remainder is equivalent to the hash value. Order numbers with the same hash value are assigned to the same order subset, thus obtaining multiple order subsets.

[0072] S306: Generate corresponding virtual payment users for each of the aforementioned order subsets.

[0073] In some embodiments of this application, after generating each order subset, it is possible to divide the corresponding business traffic into different business traffic shards according to each order subset, that is, the same order subset is divided into the same shard, thereby achieving shard balance.

[0074] A distributed system comprises multiple nodes. Traffic can be further divided into different shards based on each order subset. In practice, different subsystems within the same system may have some independence and may independently re-divide and process traffic based on user IDs. Traffic that was initially split may also be re-centralized and redistributed. To avoid affecting the default traffic splitting method (based on user IDs), a virtual payment user is generated for each order subset at the current node. The virtual payment user's user ID replaces the real user ID (the same virtual payment user typically corresponds to multiple real users). This facilitates subsequent traffic splitting based on user IDs, reducing the impact on the existing traffic splitting logic within the system. The implementation requires minimal system modifications and improves traffic balance.

[0075] When generating virtual payment users, for example, a user ID that does not actually exist can be randomly generated to represent the virtual payment user.

[0076] S308: Based on the user ID of the virtual payment user, the deduction payment order is segmented into multiple business traffic segments and routed to the corresponding distributed system nodes for further processing in order to complete the payment process.

[0077] In some embodiments of this application, as described in steps 302-306, the business traffic corresponding to each virtual payment user is relatively more balanced. Therefore, the deduction payment orders of the same virtual payment user are ultimately distributed to the same business traffic shard by the user ID of each virtual payment user. This user ID is used to uniquely identify the payer, which is equivalent to the user identification (UID) of the virtual payment user. This can effectively ensure that the traffic on the multiple business traffic shards formed by the sharding of each deduction payment order is balanced. Therefore, by using the user ID of the virtual payment user, the existing payment link settings are reused, and the business traffic can be dispersed at the entry layer to avoid concentrating the business traffic on a certain business traffic shard. At the same time, when routing to the corresponding distributed system node for further processing, it is beneficial to promote the subsequent payment process.

[0078] pass Figure 3 This method hashes the order numbers of each direct debit order in a B2B direct debit order set and generates one or more virtual payment users for each order subset based on the hashing result. This allows for the distribution of fixed business traffic more evenly across each segment by breaking down the traffic flow through virtual payment users. By segmenting each direct debit order according to the user number of the virtual payment user, multiple business traffic segments are formed. This balanced distribution of fragmented business traffic reuses existing payment link settings. Subsequent systems do not need to be aware of this and naturally reuse existing segmentation capabilities, facilitating subsequent payments and achieving more efficient traffic distribution.

[0079] based on Figure 3 In addition to the method described herein, this specification also provides some specific implementation schemes and extension schemes of this method, which will be further explained below.

[0080] In one or more embodiments of this specification, since the set of direct debit payment orders includes direct debit payment orders from multiple payers' B-end accounts, not all payers' B-end accounts continuously have a large amount of business traffic. That is, some payers' B-end accounts are hot direct debit accounts, and some payers' B-end accounts are ordinary direct debit accounts. However, for hot direct debit accounts, since they usually continuously have a large number of direct debit payment orders, that is, they have a large amount of business traffic, it is necessary to promptly reduce the business traffic of hot direct debit accounts and distribute the concentrated business traffic evenly to the business traffic segments.

[0081] Specifically, before hashing the order numbers of each direct debit payment order, a designated payer is pre-selected from multiple payers. This designated payer is the one that needs to be monitored closely, typically having a consistently high number of direct debit payment orders. Since a high number of direct debit payment orders likely indicates a higher frequency of such orders, and these two factors are correlated, the frequency of automatic deductions for the designated payer can be monitored to identify the current scenario. By determining when the frequency reaches a set threshold, the current scenario is identified as a hotspot for direct debit payments.

[0082] After identifying the current scenario as a hotspot for direct debit, the direct debit orders of the designated payer in the current scenario need to be aggregated into the aforementioned direct debit order set. This effectively ensures that at least a portion of the direct debit orders of the designated payer are included in the direct debit order set, and maximizes the even distribution of the designated payer's business traffic to the business traffic segments.

[0083] Furthermore, if the frequency does not reach the set threshold, the current scenario will be identified as a normal deduction scenario. For normal deduction scenarios, the payer's B-end account does not generate much business traffic at this time, so the payer's user ID scheme can be used for business diversion.

[0084] Based on this, if the current scenario is identified as a normal deduction scenario other than the hot deduction scenario, no virtual payment user will be generated. After obtaining the set of B2B type deduction payment orders, each deduction payment order will be sharded according to the user number of the payer of each deduction payment order, forming multiple business traffic shards, and then routed to the corresponding distributed system nodes for further processing.

[0085] Furthermore, when acquiring a collection of B2B direct debit payment orders, it is also possible to acquire a collection of B2C direct debit payment orders. The payer's C-end account generally does not generate much business traffic, except in special circumstances.

[0086] Therefore, when the set of B2C direct debit payment orders is obtained, the current scenario is identified as a normal direct debit scenario. Then, based on the user ID of the payer in each direct debit payment order in the B2C type direct debit payment order set, each direct debit payment order is sharded to form multiple business traffic shards, which are then routed to the corresponding distributed system nodes for further processing. This allows for the use of different business traffic diversion schemes based on the payer's business traffic, which can both avoid the payer's business traffic being concentrated in a few business traffic shards and reduce computing power.

[0087] In one or more embodiments of this application, after generating an order subset, in order to make the granularity of the segmentation more fine when processing each deduction payment order in each order subset, that is, the business traffic corresponding to the virtual payment user is distributed again.

[0088] Based on this, each direct debit payment order can be divided into several parts within the order subset to achieve the effect of distributing business traffic. However, since each direct debit payment order in the order subset may belong to multiple payers, and each of these multiple payers has a different number of direct debit payment orders, that is, the business traffic corresponding to a single payer is different. In order to separate the direct debit payment orders corresponding to the payers of the hot direct debit accounts into separate shards during subsequent sharding, thereby avoiding hot spot risks and improving system performance, it is necessary to separate the payers with a large amount of business traffic separately.

[0089] When generating corresponding virtual payment users for each order subset, the user ID of the payer of each direct debit order in the order subset is first hashed. Then, based on the hashing result, multiple subsets are determined in the order subset, which can further distribute the business traffic corresponding to each order subset.

[0090] For example, if the number of user IDs in each direct debit order in the order subset is 'a', in order to divide 'a' user IDs into 'b' subsets, the user IDs are divided by 'b' to obtain multiple remainders. User IDs with the same remainder are assigned to the same subset. That is, the remainder is equivalent to a hash value. User IDs with the same hash value are assigned to the same subset, thus obtaining multiple subsets.

[0091] Furthermore, based on the number of direct debit orders contained in each sub-set, the sub-sets with fewer direct debit orders are merged. Virtual payment users are then generated for both the merged set and the remaining sub-sets. In other words, the sub-sets with fewer direct debit orders are merged, while the remaining sub-sets, containing a relatively larger number of direct debit orders, can be considered "hotspot" accounts. This allows the direct debit orders corresponding to the payers of these hotspot accounts to be allocated to separate shards. Simultaneously, ensuring that the number of direct debit orders in the merged set is not significantly different from the remaining sub-sets indicates that the business traffic between the merged set and the remaining sub-sets is similar.

[0092] Of course, by segmenting each direct debit payment order based on the user ID of the virtual payment user, multiple business traffic segments are formed. Due to the finer granularity of the segmentation, the balance of the segments is more effectively guaranteed, and the risk of hot spots is avoided.

[0093] In one or more embodiments of this application, when hashing the order number of each debit payment order in the debit payment order set, the user number may be duplicated when generating the user number of the virtual payment user between the order subsets. Therefore, when generating the user number of the virtual user from the order subsets, it is necessary to avoid assigning order subsets with the same hash value to the same business traffic shard.

[0094] Specifically, since each direct debit order in an order subset may belong to multiple payers, and these payers each have a different number of direct debit orders—that is, there are payers with scattered direct debit orders and payers with concentrated direct debit orders—the first step is to determine the distribution ratio of the corresponding payers in the order subset. This distribution ratio describes the distribution of the number of direct debit orders among multiple payers in the order subset. The number of direct debit orders is the same across multiple order subsets, but the distribution of the number of direct debit orders among multiple payers in each order subset is random; it may be the same or different. For example, in order subset A, the distribution of the number of direct debit orders for each payer is 8, 2, 2; and in order subset B, the distribution is 9, 2, 1. Therefore, the distribution ratios of payers in the two order subsets are 8:2:2 and 9:2:1, respectively.

[0095] After determining the distribution ratio, the similarity of hotspot traffic distribution between each order subset is calculated based on the distribution ratio. When calculating the similarity of hotspot traffic distribution, it can be calculated according to preset rules. For example, only the ratio corresponding to the largest number of single payers including direct debit orders between two order subsets is calculated. Different distribution similarities are corresponding to different preset ranges of ratio.

[0096] After obtaining the similarity of hotspot traffic distribution, for order subsets with similarity exceeding a set threshold, user IDs with inconsistent hash processing and modulo results are generated for each order subset, and these user IDs are used as the corresponding virtual payment user IDs. If the hotspot traffic distribution similarity exceeds the set threshold, it indicates that when generating virtual payment user IDs for each order subset, the user IDs may be duplicated. Therefore, when sharding each direct debit payment order based on the virtual payment user IDs, this order subset might be assigned to the same business traffic shard. Thus, generating user IDs with inconsistent hash processing and modulo results for each order subset, and using these as the corresponding virtual payment user IDs, can prevent direct debit payment orders from multiple order subsets exceeding the set threshold from being assigned to the same business traffic shard.

[0097] Furthermore, after identifying the virtual payment user, since the existing payment link settings determine the sharding bit (i.e., the user ID of the payer) in order to determine the sharding bit, the sharding bit is then used to shard each direct debit payment order. Different sharding bits correspond to different data center traffic. Database sharding is a way to horizontally scale a database.

[0098] The sharding logic implements a route mapping from a request to a specified data shard, which is calculated using the shard key. For example, in a rental application, tenants are categorized into different shards using their IDs as the shard key. Multiple tenant information may reside in the same shard, but a single tenant's information will not span multiple shards.

[0099] Therefore, based on the existing payment link settings, in order to reduce system time consumption, the same approach is adopted after generating virtual payment users.

[0100] Specifically, the user ID of the virtual payment user is determined as the sharding bit, and then the sharding bit is used to shard each direct debit payment order, thereby enabling database sharding and table partitioning through the sharding bit.

[0101] It's important to note that in B2B direct debit services, the payer's B-end account is typically used as a shared account. This shared account is used by multiple employees within the payer's company, with each employee acting as a C-end user in a B2C model. In other words, it can be understood as setting the payer's C-end account to the same account for all C-end users. When the payer has multiple C-end users, their B-end account usually experiences continuous business traffic.

[0102] Furthermore, when a B2B type direct debit payment order corresponds to a payer who has multiple C-end users, the B2B type direct debit payment order is used by the corresponding payee to deduct the amounts payable by the multiple C-end users from the payer.

[0103] Based on the same idea, one or more embodiments of this specification also provide apparatus and devices corresponding to the above methods, such as... Figure 4 , Figure 5 As shown.

[0104] Figure 4 This specification provides a schematic diagram of the structure of a service traffic splitting device in a distributed system, according to one or more embodiments. The device includes:

[0105] The acquisition module 402 acquires a set of B2B type direct debit payment orders. The direct debit payment means that the payee automatically deducts the payment from the payer without the payer having to actively perform the payment operation. The B2B type means that both the payee and the payer are B-end users.

[0106] The hash processing module 404 performs hash processing on the order number of each deducted payment order in the deducted payment order set, and determines multiple order subsets in the deducted payment order set based on the hash processing result;

[0107] The generation module 406 generates corresponding virtual payment users for each of the order subsets;

[0108] The first sharding processing module 408 shards each deduction payment order according to the user ID of the virtual payment user, forming multiple business traffic shards, and routes them to the corresponding distributed system nodes for further processing in order to complete the payment process.

[0109] Optionally, it also includes a first identification module 410, which identifies the current scenario by monitoring the frequency of automatic deductions for the specified payer;

[0110] By determining that the frequency reaches a set threshold, the current scene is identified as a hotspot deduction scene;

[0111] Wherein, the designated payer is a B-end user, and at least a portion of its direct debit payment orders are included in the direct debit payment order set.

[0112] Optionally, if the current scenario is identified as a normal deduction scenario other than the hot deduction scenario, then the virtual payment user will not be generated;

[0113] It also includes a second sharding processing module 412, which shards each debit payment order according to the user number of the payer of each debit payment order, forming multiple business traffic shards, and routes them to the corresponding distributed system nodes for further processing.

[0114] Optionally, it also includes a second identification module 414. If the obtained set of B2C type direct debit payment orders is identified as a normal direct debit scenario, the B2C type means that the corresponding payee is a B-end user and the payer is a C-end user.

[0115] Based on the user ID of the payer in each direct debit payment order in the B2C type direct debit payment order set, each direct debit payment order is segmented to form multiple business traffic segments, and then routed to the corresponding distributed system nodes for further processing.

[0116] Optionally, the first sharding processing module 408 determines the user ID of the virtual payment user as the sharding bit;

[0117] The sharding bits are used to segment each direct debit payment order.

[0118] Optionally, the generation module 406 performs the following for each of the order subsets:

[0119] The user ID of the payer for each direct debit payment order in the order subset is hashed, and multiple subsets are determined in the order subset based on the hashing result.

[0120] Based on the number of debit payment orders contained in each of the sub-sub-sets, the sub-sub-sets with fewer debit payment orders are merged, and corresponding virtual payment users are generated for the merged set and the remaining sub-sub-sets respectively.

[0121] Optionally, the generation module 406 determines the distribution ratio of the payers in the order subset;

[0122] Based on the distribution ratio, calculate the hotspot traffic distribution similarity among the order subsets;

[0123] For the order subsets whose hotspot traffic distribution similarity is higher than a set threshold, user IDs with inconsistent hash processing and remainder results are generated for each order subset, and these user IDs are used as the corresponding virtual payment user IDs.

[0124] Optionally, the payer of the B2B type direct debit payment order is connected to multiple C-end users, and the B2B type direct debit payment order is used by the corresponding payee to deduct the amounts payable by the multiple C-end users from the payer.

[0125] Figure 5 This specification provides a schematic diagram of the structure of a service traffic splitting device in a distributed system, as shown in one or more embodiments. The device includes:

[0126] At least one processor; and,

[0127] A memory communicatively connected to the at least one processor; wherein,

[0128] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0129] Obtain a set of B2B type direct debit payment orders, where direct debit payment means that the payee automatically deducts the payment from the payer without the payer having to actively make the payment, and the B2B type means that both the payee and the payer are B-end users;

[0130] The order number of each debit payment order in the debit payment order set is hashed, and multiple order subsets are determined in the debit payment order set based on the hashing result.

[0131] For each of the aforementioned order subsets, generate a corresponding virtual payment user;

[0132] Based on the user ID of the virtual payment user, each direct debit payment order is segmented into multiple business traffic segments, which are then routed to the corresponding distributed system nodes for further processing to complete the payment process.

[0133] Based on the same approach, one or more embodiments of this specification also provide a non-volatile computer storage medium for service offloading in a distributed system, corresponding to the above method, storing computer-executable instructions, wherein the computer-executable instructions are configured as follows:

[0134] Obtain a set of B2B type direct debit payment orders, where direct debit payment means that the payee automatically deducts the payment from the payer without the payer having to actively make the payment, and the B2B type means that both the payee and the payer are B-end users;

[0135] The order number of each debit payment order in the debit payment order set is hashed, and multiple order subsets are determined in the debit payment order set based on the hashing result.

[0136] For each of the aforementioned order subsets, generate a corresponding virtual payment user;

[0137] Based on the user ID of the virtual payment user, each direct debit payment order is segmented into multiple business traffic segments, which are then routed to the corresponding distributed system nodes for further processing to complete the payment process.

[0138] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0139] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0140] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0141] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0142] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0143] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0144] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0145] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0146] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0147] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0148] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0149] It should also be noted that 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. Without further limitation, 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 said element.

[0150] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0151] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0152] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0153] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for business traffic splitting in a distributed system, comprising: Obtain a set of B2B type direct debit payment orders. Direct debit payment means that the payee automatically deducts money from the payer without the payer having to actively make a payment. The B2B type means that both the payee and the payer are B-end users. Some of the payers' B-end accounts are hot direct debit accounts. Hot direct debit accounts have a lot of direct debit payment orders. Timely reduce the business traffic of hot direct debit accounts and distribute the concentrated business traffic evenly to business traffic segments. The order number of each debit payment order in the debit payment order set is hashed, and multiple order subsets are determined in the debit payment order set based on the hashing result. Generating corresponding virtual payment users for each of the order subsets specifically includes: determining the distribution ratio of the payers in the order subset; calculating the hotspot traffic distribution similarity between the order subsets based on the distribution ratio; and for the order subsets whose hotspot traffic distribution similarity is higher than a set threshold, generating user IDs with inconsistent hash processing and remainder results for each order subset, which are then used as the user IDs of the corresponding virtual payment users. Based on the user ID of the virtual payment user, each direct debit payment order is segmented into multiple business traffic segments, which are then routed to the corresponding distributed system nodes for further processing to complete the payment process.

2. The method as described in claim 1, wherein before hashing the order number of each direct debit payment order in the set of direct debit payment orders, the method further comprises: By monitoring the frequency of automatic deductions for designated payers, the current scenario can be identified; By determining that the frequency reaches a set threshold, the current scene is identified as a hotspot deduction scene; Wherein, the designated payer is a B-end user, and at least a portion of its direct debit payment orders are included in the direct debit payment order set.

3. The method as described in claim 2, if the current scenario is identified as a normal deduction scenario other than the hotspot deduction scenario, then the virtual payment user is not generated; After obtaining the set of B2B type direct debit payment orders, the method further includes: Based on the user ID of the payer in each direct debit payment order, the direct debit payment order is segmented into multiple business traffic segments, which are then routed to the corresponding distributed system nodes for further processing.

4. The method of claim 3, further comprising: If the obtained set of B2C type direct debit payment orders is a B2C type, the current scenario will be identified as a normal direct debit scenario. The B2C type means that the corresponding payee is a B-end user and the payer is a C-end user. Based on the user ID of the payer in each direct debit payment order in the B2C type direct debit payment order set, each direct debit payment order is segmented to form multiple business traffic segments, and then routed to the corresponding distributed system nodes for further processing.

5. The method as described in claim 1, wherein the step of segmenting the debit payment orders according to the user ID of the virtual payment user specifically includes: The user ID of the virtual payment user is determined as the sharding bit; The sharding bits are used to segment each direct debit payment order.

6. The method as described in claim 1, wherein generating corresponding virtual payment users for each of the order subsets specifically includes: Execute separately for each of the aforementioned order subsets: The user ID of the payer for each direct debit payment order in the order subset is hashed, and multiple subsets are determined in the order subset based on the hashing result. Based on the number of debit payment orders contained in each of the sub-sub-sets, the sub-sub-sets with fewer debit payment orders are merged, and corresponding virtual payment users are generated for the merged set and the remaining sub-sub-sets respectively.

7. The method according to any one of claims 1 to 6, wherein the payer corresponding to the B2B type direct debit payment order has multiple C-end users, and the B2B type direct debit payment order is used by the corresponding payee to deduct the amounts payable by the multiple C-end users from the payer.

8. A service routing device in a distributed system, comprising: The acquisition module acquires a set of B2B type direct debit payment orders. Direct debit payment means that the payee automatically deducts money from the payer without the payer having to actively make a payment. The B2B type means that both the payee and the payer are B-end users. Some of the payers' B-end accounts are hot direct debit accounts. Hot direct debit accounts have a lot of direct debit payment orders. Timely release the business traffic of hot direct debit accounts and distribute the concentrated business traffic evenly to business traffic segments. The hash processing module performs hash processing on the order number of each deducted payment order in the deducted payment order set, and determines multiple order subsets in the deducted payment order set based on the hash processing result; The generation module generates corresponding virtual payment users for each of the order subsets, specifically including: determining the distribution ratio of the corresponding payers in the order subsets; calculating the hotspot traffic distribution similarity between the order subsets based on the distribution ratio; for the order subsets whose hotspot traffic distribution similarity is higher than a set threshold, generating user IDs with inconsistent hash processing and remainder results for each order subset, which are used as the user IDs of the corresponding virtual payment users; The first sharding processing module shards each deduction payment order according to the user ID of the virtual payment user, forming multiple business traffic shards, and routes them to the corresponding distributed system nodes for further processing in order to complete the payment process.

9. The apparatus of claim 8 further includes a first identification module, which identifies the current scenario by monitoring the frequency of automatic deductions for a designated payer; By determining that the frequency reaches a set threshold, the current scene is identified as a hotspot deduction scene; in, The designated payer is a B-end user, and at least some of its direct debit payment orders are included in the direct debit payment order set.

10. The apparatus of claim 9, wherein if the current scenario is identified as a normal deduction scenario other than the hotspot deduction scenario, then the virtual payment user is not generated; It also includes a second sharding processing module, which shards each direct debit payment order according to the user ID of the payer of each order, forming multiple business traffic shards, and routes them to the corresponding distributed system nodes for further processing.

11. The apparatus of claim 10 further includes a second identification module, wherein if the acquired set of B2C type direct debit payment orders is identified as a normal direct debit scenario, the B2C type indicates that the corresponding payee is a B-end user and the payer is a C-end user; Based on the user ID of the payer in each direct debit payment order in the B2C type direct debit payment order set, each direct debit payment order is segmented to form multiple business traffic segments, and then routed to the corresponding distributed system nodes for further processing.

12. The apparatus of claim 8, wherein the first sharding processing module determines the user ID of the virtual payment user as the sharding bit; The sharding bits are used to segment each direct debit payment order.

13. The apparatus of claim 8, wherein the generation module performs the following operations for each of the said order subsets: The user ID of the payer for each direct debit payment order in the order subset is hashed, and multiple subsets are determined in the order subset based on the hashing result. Based on the number of debit payment orders contained in each of the sub-sub-sets, the sub-sub-sets with fewer debit payment orders are merged, and corresponding virtual payment users are generated for the merged set and the remaining sub-sub-sets respectively.

14. The apparatus according to any one of claims 8 to 13, wherein the payer corresponding to the B2B type direct debit payment order is connected to multiple C-end users, and the B2B type direct debit payment order is used by the corresponding payee to deduct the amounts payable by the multiple C-end users from the payer.

15. A service offloading device in a distributed system, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: Obtain a set of B2B type direct debit payment orders. Direct debit payment means that the payee automatically deducts money from the payer without the payer having to actively make a payment. The B2B type means that both the payee and the payer are B-end users. Some of the payers' B-end accounts are hot direct debit accounts. Hot direct debit accounts have a lot of direct debit payment orders. Timely reduce the business traffic of hot direct debit accounts and distribute the concentrated business traffic evenly to business traffic segments. The order number of each debit payment order in the debit payment order set is hashed, and multiple order subsets are determined in the debit payment order set based on the hashing result. Generating corresponding virtual payment users for each of the order subsets specifically includes: determining the distribution ratio of the payers in the order subset; calculating the hotspot traffic distribution similarity between the order subsets based on the distribution ratio; and for the order subsets whose hotspot traffic distribution similarity is higher than a set threshold, generating user IDs with inconsistent hash processing and remainder results for each order subset, which are then used as the user IDs of the corresponding virtual payment users. Based on the user ID of the virtual payment user, each direct debit payment order is segmented into multiple business traffic segments, which are then routed to the corresponding distributed system nodes for further processing to complete the payment process.

Images