A multi-dimensional feature payment task dynamic priority scheduling method and system
Patent Information
- Application Number
- CN202511172796.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-21
- Publication Date
- 2026-10-09
AI Technical Summary
[0005]本发明的目的在于提供一种多维特征的支付任务动态优先级调度方法及系统，旨在解决现有技术中支付系统在应对高并发交易时，存在支付处理效率低和安全保障机制差的技术问题
[0044]本发明的一种多维特征的支付任务动态优先级调度方法及系统，在具体使用时，通过构建多维特征的动态优先级调度模型，综合考虑订单金额、用户等级、支付渠道状态等关键因素，实现支付任务的智能排序与高效处理，确保高优先级任务能够得到及时响应，有效避免了传统调度方式因顺序固定而导致的资源闲置与效率损耗。同时，采用双重MD5加密技术对支付请求和操作结果进行严格验证，结合乐观锁机制保障数据库操作的原子性，从数据传输和存储层面筑牢安全防线，防止数据被篡改或泄露。此外，完善的数据备份与恢复策略为支付操作提供了可靠的安全兜底，即使在极端情况下也能确保用户资金数据的安全性和完整性。而基于Kafka流式算法的日志记录与挖掘分析，则为系统的持续优化提供了有力的数据支撑，通过Apriori和随机森林算法对日志数据进行深度分析，能够及时发现系统潜在问题并针对性地优化调度策略，以此方式解决了现有技术中支付系统在应对高并发交易时，存在支付处理效率低和安全保障机制差的技术问题。
Smart Images
Figure CN122887470A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of Internet information technology, and in particular to a method and system for dynamic priority scheduling of payment tasks with multi-dimensional features. Background Technology
[0002] Existing payment systems typically employ distributed and microservice architectures to enhance scalability and flexibility. These architectures enable the system to easily handle the pressures of business growth and support multi-tenant architectures that provide independent payment services to different merchants.
[0003] In terms of technology platforms, existing systems are typically developed using programming languages such as Java and Python, and employ a combination of relational databases (e.g., MySQL) and non-relational databases (e.g., MongoDB) for data storage. Furthermore, message queues (e.g., RabbitMQ) are widely used in the asynchronous processing of payment systems. However, with the continuous increase in transaction volume, existing payment systems face certain pressures and challenges when handling high-concurrency transactions. Improving payment processing efficiency and reducing transaction latency are among the problems that existing technologies need to address. Moreover, although existing systems have adopted multiple security mechanisms to protect user funds and data, with the continuous upgrading and evolution of network attack methods, how to further improve the reliability and effectiveness of these security mechanisms is also an urgent issue to be addressed.
[0004] In summary, existing payment systems suffer from low payment processing efficiency and poor security mechanisms when dealing with high-concurrency transactions. Summary of the Invention
[0005] The purpose of this invention is to provide a method and system for dynamic priority scheduling of payment tasks with multi-dimensional features, which aims to solve the technical problems of low payment processing efficiency and poor security mechanisms in existing payment systems when dealing with high-concurrency transactions.
[0006] To achieve the above objectives, this invention employs a multi-dimensional feature-based dynamic priority scheduling method for payment tasks, comprising the following steps:
[0007] After receiving the payment request, extract the order data JSON, timestamp and user key, concatenate them into a combined string, and perform MD5 encryption to generate a verification signature;
[0008] The order amount, user level identifier, and real-time status parameters of the payment channel in the order data are analyzed, and a priority index is generated through a dynamic weight allocation algorithm.
[0009] Payment tasks are inserted into an asynchronous processing queue based on a priority index. High-priority tasks can preempt the positions of low-priority tasks that have already entered the queue. The queue scheduler monitors changes in the status of payment channels in real time and triggers task reordering.
[0010] When deducting funds, the user balance table and fund transaction table are operated simultaneously. An optimistic locking mechanism with version number verification is used in the database transaction to ensure the atomicity of balance update and transaction record insertion.
[0011] After the operation is completed, a new timestamp is generated. The operation result is combined with the user key and then encrypted twice using MD5 to generate a feedback signature, which is then returned to the client.
[0012] Before executing the deduction transaction, back up the data related to the current payment task in the user balance table and fund flow table; if the transaction fails, restore the user balance and fund flow to the state before the transaction was executed based on the backup data;
[0013] Throughout the payment task processing, the Kafka streaming algorithm is used to record detailed log information. The log information is transmitted in an encrypted manner to the Apriori algorithm to mine the data in the log information, and then the random forest algorithm is used to analyze the data to facilitate the optimization of the scheduling method.
[0014] Among them, after receiving a payment request, a request rate limiting mechanism is used to control the number of payment requests entering the system per unit time through the token bucket algorithm or the leaky bucket algorithm.
[0015] When the number of requests exceeds the set threshold, the excess requests are placed in a waiting queue or an error message indicating that the requests are too frequent is returned.
[0016] In the process of recording log information, transmitting data, and processing data, data involving sensitive user information is de-identified; sensitive information is converted into an unidentifiable or partially unidentifiable form by means of replacement, encryption, and masking to avoid leakage of sensitive information and ensure the security of user data.
[0017] Specifically, when generating the priority index using the dynamic weight allocation algorithm:
[0018] Determining the weight α of order amount dimension: Divide the order amount into multiple ranges based on the historical order amount distribution, configure a basic weight value for each range, and increase the weight of high amount ranges according to the overload ratio when the real-time payment system load exceeds the threshold.
[0019] Determining the weight β of the user level dimension: VIP levels are divided based on the user's historical payment success rate, and then the weight β of the user level dimension is determined.
[0020] Determining the weight γ of the payment channel status dimension: It is calculated inversely based on the real-time response performance index of the payment channel. The worse the response performance, the lower the weight.
[0021] The dynamic adjustment mechanism for the real-time status parameters of the payment channel includes:
[0022] A multi-level sliding time window mechanism is used to collect response rate, success rate, and average delay indicators for payment channels;
[0023] When any core performance indicator falls below a threshold dynamically adjusted based on system load within a short time window, a downgrade operation is triggered on the weight of the payment channel status dimension.
[0024] When the performance index of a payment channel remains below the preset unavailability threshold for an extended period of time, the payment channel is automatically marked as unavailable, and the status weights of other available channels are recalculated.
[0025] The asynchronous queue scheduling step is implemented in the following ways:
[0026] Real-time monitoring of payment channel performance metrics and updating of status parameter tables;
[0027] When a high-priority task is inserted into the queue, if its priority index is higher than the index of a certain proportion of tasks in the queue, the queue tasks will be rearranged, and some of the tasks that have been surpassed will be moved to the waiting area.
[0028] Set up multiple sub-queues with different priorities and allocate different processing thread resources to sub-queues with different priorities, with higher priority queues allocated more threads;
[0029] In the event of task execution failure, different retry or termination strategies are implemented based on the specific error type of the failure.
[0030] The encryption implementation methods in the combined encryption verification step include:
[0031] The order data string, the timestamp accurate to milliseconds, and the user key are concatenated in a fixed order to generate the string to be encrypted;
[0032] Enhance security by performing timestamp-based derivation on user keys;
[0033] After payment processing is complete, a second encryption is performed using the new timestamp and operation result to generate a feedback signature.
[0034] The transaction control mechanisms in the dual-table atomic operation steps include:
[0035] Set a version number field in the user balance table, and perform a conditional update operation with version number verification when updating the balance;
[0036] When version number verification fails, resulting in zero rows affected by the update, the entire transaction is rolled back, and the insertion operation of the fund flow table is canceled.
[0037] Record the user balance snapshot information before and after the operation, as well as the version number related to the operation, in the fund flow statement.
[0038] The collaborative optimization of the optimistic locking mechanism and the asynchronous queue scheduling steps includes:
[0039] Preload the current database version number into the task context before executing queued tasks to reduce the number of database accesses;
[0040] The caching system maintains recent records of user version numbers. When a queue task is executed, the cached version number is read first, and then the consistency is eventually verified with the database version number before the transaction is committed.
[0041] When multiple version number conflicts are detected for the same user account, a temporary circuit breaker is automatically triggered to protect the payment operations of that account, and an alarm is sent to the risk control system.
[0042] This invention also provides a dynamic priority scheduling system for payment tasks based on multi-dimensional features.
[0043] It includes a scheduling processing module for executing the payment task dynamic priority scheduling method with multi-dimensional features as described above.
[0044] This invention discloses a multi-dimensional feature-based dynamic priority scheduling method and system for payment tasks. In practical use, it constructs a multi-dimensional feature-based dynamic priority scheduling model, comprehensively considering key factors such as order amount, user level, and payment channel status to achieve intelligent sorting and efficient processing of payment tasks. This ensures that high-priority tasks receive timely responses, effectively avoiding resource idleness and efficiency losses caused by the fixed order of traditional scheduling methods. Simultaneously, it employs dual MD5 encryption technology to rigorously verify payment requests and operation results, combined with an optimistic locking mechanism to ensure the atomicity of database operations, building a strong security defense at the data transmission and storage levels to prevent data tampering or leakage. Furthermore, a robust data backup and recovery strategy provides a reliable security safety net for payment operations, ensuring the security and integrity of user funds even in extreme situations. Log recording and mining analysis based on the Kafka streaming algorithm provides strong data support for continuous system optimization. Deep analysis of log data using Apriori and random forest algorithms allows for timely identification of potential system problems and targeted optimization of scheduling strategies. This approach solves the technical problems of low payment processing efficiency and poor security mechanisms in existing payment systems when dealing with high-concurrency transactions. Attached Figure Description
[0045] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0046] Figure 1 This is a flowchart illustrating the multi-dimensional feature-based dynamic priority scheduling method for payment tasks according to the present invention. Detailed Implementation
[0047] The embodiments of the present invention are described in detail below. Examples of the embodiments are shown in the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, but should not be construed as limiting the present invention.
[0048] Please see Figure 1 , Figure 1 This is a flowchart illustrating the multi-dimensional feature-based dynamic priority scheduling method for payment tasks according to the present invention.
[0049] This invention provides a method for dynamic priority scheduling of payment tasks with multi-dimensional features, comprising the following steps:
[0050] S1. After receiving the payment request, extract the order data JSON, timestamp and user key, concatenate them into a combined string, and perform MD5 encryption to generate a verification signature;
[0051] In this specific implementation, after receiving a payment request, a request rate limiting mechanism is used to control the number of payment requests entering the system per unit time through a token bucket algorithm or a leaky bucket algorithm.
[0052] When the number of requests exceeds the set threshold, the excess requests are placed in a waiting queue or an error message indicating that the requests are too frequent is returned.
[0053] S2. Parse the order amount, user level identifier, and real-time status parameters of the payment channel in the order data, and generate a priority index through a dynamic weight allocation algorithm;
[0054] In this specific implementation, when generating the priority index using the dynamic weight allocation algorithm:
[0055] Determining the weight α of order amount dimension: Divide the order amount into multiple ranges based on the historical order amount distribution, configure a basic weight value for each range, and increase the weight of high amount ranges according to the overload ratio when the real-time payment system load exceeds the threshold.
[0056] Determining the weight β of the user level dimension: VIP levels are divided based on the user's historical payment success rate, and then the weight β of the user level dimension is determined.
[0057] Determining the weight γ of the payment channel status dimension: It is calculated inversely based on the real-time response performance index of the payment channel. The worse the response performance, the lower the weight.
[0058] S3. Based on the priority index, payment tasks are inserted into the asynchronous processing queue. High-priority tasks can preempt the positions of low-priority tasks that have already entered the queue. The queue scheduler monitors the changes in the status of the payment channel in real time and triggers task reordering.
[0059] For this specific implementation method, the dynamic adjustment mechanism for the real-time status parameters of the payment channel includes:
[0060] A multi-level sliding time window mechanism is used to collect response rate, success rate, and average delay indicators for payment channels;
[0061] When any core performance indicator falls below a threshold dynamically adjusted based on system load within a short time window, a downgrade operation is triggered on the weight of the payment channel status dimension.
[0062] When the performance index of a payment channel remains below the preset unavailability threshold for an extended period of time, the payment channel is automatically marked as unavailable, and the status weights of other available channels are recalculated.
[0063] The implementation methods for asynchronous queue scheduling steps include:
[0064] Real-time monitoring of payment channel performance metrics and updating of status parameter tables;
[0065] When a high-priority task is inserted into the queue, if its priority index is higher than the index of a certain proportion of tasks in the queue, the queue tasks will be rearranged, and some of the tasks that have been surpassed will be moved to the waiting area.
[0066] Set up multiple sub-queues with different priorities and allocate different processing thread resources to sub-queues with different priorities, with higher priority queues allocated more threads;
[0067] In the event of task execution failure, different retry or termination strategies are implemented based on the specific error type of the failure.
[0068] S4. When performing deduction, the user balance table and fund flow table are operated synchronously. An optimistic locking mechanism with version number verification is used in the database transaction to ensure the atomicity of balance update and flow record insertion.
[0069] S5. After the operation is completed, a new timestamp is generated. The operation result is combined with the user key and encrypted twice with MD5 to generate a feedback signature and return it to the client.
[0070] S6. Before executing the deduction transaction, back up the data related to the current payment task in the user balance table and fund flow table; if the transaction fails, restore the user balance and fund flow to the state before the transaction was executed based on the backup data;
[0071] S7. Throughout the entire payment task processing, the Kafka streaming algorithm is used to record detailed log information. The log information is transmitted in an encrypted manner to the Apriori algorithm to mine the data in the log information, and then the random forest algorithm is used to analyze the data to facilitate the optimization of the scheduling method.
[0072] In this specific implementation, during the recording of log information, transmission of data, and processing, data involving sensitive user information is de-identified; sensitive information is converted into an unidentifiable or partially unidentifiable form by means of replacement, encryption, and masking to avoid leakage of sensitive information and ensure the security of user data.
[0073] The encryption implementation methods in the combined encryption verification steps include:
[0074] The order data string, the timestamp accurate to milliseconds, and the user key are concatenated in a fixed order to generate the string to be encrypted;
[0075] Enhance security by performing timestamp-based derivation on user keys;
[0076] After payment processing is complete, a second encryption is performed using the new timestamp and operation result to generate a feedback signature.
[0077] The transaction control mechanisms in the two-table atomic operation steps include:
[0078] Set a version number field in the user balance table, and perform a conditional update operation with version number verification when updating the balance;
[0079] When version number verification fails, resulting in zero rows affected by the update, the entire transaction is rolled back, and the insertion operation of the fund flow table is canceled.
[0080] Record the user balance snapshot information before and after the operation, as well as the version number related to the operation, in the fund flow statement.
[0081] The collaborative optimization of optimistic locking mechanisms and asynchronous queue scheduling steps includes:
[0082] Preload the current database version number into the task context before executing queued tasks to reduce the number of database accesses;
[0083] The caching system maintains recent records of user version numbers. When a queue task is executed, the cached version number is read first, and then the consistency is eventually verified with the database version number before the transaction is committed.
[0084] When multiple version number conflicts are detected for the same user account, a temporary circuit breaker is automatically triggered to protect the payment operations of that account, and an alarm is sent to the risk control system.
[0085] In practical use, all operations throughout the entire payment task processing are subject to security audits. Information such as the time of the operation, the operator (or system module), and the content of the operation is recorded, and security audit reports are generated periodically. Analysis of these security audit reports allows for the timely identification of potential security issues and abnormal operations, enabling the implementation of appropriate preventative and handling measures.
[0086] In practical use, monitor various metrics of the payment business, such as payment success rate, payment failure rate, and average payment time. When abnormal fluctuations occur in business metrics, analyze the causes promptly and take corresponding measures for adjustment and optimization to ensure the normal operation of the payment business.
[0087] This embodiment employs a multi-dimensional feature-based dynamic priority scheduling method for payment tasks. In practical application, it constructs a multi-dimensional feature-based dynamic priority scheduling model, comprehensively considering key factors such as order amount, user level, and payment channel status. This enables intelligent sorting and efficient processing of payment tasks, ensuring timely responses to high-priority tasks and effectively avoiding resource idleness and efficiency losses caused by the fixed order of traditional scheduling methods. Simultaneously, dual MD5 encryption technology is used to rigorously verify payment requests and operation results, combined with an optimistic locking mechanism to ensure the atomicity of database operations. This strengthens security defenses at the data transmission and storage levels, preventing data tampering or leakage. Furthermore, a robust data backup and recovery strategy provides a reliable security safety net for payment operations, ensuring the security and integrity of user funds even in extreme situations. Log recording and mining analysis based on the Kafka streaming algorithm provides strong data support for continuous system optimization. Deep analysis of log data using Apriori and Random Forest algorithms allows for timely identification of potential system problems and targeted optimization of scheduling strategies. This approach addresses the technical problems of low payment processing efficiency and poor security mechanisms in existing payment systems when dealing with high-concurrency transactions.
[0088] This invention also provides a dynamic priority scheduling system for payment tasks based on multi-dimensional features.
[0089] It includes a scheduling processing module for executing the payment task dynamic priority scheduling method with multi-dimensional features as described above.
[0090] The system monitors various performance metrics of the processing module in real time, such as CPU utilization, memory utilization, disk I / O, and network bandwidth. When performance metrics exceed preset thresholds, alarm messages are promptly issued to notify maintenance personnel for handling, ensuring the system is always in good operating condition.
[0091] For example, set a CPU utilization threshold of 80%, and when the CPU utilization exceeds 80%, send an alarm message to the operations and maintenance personnel via email or SMS.
[0092] The multi-dimensional feature-based dynamic priority scheduling method and system for payment tasks, as described in this invention, constructs a multi-dimensional feature-based dynamic priority scheduling model. This model comprehensively considers key factors such as order amount, user level, and payment channel status to achieve intelligent sorting and efficient processing of payment tasks. This ensures that high-priority tasks receive timely responses, effectively avoiding resource idleness and efficiency losses caused by the fixed order of traditional scheduling methods. Simultaneously, dual MD5 encryption technology is used to rigorously verify payment requests and operation results, combined with an optimistic locking mechanism to ensure the atomicity of database operations. This strengthens security at the data transmission and storage levels, preventing data tampering or leakage. Furthermore, a robust data backup and recovery strategy provides a reliable security safety net for payment operations, ensuring the security and integrity of user funds even in extreme situations. Log recording and mining analysis based on the Kafka streaming algorithm provides strong data support for continuous system optimization. Deep analysis of log data using Apriori and random forest algorithms allows for timely identification of potential system problems and targeted optimization of scheduling strategies. This approach addresses the technical problems of low payment processing efficiency and poor security mechanisms in existing payment systems when dealing with high-concurrency transactions.
[0093] The above description discloses only one preferred embodiment of the present invention, and should not be construed as limiting the scope of the present invention. Those skilled in the art will understand that all or part of the processes of the above embodiments can be implemented, and equivalent changes made in accordance with the claims of the present invention are still within the scope of the invention.
Claims
1. A dynamic priority scheduling method for payment tasks with multi-dimensional features, characterized in that, Includes the following steps: After receiving the payment request, extract the order data JSON, timestamp and user key, concatenate them into a combined string, and perform MD5 encryption to generate a verification signature; The order amount, user level identifier, and real-time status parameters of the payment channel in the order data are analyzed, and a priority index is generated through a dynamic weight allocation algorithm. Payment tasks are inserted into an asynchronous processing queue based on a priority index. High-priority tasks can preempt the positions of low-priority tasks that have already entered the queue. The queue scheduler monitors changes in the status of payment channels in real time and triggers task reordering. When deducting funds, the user balance table and fund transaction table are operated simultaneously. An optimistic locking mechanism with version number verification is used in the database transaction to ensure the atomicity of balance update and transaction record insertion. After the operation is completed, a new timestamp is generated. The operation result is combined with the user key and then encrypted twice using MD5 to generate a feedback signature, which is then returned to the client. Before executing the deduction transaction, back up the data related to the current payment task in the user balance table and fund flow table; If the transaction fails, the user's balance and transaction history will be restored to their state before the transaction was executed, based on the backup data. Throughout the payment task processing, the Kafka streaming algorithm is used to record detailed log information. The log information is transmitted in an encrypted manner to the Apriori algorithm to mine the data in the log information, and then the random forest algorithm is used to analyze the data to facilitate the optimization of the scheduling method.
2. The multi-dimensional feature-based dynamic priority scheduling method for payment tasks as described in claim 1, characterized in that, After receiving a payment request, a request rate limiting mechanism is used to control the number of payment requests entering the system per unit time through the token bucket algorithm or the leaky bucket algorithm. When the number of requests exceeds the set threshold, the excess requests are placed in a waiting queue or an error message indicating that the requests are too frequent is returned.
3. The multi-dimensional feature-based dynamic priority scheduling method for payment tasks as described in claim 2, characterized in that, During the recording of log information, data transmission, and processing, data involving sensitive user information is anonymized; sensitive information is converted into an unidentifiable or partially unidentifiable form using methods such as replacement, encryption, and masking to prevent the leakage of sensitive information and ensure the security of user data.
4. The multi-dimensional feature-based dynamic priority scheduling method for payment tasks as described in claim 3, characterized in that, When generating priority indexes using a dynamic weight allocation algorithm: Determining the weight α of order amount dimension: Divide the order amount into multiple ranges based on the historical order amount distribution, configure a basic weight value for each range, and increase the weight of high amount ranges according to the overload ratio when the real-time payment system load exceeds the threshold. Determining the weight β of the user level dimension: VIP levels are divided based on the user's historical payment success rate, and then the weight β of the user level dimension is determined. Determining the weight γ of the payment channel status dimension: It is calculated inversely based on the real-time response performance index of the payment channel. The worse the response performance, the lower the weight.
5. The multi-dimensional feature-based dynamic priority scheduling method for payment tasks as described in claim 4, characterized in that, The dynamic adjustment mechanism for real-time status parameters of payment channels includes: A multi-level sliding time window mechanism is used to collect response rate, success rate, and average delay indicators for payment channels; When any core performance indicator falls below a threshold dynamically adjusted based on system load within a short time window, a downgrade operation is triggered on the weight of the payment channel status dimension. When the performance index of a payment channel remains below the preset unavailability threshold for an extended period of time, the payment channel is automatically marked as unavailable, and the status weights of other available channels are recalculated.
6. The multi-dimensional feature-based dynamic priority scheduling method for payment tasks as described in claim 5, characterized in that, The implementation methods for asynchronous queue scheduling steps include: Real-time monitoring of payment channel performance metrics and updating of status parameter tables; When a high-priority task is inserted into the queue, if its priority index is higher than the index of a certain proportion of tasks in the queue, the queue tasks will be rearranged, and some of the tasks that have been surpassed will be moved to the waiting area. Set up multiple sub-queues with different priorities and allocate different processing thread resources to sub-queues with different priorities, with higher priority queues allocated more threads; In the event of task execution failure, different retry or termination strategies are implemented based on the specific error type of the failure.
7. The multi-dimensional feature-based dynamic priority scheduling method for payment tasks as described in claim 6, characterized in that, The encryption implementation methods in the combined encryption verification steps include: The order data string, the timestamp accurate to milliseconds, and the user key are concatenated in a fixed order to generate the string to be encrypted; Enhance security by performing timestamp-based derivation on user keys; After payment processing is complete, a second encryption is performed using the new timestamp and operation result to generate a feedback signature.
8. The multi-dimensional feature-based dynamic priority scheduling method for payment tasks as described in claim 7, characterized in that, The transaction control mechanisms in the two-table atomic operation steps include: Set a version number field in the user balance table, and perform a conditional update operation with version number verification when updating the balance; When version number verification fails, resulting in zero rows affected by the update, the entire transaction is rolled back, and the insertion operation of the fund flow table is canceled. Record the user balance snapshot information before and after the operation, as well as the version number related to the operation, in the fund flow statement.
9. The multi-dimensional feature-based dynamic priority scheduling method for payment tasks as described in claim 8, characterized in that, The collaborative optimization of optimistic locking mechanisms and asynchronous queue scheduling steps includes: Preload the current database version number into the task context before executing queued tasks to reduce the number of database accesses; The caching system maintains recent records of user version numbers. When a queue task is executed, the cached version number is read first, and then the consistency is eventually verified with the database version number before the transaction is committed. When multiple version number conflicts are detected for the same user account, a temporary circuit breaker is automatically triggered to protect the payment operations of that account, and an alarm is sent to the risk control system.
10. A multi-dimensional feature-based dynamic priority scheduling system for payment tasks, characterized in that, It includes a scheduling processing module for executing the payment task dynamic priority scheduling method with multi-dimensional features as described in claim 9.