Transaction data processing method and apparatus, electronic device, and storage medium

Abstract

The present disclosure provides a transaction data processing method and device, an electronic device and a storage medium. The method comprises: acquiring market quotations of a power spot market, bidding strategies of a plurality of users and an execution return in a previous period in a current period; performing priority ranking on the users based on the strategies and the market quotations to obtain a ranked user sequence; acquiring target orders of the users based on a reference price determined by the market quotations and the strategies, a price change step in the strategies, a transaction power and the user sequence; performing comparison processing on the target orders and orders that have been hung based on the execution return to obtain a comparison result; and generating an order execution operation in the current period based on the comparison result, the target orders and the orders that have been hung. The method can realize aggregation in a period and account-level concurrent control, so that stable throughput and low jitter can be maintained under multiple parallel users, thereby improving high-concurrent stability in the transaction data processing process.

Description

Technical Field

[0001] This disclosure pertains to the field of electricity spot market trading, specifically involving transaction data processing methods and devices, electronic equipment, and storage media. Background Technology

[0002] To improve transaction rates and reduce risk, participants in the electricity spot market tend to use third-party automated trading systems. These systems use near real-time market data acquisition at the front end and centralized strategy evaluation and execution commands at the back end. In electricity spot market trading, multiple users operating concurrently are common. Each participant's trading strategy is independent, and internal competition among users exists, while they share the same market instruments and time windows. Current data processing suffers from high concurrency and low stability. Summary of the Invention

[0003] This disclosure provides a transaction data processing method and apparatus, electronic device, and storage medium to address the problem of low stability under high concurrency in the current transaction data processing technology.

[0004] In a first aspect, this disclosure provides a transaction data processing method applied to a rolling trading front-end and back-end system. The transaction data processing method includes: acquiring the current electricity spot market price, the bidding strategies of several users, and the execution returns of the previous period; prioritizing the users based on the strategies and the market price to obtain a sorted user sequence; acquiring the target orders of the users based on the benchmark price determined by the market price and the strategies, the price adjustment step size and trading volume in the strategies, and the user sequence; comparing the target orders with the pending orders in the execution returns to obtain a comparison result; and generating an order execution operation for the current period based on the comparison result, the target orders, and the pending orders.

[0005] By aggregating the market data, the strategy, and the previous period's execution returns within the current period, comparing user orders within this period, and generating corresponding order execution operations, intra-period aggregation and account-level concurrency control are achieved. This enables stable throughput and low jitter under multiple parallel users, thereby improving the high-concurrency stability of the transaction data processing process.

[0006] In one embodiment of this disclosure, the rolling trading front-end and back-end system includes a trading front-end and a trading back-end. The method for obtaining market data, reporting strategies, and execution reports from the previous period reported by several users within the current period, all related to the electricity spot market, includes: the trading back-end activating a time controller and periodically broadcasting server time; the trading front-end subscribing to the broadcast and correcting its local offset based on the broadcast server time; the trading back-end obtaining the trigger second; the trading back-end opening a receiving window based on the trigger second; based on the receiving window, the trading front-end packaging and reporting the market data, strategies, and execution reports at the aligned time; and the trading back-end obtaining the market data, strategies, and execution reports.

[0007] In one embodiment of this disclosure, the transaction data processing method further includes: deduplicating duplicate strategies reported by the same user in the strategy to retain the strategy most recently reported by the user in the duplicate strategy; performing parameter verification on the market data and the strategy to obtain a verification result, wherein the verification result is either parameter verification passed or parameter verification failed; intercepting the market data and strategy that failed the verification; and marking the user as skipped based on the user status.

[0008] In one embodiment of this disclosure, a method for prioritizing users based on the strategy and the market data to obtain a sorted user sequence includes: obtaining a priority score based on the strategy and the market data; prioritizing the users based on the priority score to obtain the user sequence; the priority score is represented as:

[0009]

[0010] in, This indicates the priority score. This represents the default value for the user's score. Indicates the first weight. This represents the user's average transaction volume over the past 30 days. Indicates the second weight. This indicates the amount of electricity a user has traded that day in the market data. This represents the total transaction volume that the user expects under the stated strategy. Indicates the third weight. Indicates the fourth weight. This represents the user's risk coefficient.

[0011] In one embodiment of this disclosure, a method for obtaining a user's target order based on a benchmark price determined by the market data and the strategy, a price adjustment step size and transaction volume in the strategy, and the user sequence includes: obtaining the price in the target order based on the benchmark price, the price adjustment step size and the user sequence; and obtaining the target order based on the price in the target order and the transaction volume.

[0012] In one embodiment of this disclosure, when the target order belongs to the buyer's target order, the price of the target order = the base price + N × the price adjustment step size; when the target order belongs to the seller's target order, the price of the target order = the base price - N × the price adjustment step size; where N is a positive integer, and N represents the order of the user corresponding to the target order in the user sequence.

[0013] In one embodiment of this disclosure, the method for generating an order execution operation within the current period based on the comparison result, the target order, and the pending orders includes: step S1, updating user declaration data; step S2, when there are pending orders that are missing compared to the target order, generating a cancellation execution operation based on the target order and the pending orders; step S3, when there are new orders in the target order compared to the pending orders, generating a pending order execution operation based on the target order and the pending orders; and step S4, recording audit logs.

[0014] Secondly, embodiments of this disclosure provide a transaction data processing apparatus. The transaction data processing apparatus includes:

[0015] The system comprises the following modules: a market data acquisition module, a user order acquisition module, a user ranking module, a user order acquisition module, an order ranking module, an order acquisition module, an order comparison ...

[0016] Thirdly, embodiments of this disclosure also provide a computer-readable storage medium having a computer program stored thereon. When executed by a processor, the computer program implements the transaction data processing method described in any of the first aspects.

[0017] Fourthly, embodiments of this disclosure also provide an electronic device. The electronic device includes: a memory storing a computer program; and a processor communicatively connected to the memory, which, when the computer program is invoked, executes the transaction data processing method described in any of the first aspects.

[0018] The aforementioned transaction data processing method and apparatus, electronic device, and storage medium have the following beneficial effects:

[0019] By aggregating market data, strategies, and previous period execution returns within the current period, comparing user orders within this period, and generating corresponding order execution operations, intra-period aggregation and account-level concurrency control are achieved. This ensures stable throughput and low jitter even with multiple concurrent users, thereby improving high-concurrency stability in transaction data processing. Furthermore, this transaction data processing method does not rely on specific provincial or platform standards; its general design for regional power trading centers makes it reusable across markets. Attached Figure Description

[0020] Figure 1 The diagram shown is a structural schematic of a mobile terminal according to an embodiment of this disclosure.

[0021] Figure 2 The flowchart shown is a transaction data processing method according to an embodiment of this disclosure.

[0022] Figure 3 The flowchart shown is an embodiment of the present disclosure of a method for obtaining the current electricity spot market conditions, the application strategies of several users, and the execution returns of the previous period.

[0023] Figure 4 The flowchart shown is an implementation method of the transaction data processing method according to an embodiment of this disclosure.

[0024] Figure 5 The flowchart shown is an embodiment of the present disclosure of a method for prioritizing users based on the strategy and market data to obtain a sorted user sequence.

[0025] Figure 6 The flowchart shown is an embodiment of the present disclosure of a method for obtaining a user's target order based on the benchmark price determined by the market data and the strategy, the price adjustment step size and transaction volume in the strategy, and the user sequence.

[0026] Figure 7 The flowchart shown is an implementation method for generating order execution operations within the current period based on the comparison results, the target order, and the pending orders, according to an embodiment of this disclosure.

[0027] Figure 8The diagram shown is a schematic representation of the transaction data processing apparatus according to an embodiment of this disclosure.

[0028] Figure 9 The diagram shown is a structural schematic of an electronic device according to an embodiment of this disclosure. Detailed Implementation

[0029] The following specific examples illustrate the implementation of this disclosure. Those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. This disclosure can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0030] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. Therefore, the illustrations only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0031] The technical solutions of the present disclosure embodiments will be described in detail below with reference to the accompanying drawings. The transaction data processing method provided in the embodiments of the present disclosure can run on mobile terminals, computer terminals, and similar devices. Taking the operation on the mobile terminal as an example, Figure 1 This is a hardware structure block diagram of the mobile terminal, such as... Figure 1 As shown, a mobile terminal may include a processor and a memory, wherein the processor may be a central processing unit and the memory is used to store data. Figure 1 The mobile terminal in the example is for illustrative purposes only and is not intended to limit the specific structure of the mobile terminal.

[0032] In some embodiments, the mobile terminal may further include: a communication transmission device and an input / output device.

[0033] In some embodiments, the memory may be used to store computer programs, such as application software programs and modules. The memory may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, which can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0034] In some embodiments, the communication transmission device can be used to receive or send data via a network, which may include a wireless network provided by the mobile terminal's communication provider. The communication transmission device may include a NIC (Network Interface Controller), which can be connected to other network devices via a base station to communicate with the Internet.

[0035] The following will describe in detail the principles and implementation methods of the transaction data processing method, apparatus, electronic device, and storage medium disclosed herein, so that those skilled in the art can understand the transaction data processing method, apparatus, electronic device, and storage medium disclosed herein without creative effort.

[0036] Figure 2 This is a flowchart illustrating a transaction data processing method according to an embodiment of the present disclosure. Figure 2 As shown, the transaction data processing method provided in this embodiment can be executed by a processor, and the method includes the following steps S11 to S14.

[0037] Step S11: Obtain the current electricity spot market conditions, the bidding strategies of several users, and the execution returns of the previous period.

[0038] Optionally, the market data may refer to the current spot market information for electricity, i.e., the market data of the electricity spot market trading center, and the market data is the latest market data within the current period. The strategy refers to the user's submission strategy for the electricity spot market within the current period, which may be a real-time strategy generated by the quantitative team based on signals, a submission generated based on model output and verified by traders, or an adaptive adjustment of strategy parameters by some algorithms within the automated system. The execution return of the previous period may refer to the actual execution result of the trading behavior generated based on the market data and strategy in the previous period, and may include pending orders from the previous period. The period in this embodiment can be flexibly set according to the actual situation, and this embodiment does not explicitly limit it.

[0039] Step S12: Prioritize the users based on the strategy and the market data to obtain a sorted user sequence.

[0040] Optionally, the method for prioritizing the users based on the strategy and the market data to obtain a sorted user sequence includes: prioritizing the users based on user weight, remaining capacity, risk coefficient, and historical transaction efficiency to obtain a sorted user sequence. The remaining capacity can be determined by the total transaction volume expected by the users in the strategy and the transaction volume already traded by the users on the current day in the market data. This embodiment will not elaborate further on this.

[0041] Optionally, the parameters in the strategy may also include: a tolerance threshold for small-volume fishing orders, a slippage control mechanism threshold, adaptive price adjustment frequency, price adjustment step size, and transaction volume. The tolerance threshold may refer to ignoring orders with a better price but a volume less than a certain value. The slippage control mechanism threshold may refer to still performing adjustments if the market price change is less than a certain threshold (e.g., 5%), and refusing adjustments and waiting for the next adjustment opportunity if the market price change is too large. The adaptive price adjustment frequency may refer to reducing the monitoring and price adjustment frequency by a certain percentage if market volatility exceeds a certain threshold. The price adjustment step size may refer to how many minimum price units are changed each time.

[0042] Optionally, the trading volume may refer to user positions, which may include: guaranteed positions that users must trade for position management, speculative positions where users have arbitrage opportunities, and high-yield, low-volume positions. The risk factor may refer to the trading risk level, specifically including: the user's tolerance for trading risk, the confidence level of the target price prediction for the specified period, and the risk of data inconsistency caused by market volatility, trading center delays, etc.

[0043] Step S13: Based on the benchmark price determined by the market data and the strategy, the price adjustment step size and transaction volume in the strategy, and the user sequence, obtain the user's target order.

[0044] Optionally, when the target order belongs to the buyer, the price of the target order = the base price + N × the price adjustment step size; when the target order belongs to the seller, the price of the target order = the base price - N × the price adjustment step size; where N is a positive integer, and N represents the order of the user corresponding to the target order in the user sequence. For example, if the user sequence is B, A, and C, user B is in the first position, and N in B's target order is 1; user A is in the second position, and N in A's target order is 2; user C is in the third position, and N in C's target order is 3.

[0045] Optionally, the benchmark price may refer to the weighted average of the benchmark price in the market data (the optimal buy / sell price) and the benchmark price in the strategy. The benchmark price in the market data is consistent for all users, while the benchmark price in the strategy is different for different users. The price adjustment step size in the strategy is the same for all users and is determined by the attributes of the market itself. For example, if the minimum transaction price change in the market is 0.01, then the step size is 0.01.

[0046] Step S14: Compare the target order and the pending orders in the execution report to obtain the comparison results.

[0047] Optionally, the execution report includes the user's declaration data, which includes the pending orders. Pending orders can refer to orders that have been submitted to the trading center but have not yet been executed.

[0048] Optionally, the comparison results may include: orders that are missing from the target order among the listed orders, and new orders that are added to the target order compared to the listed orders. The comparison process can be implemented by comparing the target order and the listed orders item by item.

[0049] Step S15: Based on the comparison results, the target order, and the pending orders, generate the order execution operation for the current period.

[0050] Optionally, the order execution operation may include order cancellation execution operation and order pending execution operation.

[0051] Optionally, the transaction data processing method further includes: acquiring market data at high frequency; and writing the market data into a real-time data warehouse via a message queue. The market data is used as a basis for backtesting and recording. The market data may refer to the market data of the electricity spot market trading center, and the data warehouse refers to a data warehouse.

[0052] Optionally, the method for generating order execution operations within the current period based on the comparison results, the target order, and the pending orders includes: updating user declaration data based on the execution report of the previous period; and generating order execution operations within the current period based on the comparison results, the target order, and the pending orders. The execution report of the previous period includes user declaration data that needs to be updated. The user declaration data may include the user's order records (including pending orders) and transaction records, and the user declaration data can be updated to the local database.

[0053] As described above, the transaction data processing method includes: obtaining the current electricity spot market price, the bidding strategies of several users, and the execution returns of the previous period; prioritizing the users based on the strategies and the market price to obtain a sorted user sequence; obtaining the user's target order based on the benchmark price determined by the market price and the strategy, the price adjustment step size and transaction volume in the strategy, and the user sequence; comparing the target order with the pending orders in the execution returns to obtain a comparison result; and generating an order execution operation for the current period based on the comparison result, the target order, and the pending orders.

[0054] By aggregating the market data, the strategy, and the previous period's execution results within the current period, comparing user orders within this period, and generating corresponding order execution operations, intra-period aggregation and account-level concurrency control are achieved. This enables stable throughput and low jitter under multiple parallel users, thereby improving the high-concurrency stability of the transaction data processing process.

[0055] Figure 3 This is a flowchart illustrating a method for obtaining the current electricity spot market price, the bidding strategies of several users, and the execution returns of the previous period according to an embodiment of this disclosure. The rolling trading front-end and back-end system includes a trading front-end and a trading back-end, such as... Figure 3 As shown in the embodiments of this disclosure, the method for obtaining the current electricity spot market conditions, the application strategies of several users, and the execution returns of the previous period includes the following steps S21 to S26.

[0056] Step S21: The transaction backend starts the time controller and periodically broadcasts the server time.

[0057] Step S22: The transaction front-end subscribes to the broadcast and corrects the local offset based on the broadcast server time.

[0058] Optionally, the local offset may refer to the offset of the transaction front-end time relative to the transaction back-end server time.

[0059] Step S23: The transaction backend obtains the trigger second.

[0060] Optionally, the trigger point can be a fixed number of seconds per minute, such as 13s, 28s, 43s, and 58s. The number of seconds can be flexibly set according to the actual situation, and this embodiment does not explicitly limit it.

[0061] Step S24: The transaction backend opens a receiving window based on the trigger second.

[0062] Optionally, the receiving window can refer to the window used to report the market data, the reporting strategy, and the execution report of the previous period. The window duration can be flexibly set according to the actual situation, for example, it can be 500ms-2000ms. This embodiment does not explicitly limit it in this way. The current receiving window can be regarded as the current period mentioned above, and the previous receiving window can be regarded as the previous period.

[0063] Optionally, the receiving window may also have a tolerance interval. The tolerance interval is used to treat reports falling within the tolerance interval as data for the current receiving window, while those exceeding the tolerance interval are automatically included in the next cycle, thereby reducing misjudgments and avoiding congestion. The tolerance interval can be flexibly set according to actual conditions, for example, it can be ±500ms, but this embodiment does not explicitly limit it.

[0064] Step S25: Based on the receiving window, the transaction front-end packages and reports the market data, the strategy, and the execution report at the aligned time.

[0065] Optionally, the aligned time can refer to the time after the transaction front-end aligns with the transaction back-end by correcting the local offset.

[0066] Step S26: The transaction backend obtains the market data, the strategy, and the execution result.

[0067] Figure 4 This is a flowchart illustrating a transaction data processing method according to an embodiment of this disclosure. Figure 4 As shown, the transaction data processing method provided in this embodiment includes the following steps S31 to S34.

[0068] Step S31: Deduplication is performed on duplicate policies reported by the same user in the policy, so as to retain the policy most recently reported by the user in the duplicate policy.

[0069] Step S32: Perform parameter verification on the market data and the strategy to obtain a verification result, which is either parameter verification passed or parameter verification failed.

[0070] Optionally, if the market data and strategy contain out-of-bounds parameters, duplicate order IDs (identifiers), or illegal direction flags, the verification result is that the parameter verification passes; otherwise, the verification result is that the parameter verification fails.

[0071] Step S33: Intercept the market data and strategies that fail the verification.

[0072] Optionally, the market data and strategies that fail the verification can be skipped, while the market data and strategies that pass the verification can be processed normally by the transaction data processing method described above.

[0073] Step S34: Mark the user as skipped based on the user's state.

[0074] Optionally, the implementation method for marking users who need to be skipped based on their user status includes: marking users whose status is disconnected, whose strategy is not loaded, or who are within the order cancellation cooldown period as skipped. When a user is marked as skipped, the transaction operations related to that user may not be executed.

[0075] Figure 5 This is a flowchart illustrating a method for prioritizing users based on the strategy and market conditions according to an embodiment of this disclosure to obtain a sorted user sequence. Figure 5 As shown, the process includes the following steps S41 to S42.

[0076] Step S41: Obtain a priority score based on the strategy and the market conditions.

[0077] Step S42: Sort the users according to their priority scores to obtain the user sequence.

[0078] The priority score is represented as follows:

[0079]

[0080] in, This indicates the priority score. This represents the default value for the user's score. Indicates the first weight. This represents the user's average transaction volume over the past 30 days. Indicates the second weight. This indicates the amount of electricity a user has traded that day in the market data. This represents the total transaction volume that the user expects under the stated strategy. Indicates the third weight. Indicates the fourth weight. This represents the user's risk coefficient. The first weight, the second weight, the third weight, the fourth weight, and the risk coefficient can be flexibly set according to actual conditions, and will not be elaborated on in this embodiment.

[0081] Figure 6 This is a flowchart illustrating a method for obtaining a user's target order based on a benchmark price determined by the market data and the strategy, the price adjustment step size and transaction volume in the strategy, and the user sequence, according to an embodiment of this disclosure. Figure 6 As shown, the process includes the following steps S51 to S52.

[0082] Step S51: Based on the benchmark price, the price adjustment step size, and the user sequence, obtain the price in the target order.

[0083] Optionally, when the target order belongs to the buyer's target order, the price of the target order = the base price + N × the price adjustment step size; when the target order belongs to the seller's target order, the price of the target order = the base price - N × the price adjustment step size; where N is a positive integer, and N represents the order of the user corresponding to the target order in the user sequence.

[0084] Step S52: Obtain the target order based on the price and the transaction volume in the target order.

[0085] Figure 7 This is a flowchart illustrating a method for generating order execution operations within the current period based on the comparison results, the target order, and the pending orders, according to an embodiment of this disclosure. Figure 7 As shown, the method for generating the order execution operation within the current period based on the comparison results, the target order, and the pending orders includes the following steps:

[0086] Step S1: Update user declaration data.

[0087] Step S2: When there is an order missing from the target order among the pending orders, generate a cancellation operation based on the target order and the pending orders.

[0088] Optionally, for example, if order A exists in the pending orders but not in the target orders, a corresponding cancellation operation needs to be generated for order A. This embodiment will not elaborate on this.

[0089] Step S3: When there is a new order in the target order compared to the pending orders, generate a pending order execution operation based on the target order and the pending orders.

[0090] Optionally, for example, if there is an order B in the target order but no order B in the pending orders, it is necessary to generate a corresponding pending order for order B and perform the operation. This embodiment will not elaborate on this.

[0091] Step S4: Record the audit log.

[0092] Optionally, steps S1 to S4 can all be atomic operations, which can be implemented through transactions. This embodiment will not elaborate on this further.

[0093] Optionally, the audit log may include a period number, user identifier, parameter summary, and result summary, and the audit log may refer to the log used to audit the user's operations within a period.

[0094] Figure 8 This is a schematic diagram illustrating the structure of a transaction data processing apparatus 800 according to an embodiment of this disclosure. Figure 8 As shown, the transaction data processing device 800 includes:

[0095] The market data acquisition module 810 is used to acquire the current electricity spot market data, the bidding strategies of several users, and the execution returns of the previous period.

[0096] The user sorting module 820 is used to prioritize the users based on the strategy and the market data to obtain a sorted user sequence.

[0097] The order acquisition module 830 is used to acquire the user's target order based on the benchmark price determined by the market data and the strategy, the price change step size and transaction volume in the strategy, and the user sequence.

[0098] The order comparison module 840 is used to compare the target order and the pending orders in the execution report to obtain the comparison results;

[0099] The operation generation module 850 is used to generate the order execution operation within the current period based on the comparison result, the target order, and the pending orders.

[0100] In the transaction data processing device 800, the market data acquisition module 810 and Figure 2 In the transaction data processing method, step S11 corresponds one-to-one, the user sorting module 820 corresponds one-to-one with step S12, the order acquisition module 830 corresponds one-to-one with step S13, the order comparison module 840 corresponds one-to-one with step S14, and the operation generation module 850 corresponds one-to-one with step S15.

[0101] In one embodiment of this disclosure, a front-end and back-end collaborative architecture for rolling transactions is provided. The core idea is: using a unified server time as a benchmark, a receiving window is opened at a fixed trigger time, aggregating market data and strategy submissions from multiple users within the window; after the window closes, a unified evaluation and generation of differential orders is performed, completing the writing of orders / transactions / logs from multiple users within a single transaction, and then acknowledging the front-end via a message channel. This process is performed rollingly, forming a stable rhythm. The system mainly consists of the following units:

[0102] Time control and synchronization unit: generates trigger beats, broadcasts server time, and coordinates front-end alignment.

[0103] Windowed data aggregation unit: When the window is open, it receives market data / status / strategy reports from multiple users, and outputs batches after the window is closed.

[0104] Policy evaluation and sorting unit: performs consistency checks, priority sorting, and target generation for multi-user policies within a batch.

[0105] Differential order generation unit: Compared with the previous period snapshot, only outputs the newly added / removed orders.

[0106] Transactional consistency write unit: Completes declaration updates, order placement and execution for multiple users, writes logs / audit records, and rolls back in case of anomalies within a single transaction.

[0107] Message distribution and session management unit: pushes order placement / cancellation / alarms / time broadcasts to the front end, and maintains session TTL (Time To Live), disconnection and reconnection recovery.

[0108] Rate limiting and caching unit: performs in-window rate limiting, duplicate parameter caching, and delay scheduling for access to the trading center API (Application Programming Interface).

[0109] Alignment Push and Display Unit: At the alignment moment, package and push market data, status, and execution results, while rendering the view locally and providing risk warnings.

[0110] Time control and synchronization include:

[0111] The system uses a fixed-beat trigger, where the backend opens a receiving window at multiple fixed seconds per minute (e.g., 13s, 28s, 43s, 58s) based on the system clock. The duration of the window is configurable (e.g., 500ms to 2000ms). This mechanism ensures that data from multiple users converges and aligns on the timeline, avoiding jitter and contention caused by processing data as it arrives.

[0112] The server broadcasts its timestamps at a frequency of seconds. Upon receiving the timestamps, the frontend calculates its local offset and adjusts the timing of the next push to ensure that pushes reach the window boundaries more precisely, thereby reducing the accumulation of time drift.

[0113] To address network jitter, this invention employs an arrival tolerance window (e.g., ±500ms): only reports falling within the tolerance window are considered current window data; those exceeding the tolerance window are automatically included in the next cycle, thus reducing misjudgments and avoiding congestion.

[0114] Windowed aggregation and consistency checks include:

[0115] Aggregation Rules: Latest Benchmark Priority: If multiple market data are received within a window, the data with the latest timestamp is used as the global evaluation benchmark; Source Deduplication: When the same user submits multiple reports, the most recent one is retained; Parameter Validation: Out-of-bounds parameters, duplicate order IDs (identifiers), illegal direction flags, etc. are intercepted; User Status Filtering: Users who are disconnected, whose strategies are not loaded, or who are in the order cancellation cooldown period are marked as skipped to avoid abnormal propagation.

[0116] Selection of benchmark market data:

[0117] Based on the latest-first consensus strategy, outdated market information decisions caused by network latency are reduced; in high-volatility scenarios, it can be configured as a majority consensus or a hybrid strategy of time + verification.

[0118] Strategy evaluation and prioritization include:

[0119] Evaluation factors: Each user is scored, which may include user weight, remaining capacity, risk coefficient, historical transaction efficiency, and deviation of the target price from the benchmark price. Users with higher scores receive a higher pricing position in that period, thereby increasing the probability of a successful transaction and ensuring fairness.

[0120] Differentiated pricing: In the same direction, prices are adjusted according to ranking, with increments / decrements of the smallest unit (e.g., highest bid price + step size × ranking). This maintains a competitive edge while avoiding contention caused by identical prices. Small change filtering: When price / quantity changes are below a threshold, prices remain unchanged for the current period, reducing meaningless order cancellations and risk control noise. The threshold can be set as an absolute value or a relative proportion to accommodate the liquidity of different assets.

[0121] Differential order generation includes:

[0122] Differential principle: Compare the target order set of the current period with the snapshot of pending orders from the previous period item by item. If they are completely consistent, skip them and do not issue duplicate orders. If any field is different, output a new order and (if an old order exists) simultaneously output a cancelled order. This differential strategy avoids duplicate order placement and unnecessary order cancellation, reducing the load on the trading center and network.

[0123] Safety net and protection: If the target volume of the strategy is not fully met in the order book, a pullback price or a protective price will be used to make up the difference to ensure that the transaction is covered; at the same time, for market conditions with large fluctuations, a protection skip will be triggered to avoid chasing the price incorrectly in volatile market conditions.

[0124] Transactional consistent writes include:

[0125] Single-transaction atomic commit: After the window closes and the strategy and differential are generated, the single-transaction write phase begins: 1. Update user declaration data (such as remaining available quantity, monitoring direction status); 2. Write new orders and new transactions; 3. Record audit logs and cycle numbers. Any sub-step that fails will be rolled back to ensure eventual consistency and avoid a half-commit state.

[0126] Concurrency control: Fine-grained concurrency control at the user level: the same user processes transactions serially during the transaction phase, while different users execute in parallel; eliminating race conditions for unloading / changing prices by the same user at the architectural level.

[0127] Auditability and traceability: Each transaction write is accompanied by a timestamp, window number, user identifier, and source summary; periodic replay can be implemented when necessary to verify the effect of the strategy and trace anomalies.

[0128] Message distribution and session management include:

[0129] Session state and TTL: The system maintains session state and TTL for each user. If the front-end disconnects or times out without reporting, it is marked as offline. Offline users will not block other users' window calculations. The architecture has user isolation and fault tolerance characteristics.

[0130] Receipt broadcasting and difference distribution: The backend pushes the order placement, cancellation, exception and time synchronization information of the period to the corresponding users one by one; it only distributes to users who need to update, reducing irrelevant traffic and client pressure.

[0131] Automatic recovery after disconnection: After the client reconnects, the system automatically recovers based on the session identifier: it sends the current server time, the latest policy status, and necessary resend messages, so that the user can seamlessly return to the current rolling cycle.

[0132] Rate limiting, caching, and aligned push notifications include:

[0133] In-window rate limiting: The front end maintains a local call counter in each time window. When the frequency limit threshold of the trading center is reached, subsequent requests for the same interface will be automatically delayed to the next window to avoid triggering risk control.

[0134] Consistent parameter caching: Requests with the same interface and the same parameters can directly reuse cached responses (the cache duration is consistent with the window), which significantly reduces redundant calls in high-frequency display / computation scenarios.

[0135] Aligned push and lightweight heartbeat: The front end broadcasts according to the server time, performs pre-calibration at the trigger second and packages and reports on time; during non-trading hours or empty windows, only heartbeat and minimal state synchronization are maintained, reducing bandwidth and computing burden.

[0136] Alternative embodiments and optional parameters:

[0137] Benchmark market selection: In addition to prioritizing the latest market data, a majority consensus or earliest arrival strategy can be adopted; a hybrid approach can also be used: prioritize the latest market data, and switch to majority consensus if the time distribution is too dispersed.

[0138] Trigger beats: The second-point sequence and window duration can be configured according to market rhythm, API frequency limiting, and network conditions (e.g., 4 / 6 / 12 times / minute; 500–2000ms).

[0139] Priority model: scalable factors (credit rating, transaction efficiency over the past N periods, risk weight of orders in transit, etc.) and supports parallel processing within the same group.

[0140] Small amount filtering: Absolute / relative thresholds, exponential smoothing, or adaptive thresholds can be used (the greater the fluctuation, the higher the threshold).

[0141] Transaction boundaries: While maintaining the order of declaration first and order second in a single cycle, it is possible to commit in batches by table or user, but atomic commit is still recommended for one user per cycle.

[0142] Message channel: WebSocket (a protocol for full-duplex communication over a single TCP connection) is the primary method, but it can also be downgraded to long polling / Server-Sent Events (server-sent events) in weak network scenarios.

[0143] Front-end form: In addition to plugins, it can be used as a browser extension, an embedded SDK (Software Development Kit), or a standalone front-end application, with the logic remaining unchanged.

[0144] The deployment and connection relationship of the front-end and back-end architecture of rolling transactions in this embodiment can be shown as follows:

[0145] Front-end: Deployed in the trading center page environment as a browser plugin / extension or embedded SDK; mainly includes components such as alignment push, rate limiting and caching, session and heartbeat, display and interaction.

[0146] Backend: Deployed in the cloud / local data center, providing unified time broadcasting, window aggregation, policy evaluation, differential generation, transaction writing, message distribution and session management capabilities.

[0147] On the trading center side: as the actual data source, it is responsible for the final matching and transaction confirmation; the system accesses its API / page interaction endpoints at a compliant frequency.

[0148] End-to-end operation process:

[0149] Startup and Alignment: The backend starts the time controller and periodically broadcasts the server time; the frontend subscribes to the broadcast, calculates the local offset, and enters standby mode.

[0150] Window reception: When the second point is triggered, the backend opens a receiving window; the frontend packages and reports the market data, strategy, and previous period's execution report at the aligned time.

[0151] Window closing and convergence: When the window is closed, the backend aggregates the valid reports within the window into a batch, selects the latest market data as the evaluation benchmark, and removes abnormal and duplicate sources.

[0152] Unified assessment: Scoring and ranking of multi-account strategies within a batch, and differentiated pricing and quantitative picking based on ranking; filtering out minor changes.

[0153] Differential generation: Compare the target order set with the snapshot of the previous period and output only the changed items (new order / removed order); add rollback / protection mechanism when necessary.

[0154] Transaction write: Complete declaration updates, order / transaction receipt and audit records within a single transaction; rollback occurs upon exception.

[0155] Receipt distribution: Push receipts to the corresponding accounts based on session mapping; offline accounts cache results and resend them upon reconnection.

[0156] Rolling to the next cycle: The time controller enters the next trigger point. If it is a non-trading period, the system will automatically reduce the frequency and only keep the system active.

[0157] Boundary and exception handling includes:

[0158] Time anomaly: If the client drift exceeds the threshold, the frontend will pause push and request realignment; the backend will issue an alert but will not interrupt other accounts.

[0159] Network jitter: Reports falling outside the tolerance range will be carried over to the next cycle to avoid contamination from incorrect reporting.

[0160] Order cancellation conflict: Order cancellations and new orders placed within the same account are processed sequentially at the account level to eliminate competition.

[0161] Write failure: The entire single-cycle transaction is rolled back; the window number and account list are recorded for easy replay and retry.

[0162] Disconnection recovery: After reconnection, the server time and the latest policy status are immediately sent, and the front end seamlessly resumes the current cycle.

[0163] Monitoring and maintenance include:

[0164] Delay observation: data collection and reporting arrival delay, data distribution within the window, and end-to-end receipt delay.

[0165] Consistency check: Compare local transaction records with transaction center reports, and if discrepancies are found, trigger a strategy slowdown or threshold adjustment.

[0166] Security and Audit: Audit logs include period number, account identifier, parameter summary and result summary to meet compliance requirements for record keeping.

[0167] Parameters and recommended configuration:

[0168] Trigger seconds: 4-6 per minute (Example: 13 / 28 / 43 / 58s).

[0169] Window duration: 500–1500ms (adjusted according to target concurrency / network fluctuations).

[0170] Small amount filtering threshold: 1 to 3 times the smallest variable price unit or 1 to 5% of the target amount.

[0171] Time tolerance range: ±300~800ms.

[0172] Transaction batch size: Batch size is divided into 10 to 100 based on the account / target dimension to ensure a balance between lock granularity and latency.

[0173] The aforementioned front-end and back-end architecture for rolling transactions has the following advantages:

[0174] Eventual time consistency: By using server time broadcasting, fixed beat, and tolerance interval, the consistency of arrival windows is ensured, significantly reducing the risk of incorrect windows and incorrect pricing.

[0175] High concurrency stability: Windowed aggregation + account-level concurrency control enables the system to maintain stable throughput and low jitter under O(1000) account concurrency.

[0176] Reduced request and write costs: Differential order placement and in-window caching significantly reduce the number of API calls and database writes to the trading center; batch unified submission reduces transaction overhead and lock contention.

[0177] Fault tolerance and self-recovery: User disconnection does not affect the overall system; automatic alignment of time / strategy after reconnection; transaction rollback ensures data consistency and auditability.

[0178] Fairness and controllability: Differentiated pricing based on priority avoids internal competition at the same price; parameters / thresholds / strategy factors can be flexibly adjusted to adapt to different targets and volatility environments.

[0179] Scalable and portable: It is a general-purpose design for regional power trading centers that does not depend on specific provincial or platform standards and has cross-market reuse value.

[0180] Figure 9 The diagram shown is a structural schematic of an electronic device according to an embodiment of this disclosure. Figure 9 As shown, the electronic device provided in this embodiment includes a processor and a memory. The memory is configured to store an executable program. The processor is configured to execute the program to cause the electronic device to perform the transaction data processing method according to any of the preceding claims.

[0181] Preferably, the processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can 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, or discrete hardware components. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0182] This embodiment also includes one or more of the following: a multimedia component, an input / output (I / O) interface, and a communication component.

[0183] The multimedia component may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is configured to output and / or input audio signals. For example, the audio component may include a microphone configured to receive external audio signals. The received audio signals may be further stored in memory or transmitted via a communication component. The audio component also includes at least one speaker configured to output audio signals. The I / O interface provides an interface between the processor and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. The communication component is configured to enable wired or wireless communication between the timer and other devices. Wireless communication may include Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, or 4G, or a combination thereof; therefore, the corresponding communication component may include a Wi-Fi module, a Bluetooth module, or an NFC module.

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

[0185] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of this disclosure, depending on actual needs. For example, the functional modules / units in the various embodiments of this disclosure may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

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

[0187] This disclosure also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the transaction data processing method and apparatus, electronic device, and storage medium provided in this disclosure. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor. The program can be stored in a computer-readable storage medium, which is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof. The storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0188] The above embodiments are merely illustrative of the principles and effects of this disclosure and are not intended to limit this disclosure. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this disclosure. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this disclosure should still be covered by the claims of this disclosure.

Claims

1. A method for processing transaction data, characterized in that, Applied to a rolling transaction front-end and back-end system, the transaction data processing method includes: Obtain the current electricity spot market price, the bidding strategies of several users, and the execution returns of the previous period; Based on the strategy and the market data, the users are prioritized to obtain a sorted user sequence. Based on the benchmark price determined by the market data and the strategy, the price adjustment step size and transaction volume in the strategy, and the user sequence, the user's target order is obtained; The target order and the pending orders in the execution report are compared to obtain the comparison results. Based on the comparison results, the target order, and the pending orders, generate the order execution operation for the current period; The method for prioritizing users based on the strategy and the market data to obtain a sorted user sequence includes: prioritizing users based on their average trading volume over the past 30 days, their trading volume for the day in the market data, and their expected total trading volume in the strategy to obtain a sorted user sequence. The method for obtaining a user's target order based on the benchmark price determined by the market data and the strategy, the price adjustment step size and transaction volume in the strategy, and the user sequence includes: obtaining the price in the target order based on the benchmark price, the price adjustment step size and the user sequence; and obtaining the target order based on the price in the target order and the transaction volume. When the target order belongs to the buyer, the price of the target order = the base price + N × the price adjustment step size; when the target order belongs to the seller, the price of the target order = the base price - N × the price adjustment step size; where N is a positive integer, and N represents the order of the user corresponding to the target order in the user sequence; The rolling trading front-end and back-end system includes a trading front-end and a trading back-end. The method for obtaining the current electricity spot market data, the application strategies of several users, and the execution reports from the previous period includes: the trading back-end starts a time controller and periodically broadcasts server time; the trading front-end subscribes to the broadcast and corrects its local offset based on the broadcast server time; the trading back-end obtains the trigger second; the trading back-end opens a receiving window based on the trigger second; based on the receiving window, the trading front-end packages and reports the data, strategies, and execution reports at the aligned time; the trading back-end obtains the data, strategies, and execution reports. Based on the comparison results, the target order, and the pending orders, the method for generating the order execution operation within the current period includes: step S1, updating user declaration data; step S2, when there are pending orders that are missing compared to the target order, generating a cancellation execution operation based on the target order and the pending orders; Step S3: When there is a new order in the target order compared to the pending orders, generate a pending order execution operation based on the target order and the pending orders; Step S4: Record the audit log.

2. The transaction data processing method according to claim 1, characterized in that, The transaction data processing method further includes: The duplicate policies reported by the same user in the policy are deduplicated to retain the policy most recently reported by the user in the duplicate policy. The market data and the strategy are validated to obtain a validation result, which is either parameter validation passed or parameter validation failed. Intercept market data and strategies that fail the verification. The user tagging process is skipped based on the user's state.

3. A transaction data processing device, characterized in that, Applied to a rolling transaction front-end and back-end system, the transaction data processing device includes: The market data acquisition module is used to obtain the current electricity spot market data, the bidding strategies of several users, and the execution returns of the previous period. The user sorting module is used to prioritize the users based on the strategy and the market data to obtain a sorted user sequence. The order acquisition module is used to acquire the user's target order based on the benchmark price determined by the market data and the strategy, the price change step size and transaction volume in the strategy, and the user sequence; The order comparison module is used to compare the target order and the pending orders in the execution report to obtain the comparison results; The operation generation module is used to generate the order execution operation within the current period based on the comparison result, the target order, and the pending orders; The method for prioritizing users based on the strategy and the market data to obtain a sorted user sequence includes: prioritizing users based on their average trading volume over the past 30 days, their trading volume for the day in the market data, and their expected total trading volume in the strategy to obtain a sorted user sequence. The method for obtaining a user's target order based on the benchmark price determined by the market data and the strategy, the price adjustment step size and transaction volume in the strategy, and the user sequence includes: obtaining the price in the target order based on the benchmark price, the price adjustment step size and the user sequence; and obtaining the target order based on the price in the target order and the transaction volume. When the target order belongs to the buyer, the price of the target order = the base price + N × the price adjustment step size; when the target order belongs to the seller, the price of the target order = the base price - N × the price adjustment step size; where N is a positive integer, and N represents the order of the user corresponding to the target order in the user sequence; The rolling trading front-end and back-end system includes a trading front-end and a trading back-end. The method for obtaining the current electricity spot market data, the application strategies of several users, and the execution reports from the previous period includes: the trading back-end starts a time controller and periodically broadcasts server time; the trading front-end subscribes to the broadcast and corrects its local offset based on the broadcast server time; the trading back-end obtains the trigger second; the trading back-end opens a receiving window based on the trigger second; based on the receiving window, the trading front-end packages and reports the data, strategies, and execution reports at the aligned time; the trading back-end obtains the data, strategies, and execution reports. Based on the comparison results, the target order, and the pending orders, the method for generating the order execution operation within the current period includes: Step S1, updating user declaration data; Step S2, when there are pending orders that are missing compared to the target order, generating a cancellation execution operation based on the target order and the pending orders; Step S3, when there are new orders in the target order compared to the pending orders, generating a pending order execution operation based on the target order and the pending orders; Step S4, recording audit logs.

4. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the transaction data processing method according to any one of claims 1 to 2.

5. An electronic device, characterized in that, include: The memory is configured to store a computer program; The processor is electrically coupled to the memory and configured to perform the transaction data processing method according to any one of claims 1 to 2.

Images