A method and apparatus for processing a transaction request and a transaction transfer system

Abstract

The present application discloses a method, apparatus, and transaction transfer system for processing transaction requests. The method is applied to each transaction transfer server in the transaction transfer system and includes: obtaining a system policy identifier, where the system policy identifier is a policy identifier that takes effect in the transaction transfer system; updating a local policy identifier according to the system policy identifier, where the local policy identifier is a policy identifier that takes effect in each transaction transfer server; processing a received transaction request according to the updated local policy identifier; and determining reporting information according to the transaction request processing result. By setting a unified system policy identifier for the entire transaction transfer system, the present application ensures that each transaction transfer server in the transaction transfer system can obtain the same local policy identifier. This system downgrading mechanism, compared with the existing local automatic downgrading mechanism, ensures the consistency of processing the same transaction request and avoids problems such as non-idempotent processing of transaction requests.

Description

Technical Field

[0001] This application relates to the field of financial technology, and in particular, to a method and device for processing transaction requests and a transaction transfer system. Background Art

[0002] When the existing clearing platform processes transaction requests, it mainly adopts the following method: First, after the server in the target data center receives a transaction request, the transaction transfer system in the server determines the business logic of the transaction according to the message number of the transaction request; then, the data of the transaction request is sent to the transaction verification system for legality and business logic verification. For transaction requests that fail the verification, they are rejected, and for transaction requests that pass the verification, the transaction data can be forwarded to the bank front-end module of this data center. The bank front-end module encrypts and assembles the message and then sends it to the target bank; after receiving the assembled message, the target bank parses the message to obtain the message information, and finally performs verification and posting processing according to the transaction information and business logic in the message.

[0003] However, the existing method for processing transaction requests has problems such as the inability to perform idempotent processing of transaction requests and a relatively high transaction loss rate. Summary of the Invention

[0004] Embodiments of this application provide a method and device for processing transaction requests and a transaction transfer system to reduce the transaction loss rate and transaction risk.

[0005] Embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a method for processing transaction requests, which is applied to each transaction transfer server in a transaction transfer system. Among them, the method includes:

[0007] Obtain a system policy identifier, where the system policy identifier is a policy identifier that takes effect in the transaction transfer system;

[0008] Update the local policy identifier according to the system policy identifier, where the local policy identifier is a policy identifier that takes effect in each transaction transfer server;

[0009] Process the received transaction request according to the updated local policy identifier;

[0010] Determine the reporting information according to the transaction request processing result.

[0011] Optionally, the transaction transfer system further includes a preset Redis database, and the system policy identifier is stored in the Redis database. The obtaining of the system policy identifier includes:

[0012] Determine the Redis status identifier of the Redis database;

[0013] When the Redis status identifier indicates that the Redis database is normal, request the Redis database to obtain the system policy identifier.

[0014] Optionally, the method further includes:

[0015] Determine the number of failed requests according to the result of the request to the Redis database;

[0016] If the number of failed requests reaches a first threshold within a preset time, update the Redis status identifier to a Redis failure identifier, where the Redis failure identifier is used to indicate that the Redis database has failed.

[0017] Optionally, the method further includes:

[0018] Report the reported information to the Redis database so that the Redis database can update the system policy identifier according to the reported information;

[0019] Determine the number of failed reports according to the reporting result;

[0020] If the number of failed reports reaches a second threshold, update the Redis status identifier to a Redis failure identifier.

[0021] Optionally, the system policy identifier includes a downgrade identifier, and the downgrade identifier includes a system exception downgrade identifier. The updating the local policy identifier according to the system policy identifier includes:

[0022] If the system policy identifier is the system exception downgrade identifier, update the local policy identifier to the system exception downgrade identifier;

[0023] The processing of the received transaction request according to the transaction request processing policy corresponding to the updated local policy identifier includes:

[0024] According to the system exception downgrade identifier, release the received transaction request to the transaction processing system for transaction processing.

[0025] Optionally, the transaction request carries an institution identifier. Before releasing the received transaction request to the transaction processing system for transaction processing according to the system exception downgrade identifier, the method further includes:

[0026] Determine whether the institution identifier carried in the transaction request is in the blacklist;

[0027] If it exists, directly reject the transaction request;

[0028] If it does not exist, release the transaction request to the transaction processing system.

[0029] Optionally, the system policy identifier includes a downgrade identifier, and the downgrade identifier includes a business rejection downgrade identifier. The updating of the local policy identifier according to the system policy identifier includes:

[0030] If the system policy identifier is the business rejection downgrade identifier, update the local policy identifier to the business rejection downgrade identifier;

[0031] The processing of the received transaction request according to the transaction request processing policy corresponding to the updated local policy identifier includes:

[0032] Directly reject the transaction request according to the business rejection downgrade identifier.

[0033] Optionally, the system policy identifier includes a non-downgrade identifier. The updating of the local policy identifier according to the system policy identifier includes:

[0034] If the system policy identifier is the non-downgrade identifier, update the local policy identifier to the non-downgrade identifier;

[0035] The processing of the received transaction request according to the transaction request processing policy corresponding to the updated local policy identifier includes:

[0036] Forward the received transaction request to the transaction verification system for verification according to the non-downgrade identifier.

[0037] Optionally, the determining of the reporting information according to the transaction request processing result includes:

[0038] Receive the transaction verification result returned by the transaction verification system. The types of the transaction verification result include transaction verification passed, transaction verification system exception, and business rejection;

[0039] Statistical system exception times and business rejection times according to the transaction verification result, and statistical interface access times according to the received transaction request;

[0040] Use at least one of the system exception times, the business rejection times, and the interface access times as the reporting information.

[0041] Optionally, the method further includes:

[0042] If the system policy identifier cannot be obtained, directly determine the local policy identifier according to the reporting information.

[0043] Optionally, the reported information includes the number of system exceptions, the number of service rejections, and the number of interface accesses. If the system policy identifier cannot be obtained, directly determining the local policy identifier according to the reported information includes:

[0044] Calculating a first failure rate of the transaction request according to the number of system exceptions and the number of interface accesses;

[0045] If the number of system exceptions triggers a system exception number threshold and the first failure rate triggers a first failure rate threshold, updating the local policy identifier to the system exception downgrade identifier.

[0046] Optionally, if the system policy identifier cannot be obtained, directly determining the local policy identifier according to the reported information includes:

[0047] Calculating a second failure rate of the transaction request according to the number of service rejections and the number of interface accesses;

[0048] If the number of service rejections triggers a service rejection number threshold and the second failure rate triggers a second failure rate threshold, updating the local policy identifier to the service rejection downgrade identifier.

[0049] In a second aspect, an embodiment of the present application provides a processing device for a transaction request, which is applied to each transaction transfer server in a transaction transfer system, wherein the device is used to implement any one of the foregoing methods.

[0050] In a third aspect, an embodiment of the present application provides a transaction transfer system, including a plurality of transaction transfer servers, and the transaction transfer server includes:

[0051] A processor; and

[0052] A memory arranged to store computer-executable instructions, and when the executable instructions are executed, the processor executes any one of the foregoing methods.

[0053] In a fourth aspect, an embodiment of the present application provides a transaction system, including: a transaction transfer system, a transaction verification system, and a transaction processing system,

[0054] The transaction transfer system includes a plurality of transaction transfer servers, and each transaction transfer server includes the foregoing device.

[0055] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, and the computer-readable storage medium stores one or more programs. When the one or more programs are executed by a transaction transfer server including a plurality of application programs, the transaction transfer server is caused to execute any one of the foregoing methods.

[0056] The above at least one technical solution adopted in the embodiments of the present application can achieve the following beneficial effects: The method for processing a transaction request in the embodiments of the present application is applied to each transaction transfer server in a transaction transfer system. When processing a transaction request, first obtain a system policy identifier, where the system policy identifier is a policy identifier effective in the transaction transfer system; then update the local policy identifier according to the system policy identifier, where the local policy identifier is a policy identifier effective in each transaction transfer server; then process the received transaction request according to the updated local policy identifier; and finally determine the reported information according to the transaction request processing result. By setting a unified system policy identifier for the entire transaction transfer system in the present application, it is ensured that each transaction transfer server in the transaction transfer system can obtain the same local policy identifier. This system downgrading mechanism can reduce the transaction loss rate to a certain extent compared with the existing local automatic downgrading mechanism, and at the same time ensure the consistency of processing the same transaction request, avoiding problems such as non-idempotent processing of transaction requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] The drawings described herein are used to provide a further understanding of the present application and form a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation to the present application. In the drawings:

[0058] Figure 1 is a schematic structural diagram of a transaction system according to an embodiment of the present application;

[0059] Figure 2 is a logic block diagram of a local automatic downgrading mechanism in the prior art;

[0060] Figure 3 is a schematic flow diagram of a method for processing a transaction request according to an embodiment of the present application;

[0061] Figure 4 is a schematic structural diagram of a transaction transfer system according to an embodiment of the present application;

[0062] Figure 5 is a logic block diagram of a method for processing a transaction request according to an embodiment of the present application;

[0063] Figure 6 is a schematic structural diagram of a device for processing a transaction request according to an embodiment of the present application;

[0064] Figure 7 is a schematic structural diagram of another transaction transfer system according to an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0065] To make the objectives, technical solutions and advantages of the present application more clear, the technical solutions of the present application will be clearly and completely described below in conjunction with specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only a part rather than all of the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present application without making creative efforts shall fall within the scope of protection of the present application.

[0066] The technical solutions provided by each embodiment of the present application will be described in detail below with reference to the drawings.

[0067] As Figure 1 shown, a schematic structural diagram of a trading system according to an embodiment of the present application is provided, which mainly involves the following three subsystems: a trading transfer system, a trading verification system, and a trading processing system. The trading transfer system is mainly used to receive trading requests sent by the user terminal and forward the trading requests to the trading verification system for verification; the trading verification system is mainly used to verify the legality, business type, business logic, etc. of the content of the trading request. For example, whether the amount of the trading request exceeds the maximum limit, whether the business type of the trading request meets the requirements, etc.; the trading processing system is mainly used to perform specific business processing on the requests verified by the trading verification system. In the embodiments of the present application, the trading transfer system and the trading verification system described above are mainly involved.

[0068] In an actual business scenario, when the trading transfer system calls the trading verification system, if there are multiple trading requests that time out or multiple trading requests are rejected, etc., this transaction will be lost. To reduce the trading loss rate, a local automatic downgrading mechanism is introduced to process trading requests.

[0069] As Figure 2As shown in the figure, a logic block diagram of a local automatic downgrading mechanism is provided. First, the downgrading identifier of the local transaction transfer server is determined. If it is a downgrading identifier, the institutional identifier carried in the transaction request is compared with the blacklist. If it is not in the blacklist, the transaction request is directly released. If it is in the blacklist, the transaction request is directly rejected. If it is a non-downgrading identifier, the transaction request is sent to the transaction verification system, and then the response of the transaction verification system is synchronously waited for. If there are problems such as the transaction verification system being abnormal or the service being rejected, the total number of times of the transaction verification system being abnormal or the service being rejected will be counted. When the total number reaches the threshold, the automatic downgrading of the local transaction transfer server is automatically triggered, and finally the downgrading identifier of the local transaction transfer server is updated. For the situation where the transaction verification system is abnormal, a fallback strategy can be further used for judgment. The fallback strategy can be understood as a processing rule agreed in advance according to the institution, transaction type, etc. For the transaction request in the case of the transaction verification system being abnormal, it can be determined whether to release the transaction request or reject the transaction request through the fallback strategy.

[0070] However, the above solution may have the following problems:

[0071] 1) The current automatic downgrading is within the scope of a single transaction transfer server (usually there are hundreds of servers in the computer room where the transaction transfer system is located). It is easy to have a situation where the transaction transfer system continuously loses transactions for a period of time, resulting in a relatively high transaction loss rate. The reason is that these lost transactions may be distributed on each transaction transfer server and none of them trigger the automatic downgrading of a single transaction transfer server.

[0072] 2) The automatic downgrading mechanism takes effect locally on each transaction transfer server, which may cause the downgrading states of the transaction transfer applications on different servers in the same computer room to be inconsistent, resulting in the inability to process transaction requests idempotently and also causing difficulties in operation and maintenance processing.

[0073] 3) The current method for processing transaction requests simultaneously counts business rejections (i.e., the situation where the transaction verification system clearly responds with a rejection) and transaction verification system abnormalities (such as communication abnormalities). As the transaction verification system becomes gradually improved and stable, it is possible that due to normal business rejections, the automatic downgrading is triggered and the transaction request is released, which may then miss some truly risky transactions.

[0074] Based on this, the embodiment of the present application provides a method for processing transaction requests, which is executed by a transaction transfer server in a transaction transfer system. Among them, as Figure 3 shown, the method includes the following steps S310 to step S340:

[0075] Step S310, obtain a system policy identifier, where the system policy identifier is a policy identifier that takes effect on the transaction transfer system.

[0076] like Figure 4 As shown, the transaction transfer system of the embodiment of the present application includes multiple transaction transfer servers, each of which can be used to execute the transaction request processing method of the embodiment of the present application. Considering the access overhead caused by processing transaction requests across computer rooms, the above-mentioned transaction transfer servers can be deployed in the same computer room.

[0077] For any of the above-mentioned transaction transfer servers, after receiving a transaction request, it can first obtain the system policy identifier of the transaction transfer system where the transaction transfer server is located. The system policy identifier here can be understood as the processing strategy identifier adopted by the entire transaction transfer system for the received transaction request, that is, the object of the system policy identifier is all transaction transfer servers in a computer room, that is, the entire computer room dimension.

[0078] Step S320: updating the local policy identifier according to the system policy identifier, wherein the local policy identifier is a policy identifier effective on each transaction transfer server.

[0079] Each transaction transfer server will have its own local policy identifier. The local policy identifier here can be understood as the processing policy identifier adopted by any transaction transfer server for the transaction requests it receives. That is, the local policy identifier is aimed at a certain transaction transfer server, that is, a single machine dimension.

[0080] In actual business scenarios, due to network delays or failures, a user may initiate multiple transaction requests for the same transaction. Each transaction request may reach a different transaction relay server. If the local policy identifiers of these transaction relay servers are inconsistent, the same transaction request will result in different processing results. Therefore, to avoid this problem, after obtaining the system policy identifier of the transaction relay system, any of the above transaction relay servers needs to update its local policy identifier based on the system policy identifier. This ensures that the local policy identifiers of all transaction relay servers in a computer room remain consistent, thereby ensuring idempotent processing of the same transaction request.

[0081] Step S330: Process the received transaction request according to the updated local policy identifier.

[0082] Each transaction transfer server can perform various processing on the received transaction requests, such as forwarding the transaction request to the transaction verification system for verification, or sending the transaction request directly to the transaction processing system for specific business processing, or directly rejecting the transaction request. The specific processing method can be determined based on the updated local policy identifier.

[0083] Step S340: Determine the reporting information according to the processing result of the transaction request.

[0084] The system policy identifier in the embodiment of the present application can be updated according to the processing results of transaction requests by each transaction transfer server to meet the processing requirements for transaction requests in different business scenarios. The processing results of the transaction requests here can include the result that the transaction request passes, the result that the transaction request is rejected, or an unclear processing result. In the actual business scenario, due to reasons such as the abnormality of the transaction transfer system, the current transaction loss rate of the transaction transfer system is relatively high. Therefore, the above reporting information of the transaction request processing result can be reported, so as to determine whether to update the system policy identifier of the transaction transfer system according to the reported information later, so as to adjust the processing policy for transaction requests and reduce the transaction loss rate.

[0085] By setting a unified system policy identifier for the entire transaction transfer system in the present application, it is ensured that each transaction transfer server in the transaction transfer system can obtain the same local policy identifier. Compared with the existing local automatic downgrading mechanism, this system downgrading mechanism ensures the consistency of the processing of the same transaction request and avoids problems such as the inability to perform idempotent processing of transaction requests.

[0086] In the actual business scenario, the system policy identifier of the transaction transfer system can be obtained by executing an asynchronous task, for example, executing an asynchronous task once per second, so as to ensure that other processes are not affected.

[0087] In an embodiment of the present application, the transaction transfer system further includes a preset Redis database, and the system policy identifier is stored in the Redis database. The obtaining of the system policy identifier includes: determining the Redis status identifier of the Redis database; and requesting to obtain the system policy identifier from the Redis database when the Redis status identifier indicates that the Redis database is normal.

[0088] As Figure 4 shown, the transaction transfer system in the embodiment of the present application further includes a preset Redis database (a key-value database). The Redis database can establish connections with each transaction transfer server in the transaction transfer system, and is mainly used to receive and process the information reported by each transaction transfer server and to manage and update the system policy identifier of the transaction transfer system separately.

[0089] In an actual business scenario, due to database failures or other reasons, the Redis database may be temporarily unavailable. Therefore, when obtaining the system policy identifier stored in the Redis database, the Redis status identifier of the Redis database can be determined first. The Redis status identifier is mainly used to represent the current state of the Redis database, such as the normal state or the failure state. Then, based on the Redis status identifier of the Redis database, the current state of the Redis database can be determined. If the Redis database is currently in the normal state, a request can be sent to the Redis database to obtain the system policy identifier.

[0090] In an embodiment of the present application, the method further includes: determining the number of request failures according to the result of the request to the Redis database; if the number of request failures reaches a first threshold within a preset time, updating the Redis status identifier to a Redis failure identifier, where the Redis failure identifier is used to indicate that the Redis database has failed.

[0091] The result of the request to the Redis database may include a successful request result, that is, successfully obtaining the system policy identifier of the transaction transfer system, or a request failure result, that is, not obtaining the system policy identifier of the transaction transfer system. The reason for the request failure may be due to a failure of the transaction transfer server or the Redis database itself, or due to a network connection exception. Therefore, here, in order to determine whether the request failure result is related to the Redis database itself to reduce the possibility of misjudgment, the number of request failures within a period of time can be counted. If the number of request failures to the Redis database within this period reaches the first threshold, it means that it is very likely that the request failure is caused by the Redis database itself. Therefore, at this time, the Redis status identifier can be updated to a Redis failure identifier to indicate that the Redis database has failed.

[0092] In an embodiment of the present application, the method further includes: reporting the reported information to the Redis database so that the Redis database can update the system policy identifier according to the reported information; determining the number of reporting failures according to the reporting result; if the number of reporting failures reaches a second threshold, updating the Redis status identifier to a Redis failure identifier.

[0093] As mentioned above, the Redis database is mainly used to manage and update the system policy identifier separately. Therefore, after obtaining the reported information according to the transaction request processing result, the reported information can be reported to the Redis database, and then the Redis database can further analyze whether the system policy identifier needs to be updated.

[0094] However, since the reporting process also involves data transmission between the transaction transfer server and the Redis database, it is possible that the reporting fails, that is, the reported information is not successfully written into the Redis database. Similarly, the reason for the reporting failure may also be due to the failure of the transaction transfer server, the failure of the Redis database, or the abnormal network connection. Therefore, here, in order to determine whether the result of the reporting failure is related to the failure of the Redis database itself and reduce the possibility of misjudgment, the number of reporting failures can be counted. If the number of reporting failures reaches the second threshold, it indicates that it is very likely that the reporting failure is caused by the failure of the Redis database itself. So at this time, the Redis status flag can also be updated to the Redis failure flag.

[0095] It should be noted that the sizes of the "first threshold" and "second threshold" in the above embodiments can be flexibly set according to actual business requirements. Of course, only one threshold can also be set to uniformly judge the sum of the number of request failures and the number of reporting failures.

[0096] In an embodiment of the present application, the system policy flag includes a downgrade flag, and the downgrade flag includes a system exception downgrade flag. The updating the local policy flag according to the system policy flag includes: if the system policy flag is the system exception downgrade flag, then updating the local policy flag to the system exception downgrade flag; the processing the received transaction request according to the transaction request processing policy corresponding to the updated local policy flag includes: releasing the received transaction request to the transaction processing system for transaction processing according to the system exception downgrade flag.

[0097] Under normal circumstances, when the transaction transfer system receives a transaction request, it will forward it to the transaction verification system for verifying the transaction legality and business logic, etc. However, due to the occurrence of some abnormal situations, the transaction request cannot be responded to in time or is rejected multiple times, which will lead to the loss of this transaction and a relatively high transaction loss rate of the entire transaction transfer system. Therefore, in order to reduce the transaction loss rate, it can be dealt with by downgrading. The specific object of downgrading is the transaction transfer application deployed on each transaction transfer server. Whether to downgrade the transaction transfer application can be determined by its corresponding downgrade flag or non-downgrade flag. The downgrade flag is further divided into a system exception downgrade flag obtained due to the exception of the transaction verification system and a business rejection downgrade flag obtained due to the rejection of the transaction request.

[0098] Of course, it should be noted that the above process of downgrading the transaction transfer application is only temporary. In order to ensure the security of transactions, after triggering the downgrade, the operation and maintenance personnel can be notified to conduct fault troubleshooting in time to restore the normal transaction verification process.

[0099] Both the downgrade flag and the non-downgrade flag are in terms of the dimension of the entire transaction transfer system. If the system policy flag of the transaction transfer system obtained in the embodiment of the present application is the system exception downgrade flag, it indicates that an abnormal situation has occurred in the transaction verification system itself. To reduce transaction losses, the transaction verification step can be temporarily omitted, that is, the local policy flag can be updated to the system exception downgrade flag, and the local policy flags of all transaction transfer servers in the transaction transfer system will be synchronously updated to the system exception downgrade flag. In this way, each transaction transfer server will adopt a processing policy of directly releasing the received transaction requests to the transaction processing system, thereby ensuring the consistency of the processing results of the same transaction request.

[0100] In an embodiment of the present application, the transaction request carries an institution identifier. Before releasing the received transaction request to the transaction processing system for transaction processing according to the system exception downgrade flag, the method further includes: determining whether the institution identifier carried in the transaction request is in the blacklist; if so, directly rejecting the transaction request; if not, releasing the transaction request to the transaction processing system.

[0101] As described above, generally, if the local policy flag has been updated to the system exception downgrade flag, the processing policy of directly releasing the subsequent received transaction requests to the transaction processing system will be adopted. However, considering the security of transactions and avoiding major transaction losses, before releasing the subsequent received transaction requests to the transaction processing system for transaction processing, the blacklist can be used to verify the legitimacy of these transaction requests. The blacklist usually stores a list of institutions that are not allowed to conduct transactions. If the institution identifier carried in the received transaction request is in the blacklist, the transaction request is directly rejected, and subsequent manual intervention can be carried out for processing. If it is not in the blacklist, the transaction request can be released to the transaction processing system for specific business processing.

[0102] In an embodiment of the present application, the system policy flag includes a downgrade flag, and the downgrade flag includes a service rejection downgrade flag. Updating the local policy flag according to the system policy flag includes: if the system policy flag is the service rejection downgrade flag, updating the local policy flag to the service rejection downgrade flag; processing the received transaction request according to the transaction request processing policy corresponding to the updated local policy flag includes: directly rejecting the transaction request according to the service rejection downgrade flag.

[0103] If the system policy identifier of the transaction transfer system obtained in the embodiment of the present application is a business rejection downgrade identifier, it indicates that the transaction verification system has clearly rejected the transaction request multiple times. To avoid the transaction verification system receiving the same transaction request again in the future, the local policy identifier can be updated to the business rejection downgrade identifier, and the local policy identifiers of all transaction transfer servers in the transaction transfer system will be synchronously updated to the business rejection downgrade identifier. In this way, each transaction transfer server will adopt a direct rejection processing strategy for the subsequent received transaction requests, thereby ensuring the consistency of the processing results of the same transaction request.

[0104] In an embodiment of the present application, the system policy identifier includes a non-downgrade identifier. The updating of the local policy identifier according to the system policy identifier includes: if the system policy identifier is the non-downgrade identifier, then updating the local policy identifier to the non-downgrade identifier; the processing of the received transaction request according to the transaction request processing strategy corresponding to the updated local policy identifier includes: forwarding the received transaction request to the transaction verification system for verification according to the non-downgrade identifier.

[0105] If the system policy identifier of the obtained transaction transfer system is a non-downgrade identifier, then the local policy identifier is also updated to the non-downgrade identifier, and the subsequent received transaction requests can be normally forwarded to the transaction verification system for verification.

[0106] In an embodiment of the present application, the determining of the reporting information according to the transaction request processing result includes: receiving the transaction verification result returned by the transaction verification system, and the types of the transaction verification result include transaction verification passed, transaction verification system exception, and business rejection; counting the number of system exceptions and the number of business rejections according to the transaction verification result, and counting the number of interface accesses according to the received transaction requests; using at least one of the number of system exceptions, the number of business rejections, and the number of interface accesses as the reporting information.

[0107] The verification result returned by the transaction verification system can include three situations: transaction verification passed, transaction verification system exception, and business rejection. Transaction verification passed indicates that the transaction request meets the requirements of legality and business logic, etc., and subsequent business processing can be carried out; transaction verification system exception indicates that the transaction verification system has failed, resulting in the inability to respond to the transaction request in a timely manner. Business rejection indicates that after the transaction verification system verifies the legality and business logic, etc. of the transaction request, it is considered that the transaction request does not meet the requirements of legality or business logic, etc., and the transaction request is directly rejected, and subsequent business processing cannot be carried out temporarily.

[0108] When a transaction verification system exception or a business rejection occurs, it means that the transaction was not successful, that is, a transaction loss occurred. Therefore, in order to reduce the transaction loss rate and increase the transaction volume of the business, the number of system exceptions and business rejections can be counted according to the verification results returned by the transaction verification system at a certain time, such as every minute. At the same time, the number of interface accesses can be counted according to the received transaction requests. Then, the three indicators of system exceptions, business rejections and interface accesses are reported as reporting information to the Redis database in the transaction verification system, so that the Redis database can analyze and process the reported information to determine whether to adjust the system policy identifier to reduce the transaction loss rate.

[0109] If the Redis database fails to update the system policy identifier, it is necessary to make the update successful as much as possible. For example, a retry mechanism can be invoked to retry twice after the first update failure, making the update successful as much as possible. If the retry mechanism is also unsuccessful, an alarm is triggered and manual intervention is required.

[0110] In one embodiment of the present application, the method further includes: if the system policy identifier cannot be obtained, directly determining the local policy identifier based on the reported information.

[0111] As in the aforementioned embodiment, the system policy identifier can be stored in the Redis database for management. If the Redis database fails, the system policy identifier cannot be obtained from the Redis database. At this time, the local automatic downgrade mechanism can be called to process the transaction request. The local automatic downgrade mechanism is aimed at a single transaction transfer server. Although the local automatic downgrade mechanism may have the aforementioned problems such as inconsistent downgrade identifiers of different transaction transfer servers, resulting in the inability to idempotently process transaction requests, in order to reduce the transaction loss rate, the local automatic downgrade mechanism can be used in abnormal situations such as Redis database failure to avoid strong dependence on the system downgrade mechanism.

[0112] By default, the local automatic degradation mechanism has a lower priority than the system degradation mechanism. That is, the system degradation mechanism is called first. The local automatic degradation mechanism is called only when an exception occurs in the system degradation mechanism, such as a Redis database failure.

[0113] In one embodiment of the present application, the reported information includes the number of system exceptions, the number of service rejections, and the number of interface accesses. If the system policy identifier cannot be obtained, directly determining the local policy identifier according to the reported information includes: calculating a first failure rate of the transaction request based on the number of system exceptions and the number of interface accesses; if the number of system exceptions triggers a system exception count threshold and the first failure rate triggers a first failure rate threshold, updating the local policy identifier to the system exception downgrade identifier.

[0114] Specifically, if there is a situation of system exception in the transaction verification system, it indicates that the transaction fails. At this time, it is possible to determine whether to update the local policy identifier to the system exception downgrade identifier according to the number of system exceptions and the ratio of the number of system exceptions to the number of interface accesses, that is, the first failure rate.

[0115] The main reasons for comprehensively determining the local policy identifier by using the two indicators of the number of system exceptions and the first failure rate are mainly considered as follows: 1) Since the number of system exceptions is only a statistic for a certain period of time, such as per minute, if only judged by the number of system exceptions, if there is only one or a few transaction requests per minute that fail due to system exceptions in the transaction verification system but do not trigger the system exception count threshold, it will lead to continuous transaction losses; 2) When the number of transaction requests within one minute is small, as long as one or a few transaction requests fail due to system exceptions in the transaction verification system, it may result in a relatively high first failure rate. Therefore, if only judged by the first failure rate, the local automatic downgrade mechanism will be frequently triggered.

[0116] Therefore, in order to avoid the above problems, when updating the local policy identifier in the case of system exception in the transaction verification system, the two indicators of the number of system exceptions and the first failure rate can be used to comprehensively determine the local policy identifier. Specifically, if the number of system exceptions triggers the system exception count threshold and the first failure rate also triggers the first failure rate threshold, the local policy identifier is updated to the system exception downgrade identifier.

[0117] In one embodiment of the present application, if the system policy identifier cannot be obtained, directly determining the local policy identifier according to the reported information includes: calculating a second failure rate of the transaction request based on the number of service rejections and the number of interface accesses; if the number of service rejections triggers a service rejection count threshold and the second failure rate triggers a second failure rate threshold, updating the local policy identifier to the service rejection downgrade identifier.

[0118] Specifically, if a business rejection occurs, it also indicates that the transaction fails. To avoid the continuous transaction losses or the frequent triggering of the local automatic downgrading mechanism mentioned above, when updating the local policy identifier in the case of a business rejection, whether to update the local policy identifier to a business rejection downgrading identifier can be determined based on the number of business rejections and the ratio of the number of business rejections to the number of interface accesses, i.e., the second failure rate. If the number of business rejections triggers the business rejection count threshold and the second failure rate also triggers the second failure rate threshold, the local policy identifier can be updated to a business rejection downgrading identifier.

[0119] The existing local automatic downgrading solution does not distinguish between the cases of transaction verification system exceptions and business rejections. Instead, it determines whether to call the local automatic downgrading mechanism based on whether the sum of the number of system exceptions and the number of business rejections triggers a threshold. The problem with this is that the number of system exceptions and the number of business rejections will affect each other during statistics. If the sum of the two triggers the threshold due to a high number of business rejections, there will be a problem of releasing transaction requests that should have been rejected, thereby overlooking real transaction risks. In contrast, the local automatic downgrading mechanism of the present application distinguishes between the cases of transaction verification system exceptions and business rejections in the above embodiments, and sets corresponding thresholds for judgment respectively, thereby avoiding overlooking real transaction risks.

[0120] As Figure 5 shown, a processing logic block diagram of a transaction request is provided. For any transaction transfer server, an asynchronous task is first started to obtain the Redis status identifier of the Redis database. If the Redis status identifier is in a normal state, a request is sent to the Redis database to obtain the system policy identifier. If the system policy identifier can be obtained normally, the local policy identifier is updated according to the obtained system policy identifier. According to the transaction request processing policy corresponding to the updated local policy identifier, the received transaction request is processed. Here, if the system policy identifier is a downgrading identifier, this asynchronous task is directly ended. If the system policy identifier is a non-downgrading identifier, the number of system exceptions, the number of business rejections, and the number of interface accesses are obtained, and the reporting information such as the number of system exceptions, the number of business rejections, and the number of interface accesses is reported to the Redis database. The Redis database calculates and analyzes whether the threshold corresponding to the system downgrading mechanism is triggered. If it is triggered, the system policy identifier is updated to a downgrading identifier.

[0121] In the above process, if the system policy identifier cannot be obtained from the Redis database, or the reporting information cannot be reported to the Redis database, the number of exceptions in the Redis database is counted. If this number of exceptions triggers the corresponding exception count threshold, the Redis status identifier is updated to a Redis failure identifier.

[0122] If the obtained Redis status flag is the Redis failure flag, the local automatic degradation mechanism can be called to process the transaction request, and then directly obtain the system exception count, business rejection count, and interface access count, and determine whether to trigger the threshold corresponding to the local automatic degradation mechanism based on the system exception count, business rejection count, and interface access count. If triggered, update the local policy flag to the degradation flag, and then determine whether the institution flag carried in the received transaction request is in the blacklist. If so, directly reject the transaction request; if the threshold corresponding to the local automatic degradation mechanism is not triggered, call the transaction verification system to verify the received transaction request, and obtain a processing result of transaction verification passed, business rejected, or unclear, and update the system exception count, business rejection count, and interface access count accordingly.

[0123] An embodiment of the present application also provides a processing device 600 for transaction requests, which is applied to each transaction transfer server in the transaction transfer system. Among them, as Figure 6 shown, the device 600 includes:

[0124] An acquisition unit 610, configured to acquire a system policy flag, where the system policy flag is a policy flag that takes effect in the transaction transfer system;

[0125] A first update unit 620, configured to update a local policy flag according to the system policy flag, where the local policy flag is a policy flag that takes effect in each transaction transfer server;

[0126] A transaction request processing unit 630, configured to process the received transaction request according to the updated local policy flag;

[0127] A first determination unit 640, configured to determine reporting information according to the transaction request processing result.

[0128] In an embodiment of the present application, the transaction transfer system further includes a preset Redis database, and the system policy flag is stored in the Redis database. The acquisition unit 610 is specifically configured to: determine the Redis status flag of the Redis database; in the case that the Redis status flag indicates that the Redis database is normal, request the Redis database to obtain the system policy flag.

[0129] In an embodiment of the present application, the device further includes: a second determination unit, configured to determine the number of request failures according to the result of the request to the Redis database; a second update unit, configured to update the Redis status flag to the Redis failure flag if the number of request failures reaches a first threshold within a preset time, and the Redis failure flag is used to indicate that the Redis database fails.

[0130] In one embodiment of the present application, the device further includes: a reporting unit, configured to report the reporting information to the Redis database, so that the Redis database can update the system policy identifier according to the reporting information; a third determination unit, configured to determine the number of reporting failures according to the reporting result; a third update unit, configured to update the Redis status identifier to a Redis failure identifier if the number of reporting failures reaches a second threshold.

[0131] In one embodiment of the present application, the system policy identifier includes a downgrade identifier, and the downgrade identifier includes a system exception downgrade identifier. The first update unit 620 is specifically configured to: if the system policy identifier is the system exception downgrade identifier, update the local policy identifier to the system exception downgrade identifier; the transaction request processing unit 630 is specifically configured to: according to the system exception downgrade identifier, release the received transaction request to the transaction processing system for transaction processing.

[0132] In one embodiment of the present application, the transaction request carries an institution identifier. Before releasing the received transaction request to the transaction processing system for transaction processing according to the system exception downgrade identifier, the device further includes: a fourth determination unit, configured to determine whether the institution identifier carried in the transaction request is in the blacklist; a rejection unit, configured to directly reject the transaction request if it is; a release unit, configured to release the transaction request to the transaction processing system if it is not.

[0133] In one embodiment of the present application, the system policy identifier includes a downgrade identifier, and the downgrade identifier includes a service rejection downgrade identifier. The first update unit 620 is specifically configured to: if the system policy identifier is the service rejection downgrade identifier, update the local policy identifier to the service rejection downgrade identifier; the transaction request processing unit 630 is specifically configured to: directly reject the transaction request according to the service rejection downgrade identifier.

[0134] In one embodiment of the present application, the system policy identifier includes a non-downgrade identifier. The first update unit 620 is specifically configured to: if the system policy identifier is the non-downgrade identifier, update the local policy identifier to the non-downgrade identifier; the transaction request processing unit 630 is specifically configured to: forward the received transaction request to the transaction verification system for verification according to the non-downgrade identifier.

[0135] In one embodiment of the present application, the first determination unit 630 is specifically configured to: receive the transaction verification result returned by the transaction verification system, where the types of the transaction verification result include transaction verification passed, transaction verification system exception, and service rejection; count the number of system exceptions and the number of service rejections according to the transaction verification result, and count the number of interface accesses according to the received transaction requests; use at least one of the number of system exceptions, the number of service rejections, and the number of interface accesses as the reported information.

[0136] In one embodiment of the present application, the device further includes: a fifth determination unit, configured to directly determine the local policy identifier according to the reported information if the system policy identifier cannot be obtained.

[0137] In one embodiment of the present application, the reported information includes the number of system exceptions, the number of service rejections, and the number of interface accesses. The fifth determination unit is specifically configured to: calculate a first failure rate of the transaction request according to the number of system exceptions and the number of interface accesses; if the number of system exceptions triggers a system exception number threshold and the first failure rate triggers a first failure rate threshold, update the local policy identifier to the system exception downgrade identifier.

[0138] In one embodiment of the present application, the fifth determination unit is specifically configured to: calculate a second failure rate of the transaction request according to the number of service rejections and the number of interface accesses; if the number of service rejections triggers a service rejection number threshold and the second failure rate triggers a second failure rate threshold, update the local policy identifier to the service rejection downgrade identifier.

[0139] It can be understood that the above transaction request processing device can implement each step of the transaction request processing method executed by the transaction transfer server provided in the foregoing embodiment. The relevant explanations regarding the transaction request processing method are applicable to the transaction request processing device and will not be elaborated herein.

[0140] Figure 7 It is a schematic structural diagram of a transaction transfer system according to another embodiment of the present application. Please refer to Figure 7 , the transaction transfer system includes multiple transaction transfer servers. At the hardware level, each transaction transfer server includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include a memory, such as a high-speed random access memory (Random-Access Memory, RAM), and may also include a non-volatile memory, such as at least one disk memory, etc. Of course, the electronic device may also include other hardware required for other services.

[0141] The processor, network interface, and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, Figure 7 only a bidirectional arrow is used in

[0142] Memory, used to store programs. Specifically, the program can include program code, and the program code includes computer operation instructions. The memory can include a memory and a non-volatile memory, and provide instructions and data to the processor.

[0143] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a transaction reconciliation device at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0144] Obtain a system policy identifier, where the system policy identifier is a policy identifier effective for the transaction transfer system;

[0145] Update the local policy identifier according to the system policy identifier, where the local policy identifier is a policy identifier effective for each transaction transfer server;

[0146] Process the received transaction request according to the updated local policy identifier;

[0147] Determine the reporting information according to the transaction request processing result.

[0148] The above is as in this application Figure 6The method executed by the processing device for transaction requests disclosed in the illustrated embodiments can be applied to or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in the processor or the instructions in the form of software. The above-mentioned processor may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. It can implement or execute various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in combination with the embodiments of the present application can be directly embodied as being executed and completed by the hardware decoding processor, or executed and completed by the combination of the hardware and software modules in the decoding processor. The software module may be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. This storage medium is located in the memory, and the processor reads the information in the memory and combines its hardware to complete the steps of the above method.

[0149] The transaction transfer system can also execute Figure 6 the method executed by the processing device for transaction requests in Figure 6 the illustrated embodiments, and implement the functions of the processing device for transaction requests in

[0150] The embodiments of the present application also propose a computer-readable storage medium that stores one or more programs. The one or more programs include instructions that, when executed by a transaction transfer server including multiple application programs, can enable the transaction transfer server to execute Figure 6 the method executed by the processing device for transaction requests in the illustrated embodiments, and specifically used to execute:

[0151] Obtain a system policy identifier, where the system policy identifier is a policy identifier effective for the transaction transfer system;

[0152] Update the local policy identifier according to the system policy identifier, where the local policy identifier is a policy identifier effective for each transaction transfer server;

[0153] Process the received transaction request according to the updated local policy identifier;

[0154] Determine the reported information according to the transaction request processing result.

[0155] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer-usable program code.

[0156] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the functions specified in one Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0157] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means that implement the functions specified in one Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0158] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0159] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0160] The memory may include non-permanent memory in the form of 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.

[0161] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can store information by any method or technology. The information can be computer-readable instructions, data structures, program modules, 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, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transitory media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

[0162] It should also be noted that the term "comprising", "including" or any other variation thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but also other elements not expressly listed, or elements that are inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising a..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0163] Those skilled in the art will appreciate that the embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application may 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.) that contain computer-usable program code.

[0164] The above description is only for the embodiments of the present application and is not intended to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

1. A method for processing a transaction request, which is applied to each transaction transfer server in a transaction transfer system, wherein, The method includes: After receiving a transaction request, obtaining a system policy identifier, where the system policy identifier is a policy identifier effective for the transaction transfer system; Updating a local policy identifier according to the system policy identifier, where the local policy identifier is a policy identifier effective for each transaction transfer server; Processing the received transaction request according to the updated local policy identifier; Determining reporting information according to the transaction request processing result; The system policy identifier includes a system exception downgrade identifier and a service rejection downgrade identifier. The reporting information includes the number of system exceptions, the number of service rejections, and the number of interface accesses. The system exception downgrade identifier is determined based on the number of system exceptions and the number of interface accesses, and the service rejection downgrade identifier is determined based on the number of service rejections and the number of interface accesses.

2. The method according to claim 1, wherein The transaction transfer system further includes a preset Redis database, and the system policy identifier is stored in the Redis database. The obtaining of the system policy identifier includes: Determining a Redis status identifier of the Redis database; When the Redis status identifier indicates that the Redis database is normal, requesting the Redis database to obtain the system policy identifier.

3. The method according to claim 2, wherein, The method further includes: Determining the number of failed requests according to the result of the request to the Redis database; [[ID=~11]]If the number of failed requests reaches a first threshold within a preset time, updating the Redis status identifier to a Redis failure identifier, where the Redis failure identifier is used to indicate that the Redis database fails.

4. The method according to claim 2, wherein The method further includes: Reporting the reporting information to the Redis database so that the Redis database can update the system policy identifier according to the reporting information; Determining the number of failed reports according to the reporting result; If the number of failed reports reaches a second threshold, updating the Redis status identifier to a Redis failure identifier.

5. The method according to claim 1, wherein, The system policy identifier includes a downgrade identifier, and the downgrade identifier includes a system exception downgrade identifier. The updating of the local policy identifier according to the system policy identifier includes: If the system policy identifier is the system exception downgrade identifier, updating the local policy identifier to the system exception downgrade identifier; The processing of the received transaction request according to the transaction request processing policy corresponding to the updated local policy identifier includes: Releasing the received transaction request to the transaction processing system for transaction processing according to the system exception downgrade identifier.

6. The method according to claim 5, wherein, The transaction request carries an institution identifier. Before releasing the received transaction request to the transaction processing system for transaction processing according to the system exception downgrade identifier, the method further includes: Determining whether the institution identifier carried in the transaction request is in a blacklist; If so, directly rejecting the transaction request; If not, releasing the transaction request to the transaction processing system.

7. The method according to claim 1, wherein The system policy identifier includes a downgrade identifier, and the downgrade identifier includes a service rejection downgrade identifier. The updating of the local policy identifier according to the system policy identifier includes: If the system policy identifier is the service rejection downgrade identifier, update the local policy identifier to the service rejection downgrade identifier; Processing the received transaction request according to the transaction request processing policy corresponding to the updated local policy identifier includes: Directly reject the transaction request according to the service rejection downgrade identifier.

8. The method according to claim 1, wherein, The system policy identifier includes a non-downgrade identifier, and updating the local policy identifier according to the system policy identifier includes: If the system policy identifier is the non-downgrade identifier, update the local policy identifier to the non-downgrade identifier; Processing the received transaction request according to the transaction request processing policy corresponding to the updated local policy identifier includes: Forward the received transaction request to the transaction verification system for verification according to the non-downgrade identifier.

9. The method according to claim 8, wherein, Determining the reported information according to the transaction request processing result includes: Receiving the transaction verification result returned by the transaction verification system, and the types of the transaction verification result include transaction verification passed, transaction verification system exception, and service rejection; Counting the number of system exceptions and the number of service rejections according to the transaction verification result, and counting the number of interface accesses according to the received transaction request; Use the number of system exceptions, the number of service rejections, and the number of interface accesses as the reported information.

10. The method according to claim 1, wherein, The method further includes: If the system policy identifier cannot be obtained, directly determine the local policy identifier according to the reported information.

11. The method according to claim 10, wherein The step of directly determining the local policy identifier according to the reported information if the system policy identifier cannot be obtained includes: Calculate the first failure rate of the transaction request according to the number of system exceptions and the number of interface accesses; If the number of system exceptions triggers the system exception number threshold and the first failure rate triggers the first failure rate threshold, update the local policy identifier to the system exception downgrade identifier.

12. The method according to claim 11, wherein, The step of directly determining the local policy identifier according to the reported information if the system policy identifier cannot be obtained includes: Calculate the second failure rate of the transaction request according to the number of service rejections and the number of interface accesses; If the number of service rejections triggers the service rejection number threshold and the second failure rate triggers the second failure rate threshold, update the local policy identifier to the service rejection downgrade identifier.

13. A processing device for transaction requests, which is applied to each transaction transfer server in a transaction transfer system, wherein, The device is used to implement the method according to any one of claims 1 to 12.

14. A transaction transfer system includes a plurality of transaction transfer servers, and each transaction transfer server includes: A processor; And A memory arranged to store computer-executable instructions, and when the executable instructions are executed, the processor executes the method according to any one of claims 1 to 12.

15. A trading system, comprising: A transaction transfer system, a transaction verification system, and a transaction processing system. The transaction transfer system includes several transaction transfer servers, and each transaction transfer server includes the device according to claim 13.

16. A computer-readable storage medium storing one or more programs which, when executed by a transaction switching server including a plurality of application programs, cause the transaction switching server to execute the method according to any one of claims 1 to 12.

Images