A unit transaction link risk identification method and device and computer equipment

Abstract

The present specification relates to the field of software testing, and particularly relates to a unit transaction link risk identification method and device and computer equipment. The method comprises obtaining unit transaction link data, wherein the unit transaction link data comprises user information number, service, and physical unit number; calculating a logical unit to which a user belongs according to the user information number; determining whether the physical unit number of each service corresponds to the logical unit to which the user belongs according to the physical unit number of each service and the logical unit to which the user belongs; if yes, determining that the unit transaction link is normal; and if no, determining that the unit transaction link has risks. The present scheme identifies risk items such as cross-unit access, routing disorder, long time consumption, and timeout setting error by checking the transaction link of the test environment, reduces the high cost of manual monitoring, improves the test accuracy, realizes accurate testing, reduces unnecessary cross-unit access, and better adapts to the multi-site and multi-center deployment requirements of future data centers.

Description

Technical Field

[0001] This specification relates to the field of software testing, and in particular to a method, apparatus, and computer equipment for identifying risks in a unitized transaction chain. Background Technology

[0002] The distributed architecture of banking IT primarily employs a local active-active deployment model, which suffers from significant cross-site (campus) access. In a distributed architecture, the system can achieve "self-healing" through rapid restarts when facing single-machine failures. However, when facing regional failures, the numerous cross-site accesses between applications cause the failure to have a larger blast radius as the call chain lengthens. Furthermore, due to the difficulty in fault localization, emergency measures rely mainly on local failover, resulting in poor switching flexibility and difficulty in effectively controlling system recovery time. In a geographically dispersed deployment model, a large number of cross-site accesses lead to significant performance degradation due to network latency, making it difficult to realize the advantages of geographically dispersed active-active deployments.

[0003] Overly complex call relationships lead to a higher probability of service anomalies, making it difficult to pinpoint the scope of business impact and the accuracy of testing. Secondly, for a large number of high-risk or customer experience-affecting items, manually checking the transaction process for risks such as cross-unit access, routing errors, excessive processing time, and incorrect timeout settings is extremely costly and prone to oversight. Summary of the Invention

[0004] To address the problems of difficulty in fault location and high cost of manual inspection when cross-site access applications malfunction in the prior art, this specification provides a unitized transaction link risk identification method, apparatus, and computer equipment.

[0005] This specification provides a method for identifying risks in a unitized transaction link. The method includes: retrieving unitized transaction link data, the unitized transaction link data including: user information number, service, and physical unit number; calculating the logical unit to which the user belongs based on the user information number; determining whether the physical unit number of each service corresponds to the logical unit to which the user belongs based on the physical unit number of each service and the logical unit to which the user belongs; if yes, determining that the unitized transaction link is normal; if no, determining that the unitized transaction link has a risk.

[0006] According to one aspect of the embodiments of this specification, obtaining the unitized transaction link data includes: obtaining the business card number submitted by the user; querying the user information number corresponding to the business card number from the mapping table between the business card number and the user information number; and adding the user information number to the initial transaction link data to obtain the unitized transaction link data.

[0007] According to one aspect of the embodiments of this specification, calculating the logical unit to which a user belongs based on the user information number includes: calculating the hash value of the user information number according to a consistent hashing algorithm; and determining the sharding interval where the hash value is located based on the hash value and a preset sharding interval.

[0008] According to one aspect of an embodiment of this specification, the method further includes: determining the logical unit to which the user belongs based on the sharding interval where the user's hash value is located and the sharding range contained in each logical unit, wherein the sharding range contained in each logical unit is determined based on the preset sharding interval and the preset number of logical units.

[0009] According to one aspect of the embodiments of this specification, determining whether the physical unit number of each service corresponds to the logical unit to which the user belongs includes: obtaining the mapping relationship between physical unit numbers and logical units; determining the logical unit number corresponding to the physical unit number of each service in the unitized transaction link data according to the mapping relationship; determining whether all physical units corresponding to all services are the same; if so, determining whether the logical units corresponding to all services are consistent with the logical unit to which the user belongs; if so, determining that the unitized transaction link is normal; if not, determining that the unitized transaction link has experienced cross-unit access and issuing a risk warning; if not, determining that the unitized transaction link has experienced cross-unit access and issuing a risk warning.

[0010] This specification also provides a unitized transaction link risk identification device, the device comprising: a unitized transaction link data acquisition unit for acquiring unitized transaction link data, the unitized transaction link data including: user information number, service, and physical unit number; a calculation unit for calculating the logical unit to which the user belongs based on the user information number; a determination unit for determining whether the physical unit number of each service corresponds to the logical unit to which the user belongs based on the physical unit number of each service and the logical unit to which the user belongs; a first determination unit for determining that the unitized transaction link is normal if it is; and a second determination unit for determining that the unitized transaction link is risky if it is not.

[0011] This specification provides a computer device including a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the unitized transaction link risk identification method.

[0012] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the unitized transaction link risk identification method.

[0013] This solution identifies risks such as cross-unit access, routing errors, excessive processing time, and incorrect timeout settings by examining the transaction links in the test environment. This significantly reduces the cost of manual monitoring, improves test accuracy, achieves precise testing, reduces unnecessary cross-unit access, and better adapts to the multi-site, multi-center deployment needs of future data centers. Attached Figure Description

[0014] 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 of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 The diagram shown is a flowchart of a unitized transaction link risk identification method according to an embodiment of this specification;

[0016] Figure 2 The diagram shown is a flowchart of a method for obtaining unitized transaction link data according to an embodiment of this specification.

[0017] Figure 3 The diagram shown is a flowchart of a method for calculating the logical unit to which a user belongs, according to an embodiment of this specification.

[0018] Figure 4 The diagram shown is a flowchart of a method for determining the fragmentation range of a logic unit according to an embodiment of this specification.

[0019] Figure 5 The diagram shown is a flowchart of a method for determining the correspondence between a service unit number and a logical unit according to an embodiment of this specification.

[0020] Figure 6 The diagram shown is a flowchart of a method for determining whether there is a risk in unitized transaction link data according to an embodiment of this specification.

[0021] Figure 7 The diagram shown is a structural schematic of a unitized transaction link risk identification device according to an embodiment of this specification.

[0022] Figure 8 The diagram shown is a schematic representation of the unitized transaction link risk identification device according to an embodiment of this specification.

[0023] Figure 9 The diagram shown is a structural schematic of a computer device according to an embodiment of this specification.

[0024] Explanation of symbols in the attached drawings:

[0025] 701. Unitized Transaction Link Data Acquisition Unit;

[0026] 7011, Business Card Number Acquisition Module;

[0027] 7012. User Information Number Query Module;

[0028] 702. Calculation Unit;

[0029] 7021, Hash value calculation module;

[0030] 7022, Segmentation Range Determination Module;

[0031] 703. Determine the unit;

[0032] 7031. Mapping Relationship Determination Module;

[0033] 7032, Logic Unit Number Determination Module;

[0034] 704. First Determined Unit;

[0035] 705. Second Determined Unit;

[0036] 902. Computer equipment;

[0037] 904, Processor;

[0038] 906. Memory;

[0039] 908. Drive mechanism;

[0040] 910. Input / Output Module;

[0041] 912. Input devices;

[0042] 914. Output devices;

[0043] 916. Presentation equipment;

[0044] 918. Graphical User Interface;

[0045] 920. Network interface;

[0046] 922. Communication link;

[0047] 924. Communication bus. Detailed Implementation

[0048] 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 specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0049] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0050] This specification provides the operational steps of the methods described in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or device products, the methods shown in the embodiments or drawings can be executed sequentially or in parallel.

[0051] It should be noted that the methods described in this specification can be used in the fields of software testing and financial technology. This specification does not limit the application areas of the unitized transaction link risk identification method and device.

[0052] Figure 1 The diagram shown is a flowchart of a unitized transaction link risk identification method according to an embodiment of this specification, which specifically includes the following steps:

[0053] Step 101: Obtain unitized transaction link data, which includes: user information number, service, and physical unit number. In this specification, the bank's distributed architecture has been transformed into a unitized architecture, recording each transaction initiated or generated by a user in personal customer services according to the business link dimension. In this specification, the use of a unitized architecture can ensure that the business traffic of transactions is evenly distributed into each unit.

[0054] Each transaction's corresponding unitized transaction link data is recorded in a distributed architecture. Compared to traditional transaction link data that stores transaction information, the unitized transaction link data also includes a user information number in addition to the traditional transaction link data.

[0055] In some embodiments of this specification, the user information number is a unique identifier for each user within the same row. The user information number can be understood as a user identity ID and can consist of numbers, letters, or characters. Unitized transaction link data containing user information numbers can clearly identify the logical unit to which the services included in that transaction link belong.

[0056] In this step, the unitized transaction link data, in addition to the user information number, also records all services involved in the user's transaction logic and the corresponding physical unit number for each service. A single transaction may involve multiple services; the physical unit number is used to package the physical resources of the infrastructure and the key support systems of the unitized architecture, defining them as basic physical units and masking the physical characteristics of the units. In some embodiments of this specification, physical units can be mapped to the physical resource domains of the infrastructure, with one physical unit directly corresponding to one data center, adapting to the multi-site, multi-center deployment requirements of data centers. For example, deploying three data centers in Shanghai, Beijing, and Guangzhou respectively corresponds to three different physical units.

[0057] Step 102: Calculate the logical unit to which the user belongs based on the user information number. In some embodiments of this specification, in order to evenly distribute a large number of transactions generated by a user to different units for processing, the logical unit corresponding to each user can be calculated based on the user information number.

[0058] Step 103: Based on the physical unit number of each service and the logical unit to which the user belongs, determine whether the physical unit number of each service corresponds to the logical unit to which the user belongs. In this specification, a transaction may involve multiple services. After each service is completed, the transaction ultimately lands on a certain server, which can be represented by a physical unit number. In some embodiments of this specification, the physical unit number can be represented by pz-unit-xx, for example: pz-unit-01, pz-unit-02, pz-unit-03, pz-unit-04, etc.

[0059] Step 104: If yes, confirm that the unitized transaction link is normal. If the physical unit numbers of all services involved in a unitized transaction link data correspond to the logical unit to which the user belongs, it means that all services of the transaction have completed a closed loop within a single physical unit, the transaction has not involved cross-unit access, and the transaction is normal.

[0060] Step 105: If not, it is determined that the unitized transaction link has a risk. If the physical unit numbers of all services involved in a unitized transaction link do not completely correspond to the logical unit to which the user belongs, it indicates that all cross-unit accesses have occurred in the transaction, and the transaction link may have a fragmentation disorder problem.

[0061] Figure 2The diagram shown is a flowchart of a method for acquiring unitized transaction link data according to an embodiment of this specification. This method uses the Ttrace component to collect unitized transaction link data. The trace component supports fine-grained transaction link monitoring across applications and platforms. Specifically, it includes the following steps:

[0062] Step 201: Obtain the user's submitted business card number. In this step, if the user has previously registered or conducted business with this bank, their business card number with this bank can be obtained directly. If the user has not previously registered with this bank, is a potential customer, or holds a business card from another bank, the logical unit to which the user belongs can be determined based on other identifiers or characteristics of the user. Specifically, data such as the user's card numbers from other banks and transaction order numbers can be processed to determine the logical unit to which the user belongs.

[0063] For example, User A holds a debit card from Bank B and transfers money to someone else at an ATM of Bank A. Bank A prepares to calculate the logical unit to which User A should belong. In this scenario, since User A is not a registered user of Bank A and Bank A does not record User A's user information number, it can read the card number of User A's debit card from Bank B, process the card number, or obtain the order number of the completed transfer, process the order number, and further calculate the logical unit to which User A should belong.

[0064] Step 202: Query the user information number corresponding to the service card number from the mapping table between service card number and user information number.

[0065] In some embodiments of this specification, if the user has already completed registration, the user information number can be obtained based on the service card number submitted by the user and a lookup table. The logical unit to which the user should belong can then be calculated based on the user information number. Specifically, the user information number can be determined by querying the lookup table between service card numbers and user information numbers.

[0066] Step 203: Add the user information number to the initial transaction link data to obtain unitized transaction link data. The initial transaction link data includes service name, service duration, SQL, server information, the service corresponding to the service name, and the physical unit number corresponding to the service.

[0067] The initial transaction link data collection includes: consuming initial transaction link data from Kafka partitions based on the trace component; and the data distribution cluster routing link data with the same trace ID to the same aggregation service node. A topology relationship (including application-to-application, cluster-to-cluster, and service-to-service topologies) is constructed based on the link data and saved to a graph database. The graph database provides graph element computation; applications need to tag transaction features offline, and these tags will be displayed in the transaction entry point via code. Topology information is queried and analyzed in real-time from the database by transaction tags and displayed through a monitoring interface.

[0068] This step involves adding the user information number obtained in step 202 to the initial transaction link data, thereby obtaining complete unitized transaction link data.

[0069] Figure 3 The diagram shown is a flowchart of a method for calculating the logical unit to which a user belongs, according to an embodiment of this specification. The method specifically includes the following steps:

[0070] Step 301: Calculate the hash value of the user information number according to the consistent hashing algorithm. In some embodiments of this specification, the consistent hashing algorithm uses a hash function to perform hash calculation on the user information number and then performs a hash mapping on the user information number. The unencrypted 64-bit hash algorithm Murmurhash is selected to maximize bit support. Specifically, the user information number is used as the key, and the hash value corresponding to the user information number is obtained using the formula: hash value = ConsistentHash(key).

[0071] This specification does not limit the type of consistent hashing algorithm. Using a consistent hashing algorithm avoids the problem of calculated hash values ​​changing when the modulus value changes in a regular modulo hashing algorithm. For example, when the number of logical units increases, using the consistent hashing algorithm in this step will not affect the already calculated hash values ​​for users.

[0072] Step 302: Determine the sharding interval where the hash value is located based on the hash value and the preset sharding interval. In this step, the preset sharding interval is determined based on the maximum hash value. This step selects an unencrypted 64-bit hash algorithm, so the maximum hash value is 2. 63 -1, the hash function value space is: [0,2] 63 -1]. The preset total number of shards is determined to be 128, resulting in a total of 128 shards. Each shard's range is: [0, 1 / 128], (1 / 128, 2 / 128]...((n-1) / 128, n / 128]...(127 / 128, 128 / 128]). Based on the hash value corresponding to the user information number, divide by the maximum hash value plus 1 (2...). 63), a value h is obtained, where h is a value between 0 and 1, and the number of shards to which the user belongs is determined according to the value.

[0073] For example: if the h value calculated from a user information number falls within the interval: 31 / 128 < h ≤ 32 / 128 (the first shard interval is 0 ≤ h ≤ 1 / 128), then the user transaction-related data corresponding to this value is allocated to the 32nd shard among 128 shards. After data sharding, the storage location of the user data can be found.

[0074] In some embodiments of this specification, the logic unit to which the user belongs is determined according to the shard interval where the user's hash value is located and the shard range included in each logic unit, wherein the shard range included in each logic unit is determined according to the preset shard interval and the preset number of logic units.

[0075] In this specification, the user data of upstream and downstream applications is uniformly sharded, logical unit division is performed on each user together with application nodes, and all upstream and downstream applications of transactions are deployed in a sharding mode, so that service traffic is distributed to each unit, and it is ensured as much as possible that service processing of the same user is always completed converged within the same unit. By actively controlling the traffic between applications and the traffic from applications to databases, and uniformly sharding the main transaction-related data, affinity deployment within the unit can be achieved, unnecessary cross-unit access is greatly reduced, the fault explosion radius is effectively controlled, the flexibility of switching is improved, and it can better adapt to the multi-location and multi-center deployment requirements of data centers.

[0076] Figure 4 is a flowchart of a method for determining a shard range of a logic unit according to an embodiment of this specification, which specifically includes the following steps:

[0077] Step 401: determine the number of shards included in each logic unit according to the preset total number of shards and the preset number of logic units. In this step, the preset total number of shards and the preset number of logic units can be determined according to application traffic, database traffic and the number of users. For example, if the preset total number of shards is 128 and the preset number of logic units is 4, then each logic unit can contain 32 shards. As Figure 3 described above, each shard corresponds to its own shard interval. After determining the hash value corresponding to the user information number, the h value is calculated, the shard interval into which the h value falls can be determined, and thus which shard the h value belongs to can be determined.

[0078] Step 402: sequentially select shards of the corresponding number of shards to form the shard range included in each logic unit.

[0079] In this step, fragments corresponding to the total number of fragments are selected sequentially from the total number of fragments to form the fragment range contained in each logical unit. For example, if the total number of fragments is 128, there are 4 logical units, and each logical unit contains 32 fragments. Then, select the 1st to 32nd slices in sequence to form the slice range of the first logic unit, for example: [0, 1 / 128], (1 / 128, 2 / 128]...(31 / 128, 32 / 128]; select the 33rd to 64th slices in sequence to form the slice range of the second logic unit, for example: (32 / 128, 33 / 128], (33 / 128, 34 / 128]...(63 / 128, 64 / 128]; select the 97th to 128th slices to form the slice range of the fourth logic unit, for example: (96 / 128, 97 / 128], (97 / 128, 98 / 128]...(127 / 128, 128 / 128).

[0080] Figure 5 The diagram shown is a flowchart of a method for determining the correspondence between a service unit number and a logical unit according to an embodiment of this specification, which specifically includes the following steps:

[0081] Step 501: Obtain the mapping relationship between physical unit numbers and logical units. In some embodiments of this specification, the mapping relationship between physical unit numbers and logical units should be one-to-one. To adapt to the deployment requirements of multi-site and multi-center data centers, one physical unit directly corresponds to one data center. For example, if four data centers are deployed in four regions, the corresponding number of physical units is also four. Physical units can be represented by physical unit numbers: for example, pz-unit-01, pz-unit-02, pz-unit-03, pz-unit-04.

[0082] In some embodiments of this specification, the mapping relationship between physical units and logical units is as follows: a one-to-one correspondence in sequence. The first physical unit corresponds to the first logical unit, the second physical unit corresponds to the second logical unit, and so on, with the fourth physical unit corresponding to the fourth logical unit. For example, a logical unit can be represented by the following logical unit numbers: for example, zone 01, zone 02, zone 03, and zone 04. According to the one-to-one mapping relationship between physical units and logical units, physical unit number pz-unit-01 corresponds to zone 01, physical unit number pz-unit-02 corresponds to zone 02, physical unit number pz-unit-03 corresponds to zone 03, and physical unit number pz-unit-04 corresponds to zone 04.

[0083] Step 502: Based on the mapping relationship, determine the logical unit number corresponding to the physical unit number of each service in the unitized transaction link data. According to the mapping relationship, the logical unit numbers corresponding to the physical unit numbers of all services involved in a transaction can be determined. When a user completes a transaction, the physical unit numbers of all services used in that transaction are recorded in the corresponding unitized transaction link data. The corresponding logical unit number is determined based on the physical unit numbers of all services.

[0084] Step 503: Determine if all logical unit numbers corresponding to all services are identical. In the unitized transaction link data corresponding to a user's transaction, multiple services / applications may be involved, and the completion of the transaction is achieved jointly by these services / applications. For example, a user binds a debit card from Bank A to the WeChat application and uses the debit card from Bank A for quick payment when topping up mobile phone credit. For Bank A, the processing logic for this transaction may include services A, B, C, D, and E. For example, service A is used to obtain and record the user's debit card number; service B is used to query the user's user information number within Bank A based on the mapping table between card number and user information number; service C is used to implement the accounting function based on the user's request; service D provides the function of sending SMS messages to the user; and service E is used to provide SMS query information, etc.

[0085] In this specification, if all upstream and downstream services of a user's transaction are functioning normally, all services should complete a closed loop within the same physical unit; that is, the physical unit number and corresponding logical unit number of all services should be identical. Therefore, it is necessary to determine whether the logical unit numbers corresponding to all services are identical.

[0086] Step 504: If yes, determine whether the logical unit numbers corresponding to all services are consistent with the logical unit to which the user belongs. If it is determined that all service logical unit numbers are the same, it means that the user's upstream and downstream services have completed a closed loop within a single physical unit. Further determine whether the physical units to which all upstream and downstream services fall correspond to the logical unit to which the user belongs.

[0087] Step 505: If not, determine that cross-unit access has occurred in the unitized transaction link and issue a risk warning.

[0088] This step is a continuation of step 503. If the logical unit numbers corresponding to all services are not all the same, for example, the upstream and downstream services of a user transaction include services A, B, C, and D. The physical unit service of services A, B, and C is pz-unit-01, and the physical unit of service D is pz-unit-03. Therefore, these four services are not on the same physical unit, and the logical units corresponding to the four services are completely identical. Thus, it is determined that this transaction involves cross-unit access, posing a risk. A risk warning will be issued to the testers for monitoring and handling.

[0089] Step 506: If yes, confirm that the unitized transaction link is normal.

[0090] This step is a continuation of step 504. If the logical unit number of the upstream and downstream services of the user's transaction is consistent with the logical unit to which the user belongs, it means that the user's upstream and downstream services and user data are processed within the same unit. The unitized transaction link has not experienced cross-unit access or routing errors, and the transaction link is normal.

[0091] Step 507: If not, determine that cross-unit access has occurred in the unitized transaction link and issue a risk warning.

[0092] This step is a continuation of step 504. If the logical unit number of the service to which the user's transaction originates is inconsistent with the logical unit to which the user belongs, it indicates that the transaction involves cross-unit access, which poses a risk. In this case, a risk warning is issued, and testers are tasked with monitoring and handling the situation.

[0093] Figure 6 The diagram shown is a flowchart of a method for determining whether unitized transaction link data poses a risk, according to an embodiment of this specification. The method specifically includes the following steps:

[0094] Step 601: Determine the database corresponding to the service based on the transaction serial number in the unitized transaction link data. In some embodiments of this specification, a certain service has a corresponding database used to store data during the storage application process. Each service corresponds to one or more databases. In some embodiments of this specification, the transaction detail table log surface is queried first. Specifically, each transaction detail table is divided into 1 / 2 sides, and they are rotated daily. For example, today's transaction detail table is side 1, tomorrow's transaction detail table is side 2, and the day after tomorrow's transaction detail table is side 1 again. Based on the transaction detail table log surface, the specific transaction detail table can be determined. The transaction detail table can be represented as: unpaytrx_dtl1, unpaytrx_dtl2. The command to query the transaction detail table log surface is as follows: select journal_flag from pub_pasct_parm. Based on the journal_flag value returned by the command, the specific transaction detail table is determined. If journal_flag = 1, the corresponding transaction details table is unpaytrx_dtl1; if journal_flag = 2, the corresponding transaction details table is unpaytrx_dtl2.

[0095] In this application, the transaction details table includes, but is not limited to, the following: transaction serial number, a field used to identify a fixed sequence number in the database, and the database name. The database containing the transaction details table is pre-defined according to fixed sequence numbers. Therefore, this step can directly determine the database sequence number based on the data in the transaction details table.

[0096] Alternatively, you can use an aggregated query tool to retrieve the transaction serial number and obtain the corresponding database sequence number. An example command is shown below:

[0097] select CURR_SET,

[0098] from unpaytrx_dtl1

[0099] where TRX_ID='2210090944359643';

[0100] Among them, unpaytrx_dtl1 is the data details table, TRX_ID is the transaction serial number, and CURR_SET is the database sequence number.

[0101] Step 602: Calculate the database sequence number using the consistent hashing algorithm, obtain the hash value corresponding to the database sequence number, and determine the sharding interval in which the database belongs. This step is similar to step 301, processing the database sequence number into data of the same length as the user information number (e.g., 15 digits), and calculating the hash value of the database sequence number using the consistent hashing algorithm. Furthermore, based on the hash value of the database sequence number and the preset sharding interval, determine the sharding interval in which the hash value of the database sequence number belongs. For example, if the total number of shards is 128, and the calculated hash value h of the database sequence number falls within the interval (52 / 128, 53 / 128), it indicates that the hash value of the database sequence number is in the 53rd sharding interval.

[0102] Step 603: Determine whether the sharding range of the database is consistent with the logical unit to which the user belongs. This step specifically includes: determining the logical unit to which the database falls based on the database sharding range; and determining whether the logical unit to which the database falls is consistent with the logical unit to which the user belongs.

[0103] Based on the sharding range where the database is located, determine which logical unit that sharding range belongs to. In this step, each logical unit contains different sharding ranges. If there are 4 logical units, and as described above, each logical unit includes 32 sharding ranges, then the database in step 602 is in the 53rd sharding range, actually belonging to the 2nd logical unit. Then determine whether the logical unit to which the user belongs is also the 2nd logical unit.

[0104] Step 604: If yes, confirm that the unitized transaction link data is normal. If the logical unit to which the user belongs is consistent with the logical unit to which the database belongs in the sharding interval, it indicates that the service has not performed a cross-unit call, and the transaction is normal.

[0105] Step 605: If not, determine that the unitized transaction link data has a risk. If the logical unit to which the user belongs is inconsistent with the logical unit to which the database belongs in the sharding interval, it indicates that the service has undergone cross-unit calls or sharding routing, and the transaction has a risk.

[0106] like Figure 7 The diagram shown is a structural schematic of a unitized transaction link risk identification device according to an embodiment of this specification. The basic structure of the unitized transaction link risk identification device is illustrated in this diagram. The functional units and modules can be implemented in software, or they can be implemented using general-purpose chips or specific chips. The device specifically includes:

[0107] Unitized transaction link data acquisition unit 701 is used to acquire unitized transaction link data, which includes: user information number, service, and physical unit number;

[0108] The calculation unit 702 is used to calculate the logical unit to which the user belongs based on the user information number;

[0109] The determining unit 703 is used to determine whether the physical unit number of each service corresponds to the logical unit to which the user belongs, based on the physical unit number of each service and the logical unit to which the user belongs;

[0110] The first determining unit 704 is used to determine, if yes, that the unitized transaction link is normal;

[0111] The second determining unit 705 is used to determine, if not, that there is a risk in the unitized transaction link.

[0112] This solution identifies risks such as cross-unit access, routing errors, excessive processing time, and incorrect timeout settings by inspecting the transaction chain in the test environment. This reduces manual monitoring costs, improves testing accuracy, and achieves precise testing. It proactively controls inter-application traffic and application-to-database traffic, unifies the sharding strategy for key user transaction-related data, effectively controls the probability of failures and the radius of failure blasts, enhances switchover flexibility, better adapts to the multi-site, multi-center deployment requirements of data centers, and leverages the advantages of geographically dispersed active-active architectures.

[0113] As one embodiment of this specification, reference may also be made to, for example, Figure 8 The diagram shown is a schematic representation of the specific structure of the unitized transaction link risk identification device in this embodiment.

[0114] As one embodiment of this specification, the unitized transaction link data acquisition unit 701 further includes:

[0115] The business card number acquisition module 7011 is used to acquire the business card number submitted by the user.

[0116] The user information number query module 7012 is used to query the user information number corresponding to the service card number from the mapping table between the service card number and the user information number.

[0117] As one embodiment of this specification, the computing unit 702 further includes:

[0118] The hash value calculation module 7021 is used to calculate the hash value of the user information number according to the consistent hashing algorithm;

[0119] The sharding interval determination module 7022 is used to determine the sharding interval where the hash value is located based on the hash value and the preset sharding interval.

[0120] As one embodiment of this specification, the determining unit 703 further includes:

[0121] The mapping relationship determination module 7031 is used to obtain the mapping relationship between physical unit number and logical unit;

[0122] The logical unit number determination module 7032 is used to determine the logical unit number corresponding to the physical unit number of each service in the unitized transaction link data according to the mapping relationship.

[0123] like Figure 9 The computer device 902, as shown in the embodiment of this specification, provides a computer device that can execute the risk identification method for unitized transaction links described in this specification. The computer device 902 may include one or more processors 904, such as one or more central processing units (CPUs), each of which can implement one or more hardware threads. The computer device 902 may also include any memory 906 for storing information of any kind, such as code, settings, data, etc. Non-limitingly, for example, the memory 906 may include any type of RAM, any type of ROM, flash memory, hard disk, optical disk, etc. More generally, any memory can use any technology to store information. Further, any memory can provide volatile or non-volatile retention of information. Further, any memory can represent a fixed or removable component of the computer device 902. In one case, when the processor 904 executes associated instructions stored in any memory or combination of memories, the computer device 902 can perform any operation of the associated instructions. The computer device 902 also includes one or more drive mechanisms 908 for interacting with any memory, such as hard disk drive mechanisms, optical disk drive mechanisms, etc.

[0124] Computer device 902 may also include an input / output module 910 (I / O) for receiving various inputs (via input device 912) and providing various outputs (via output device 914). A specific output mechanism may include a presentation device 916 and an associated graphical user interface (GUI) 918. In other embodiments, the input / output module 910 (I / O), input device 912, and output device 914 may be omitted, and the device may function solely as a computer device within a network. Computer device 902 may also include one or more network interfaces 920 for exchanging data with other devices via one or more communication links 922. One or more communication buses 924 couple the components described above together.

[0125] Communication link 922 can be implemented in any way, such as via a local area network (LAN), a wide area network (WAN) (e.g., the Internet), a point-to-point connection, or any combination thereof. Communication link 922 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0126] Corresponding to Figures 1 to 6 In addition to the methods described above, embodiments of this specification also provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the methods described above.

[0127] It should be understood that in the various embodiments of this specification, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this specification.

[0128] It should also be understood that, in the embodiments of this specification, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this specification generally indicates that the preceding and following related objects have an "or" relationship.

[0129] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this specification.

[0130] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0131] In the several embodiments provided in this specification, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, or they may be electrical, mechanical, or other forms of connection.

[0132] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments described in this specification, depending on actual needs.

[0133] Furthermore, the functional units in the various embodiments of this specification can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0134] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this specification, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this specification. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0135] This specification uses specific embodiments to illustrate the principles and implementation methods of this specification. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this specification. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this specification. Therefore, the content of this specification should not be construed as a limitation of this specification.

Claims

1. A method for identifying risks in a unitized transaction chain, characterized in that, The method includes: Acquire unitized transaction link data, which includes: user information number, service, and physical unit number; wherein, the user information number is the user identity ID, composed of numbers, letters, or characters; the service is all services of the user's transaction logic; Calculate the logical unit to which the user belongs based on the user information number; Based on the physical unit number of each service and the logical unit to which the user belongs, determine whether the physical unit number of each service corresponds to the logical unit to which the user belongs; If so, confirm that the unitized transaction link is normal; If not, it is determined that the unitized transaction link has a risk.

2. The method for identifying risks in a unitized transaction chain according to claim 1, characterized in that, The acquisition of unitized transaction link data includes: Obtain the business card number submitted by the user; From the mapping table between service card number and user information number, query the user information number corresponding to the service card number; The user information number is added to the initial transaction link data to obtain unitized transaction link data.

3. The method for identifying risks in a unitized transaction chain according to claim 2, characterized in that, Calculating the logical unit to which the user belongs based on the user information number includes: Calculate the hash value of the user information number using the consistent hashing algorithm; Based on the hash value and the preset sharding interval, the sharding interval in which the hash value is located is determined.

4. The method for identifying risks in a unitized transaction chain according to claim 3, characterized in that, The method further includes: The logical unit to which the user belongs is determined based on the sharding range of the user's hash value and the sharding range contained in each logical unit.

5. The method for identifying risks in a unitized transaction chain according to claim 4, characterized in that, Determining the fragmentation range of a logic unit includes: Based on the preset total number of shards and the preset number of logical units, determine the number of shards contained in each logical unit; Select the corresponding number of fragments in sequence to form the fragment range contained in each logical unit.

6. The method for identifying risks in a unitized transaction chain according to claim 5, characterized in that, Determining whether the physical unit number of each service corresponds to the logical unit to which the user belongs includes: Obtain the mapping relationship between physical unit numbers and logical units; Based on the mapping relationship, the logical unit number corresponding to the physical unit number of each service in the unitized transaction link data is determined respectively; Determine whether all services correspond to the same physical unit; If not, if cross-unit access is confirmed in the unitized transaction link, a risk warning will be issued. If so, determine whether the logical unit corresponding to all services is consistent with the logical unit to which the user belongs; If so, confirm that the unitized transaction link is normal; If not, it is determined that cross-unit access has occurred in the unitized transaction link, and a risk warning is issued.

7. A method for identifying risks in a unitized transaction chain, characterized in that, The method is applied to each service, including: determining the database corresponding to the service based on the transaction serial number in the unitized transaction link data; The database sequence number is calculated using the consistent hashing algorithm to obtain the hash value corresponding to the database sequence number, and the sharding interval in which the database is located is determined. Based on the database's partitioning range, determine the logical unit to which the database falls; Determine whether the logical unit into which the database is located is consistent with the logical unit to which the user belongs; If so, confirm that the unitized transaction link data is normal; If not, it is determined that the unitized transaction link data poses a risk.

8. A unitized transaction link risk identification device, characterized in that, The device includes: A unitized transaction link data acquisition unit is used to acquire unitized transaction link data, which includes: user information number, service, and physical unit number; wherein, the user information number is a user identity ID, composed of numbers, letters, or characters; the service is all services of the user's transaction logic; A calculation unit is used to calculate the logical unit to which the user belongs based on the user information number; The determining unit is used to determine whether the physical unit number of each service corresponds to the logical unit to which the user belongs, based on the physical unit number of each service and the logical unit to which the user belongs; The first determining unit is used to determine, if yes, that the unitized transaction link is normal; The second determining unit is used to determine, if not, that there is a risk in the unitized transaction link.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images