Full-duplex distributed investment transaction information pushing method and system

Abstract

The embodiment of the invention provides a full-duplex distributed investment transaction information pushing method and system, and relates to the technical field of investment transaction information management. According to the method, after a transaction request message sent by a client is acquired, at least one transaction service node is called according to a load balancing strategy to generate a transaction instruction. And requesting a delegation confirmation message according to the transaction instruction, sending the delegation confirmation message to the target service nodes of all subscription channels through the redis channel, and pushing the delegation confirmation message to the client through the target service nodes. According to the method, real-time feedback of investment transaction related delegation and transaction result information can be realized by using a distributed micro-service framework, a redis subscription publishing channel and a websocket full-duplex communication technology at the same time. According to the method, the network overhead can be effectively reduced, the response speed is increased, and the real-time performance of investment transaction information pushing is improved.

Description

Technical Field

[0001] This application relates to the field of investment transaction information management technology, and in particular to a full-duplex distributed investment transaction information push method and system. Background Technology

[0002] In the investment and trading fields such as securities and futures, trading systems need to acquire massive amounts of investment and trading data in real time, such as real-time fluctuations in stock prices and the latest quotes for futures contracts, and quickly send investors' trading orders to the trading engine. Driven by the demands of high-frequency trading and real-time decision-making in financial markets, investment and trading systems place extremely high requirements on the timeliness and interactivity of data transmission.

[0003] For example, an investment trading system can adopt a monolithic architecture, relying on independent information sending and receiving channels to push investment trading information in simplex or half-duplex mode. Simplex mode can only transmit investment trading information in one direction, while half-duplex mode can transmit investment trading information through bidirectional alternating transmission.

[0004] However, with the development of financial markets, the volume of transaction information has exploded. Due to insufficient data processing capabilities in some trading systems, they are unable to efficiently process and push massive amounts of real-time market data, transaction data, and other investment and trading information in a timely manner, resulting in significant delays in information delivery. This affects the real-time nature of investment and trading information delivery. For example, during periods of sharp market fluctuations, trading systems may be unable to quickly calculate or push accurate risk indicators, thereby affecting the timely adjustment of investment strategies. Summary of the Invention

[0005] In view of this, embodiments of this application provide a full-duplex distributed investment transaction information push method and system to solve the problem of poor real-time performance of investment transaction information push.

[0006] According to a first aspect of this application, a full-duplex distributed investment transaction information push method is provided, applied to a server, wherein the server establishes a communication connection with a client; the server includes a transaction gateway and multiple transaction service nodes based on a distributed microservice framework; the method includes: Obtain the transaction request message sent by the client, the transaction request message including the instruction elements filled in when placing the order and the transaction strategy; the instruction elements include the authorized user ID; In response to the transaction request message, at least one transaction service node is invoked according to the load balancing strategy to generate a transaction instruction, the transaction instruction including an instruction ID; The transaction instruction request confirmation message is a message data returned by the trading institution in response to the transaction instruction. The delegation confirmation message is sent to all target service nodes of the subscribed channels via a Redis channel. The target service node is the transaction service node that contains the binding mapping between user ID and session ID. The delegation confirmation message is pushed to the client through the target service node.

[0007] In some embodiments, the method further includes: Obtain the connection request message sent by the client, which is used to establish a Websocket connection between the transaction service node and the client; Extract authorization information from the request header of the connection request message. The authorization information includes the user ID and the role permissions corresponding to the user ID. By invoking the authentication and authorization service, permission verification is performed on the current client based on the authorization information. Upon successful permission verification, at least one transaction service node is invoked according to the load balancing strategy. A websocket connection is established between the transaction service node and the client based on the handshake protocol.

[0008] In some embodiments, establishing a WebSocket connection between the transaction service node and the client based on a handshake protocol further includes: Extract the user ID from the authorization information; A session instance is allocated for the websocket connection, and the session instance is set with a session ID; A session binding mapping is established based on the user ID and the session ID. The session binding mapping includes a binding mapping between the session ID and the session instance, and a binding mapping between the user ID and the session ID. The session binding mapping is stored in the transaction service node.

[0009] In some embodiments, the method further includes: A heartbeat strategy is set for the websocket connection, and the heartbeat strategy is used to maintain a long connection between the client and the transaction service node through heartbeat signals; Monitor session instance status based on the aforementioned heartbeat strategy; When the session instance is in an invalid state, the session binding mapping is cleared; the invalid state is the instance state triggered when the client actively closes the session instance or when the authentication and authorization of the session instance expires.

[0010] In some embodiments, requesting a confirmation message based on the transaction instruction includes: The trading instruction is split into several trading orders according to the trading strategy; The transaction order is sent to the relevant transaction interface of the trading institution through the transaction gateway; The transaction gateway receives the order confirmation message. Based on the instruction ID and the delegation confirmation message, add a binding mapping between the user ID and the instruction ID.

[0011] In some embodiments, the method further includes: A client list is constructed based on the transaction instruction and the order confirmation message; the client list includes transaction element information of the transaction instruction; the transaction element information includes at least one of order progress, transaction progress, and average transaction price; The transaction gateway receives transaction flow information, which is the flow information issued by the transaction institution in response to the transaction instruction. Perform logical calculations on the transaction information to update the transaction element information; Modify the element fields in the client list based on the updated transaction element information.

[0012] In some embodiments, the method further includes: The final state event of the monitoring connection status is an event triggered when the instruction is issued abnormally or the strategy algorithm stops; Generate a final state message based on the final state form event; The final state message is sent to the target service nodes of all subscribed channels via a Redis channel; The final state message is pushed to the client through the target service node, and the binding mapping between user ID and command ID is cleared.

[0013] In some embodiments, the method further includes: Obtain the subscription message sent by the client, wherein the subscription message includes the specified security code; According to the load balancing strategy, at least one transaction service node is invoked to add a binding mapping between session ID and security code; By subscribing to the message queue topic subscription of the aforementioned stock code through the market information service, relevant stock market information can be obtained; The relevant market data is sent to all subscription service nodes that subscribe to the Redis channel via a Redis channel; the subscription service node is a trading service node that contains a binding mapping between session ID and security code. The market information is sent to the client via a WebSocket connection.

[0014] In some embodiments, the method further includes: Retrieve the market data subscription messages specified by the client; According to the load balancing strategy, call at least one transaction service node to add the market data list corresponding to the session ID; Call the full market information interface of the market information service to return full market information through message queue topic subscription; The market data list is updated based on the full market data, and the newly added market data list is sent to all transaction service nodes of the subscribed channels through the Redis channel; If the market data list corresponding to the session ID in the transaction service node is not empty, the newly added market data list will be sent to the client.

[0015] According to a second aspect of this application, a full-duplex distributed investment transaction information push system is provided. The system includes a client and a server, and the server establishes a communication connection with the client. The server includes a transaction gateway and multiple transaction service nodes based on a distributed microservice framework. The client is configured to send a transaction request message to the server, the transaction request message including the instruction elements filled in when placing the order and the transaction strategy; the instruction elements include the authorized user ID; The server is configured as follows: Obtain the transaction request message sent by the client; In response to the transaction request message, at least one transaction service node is invoked according to the load balancing strategy to generate a transaction instruction, the transaction instruction including an instruction ID; The transaction instruction request confirmation message is a message data returned by the trading institution in response to the transaction instruction. The delegation confirmation message is sent to all target service nodes of the subscribed channels via a Redis channel. The target service node is the transaction service node that contains the binding mapping between user ID and session ID. The delegation confirmation message is pushed to the client through the target service node.

[0016] According to a third aspect of this application, a computer device is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the program to implement the above-described full-duplex distributed investment transaction information push method.

[0017] According to a fourth aspect of this application, a storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements the above-described full-duplex distributed investment transaction information push method.

[0018] By employing the above technical solutions, embodiments of this application provide a full-duplex distributed investment transaction information push method and system. The method, after obtaining a transaction request message sent by a client, calls at least one transaction service node according to a load balancing strategy to generate a transaction instruction. Then, it requests an order confirmation message based on the transaction instruction and sends the order confirmation message to the target service nodes of all subscribed channels via a Redis channel. The target service nodes then push the order confirmation message to the client. This method utilizes a distributed microservice framework and simultaneously uses Redis publish-subscribe channels and WebSocket full-duplex communication technology to achieve real-time feedback of investment transaction-related order and transaction result information. This method can effectively reduce network overhead, accelerate response speed, and improve the real-time performance of investment transaction information push.

[0019] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This application provides an overall architecture diagram of an investment trading system. Figure 2 This is a schematic diagram of the investment transaction information push method provided in the embodiments of this application; Figure 3 This is a schematic diagram illustrating the process of establishing a WebSocket connection as provided in an embodiment of this application. Figure 4 This is a schematic diagram of the client-side transaction instruction order placement and transaction monitoring process provided in an embodiment of this application; Figure 5 This is a schematic diagram of the subscription message push process provided in an embodiment of this application; Figure 6 This is a schematic diagram of the client-side price quote monitoring process provided in an embodiment of this application; Figure 7 This is a schematic diagram of the market data list monitoring process provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of the investment transaction information push system provided in the embodiments of this application. Detailed Implementation

[0021] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0022] In this embodiment, the full-duplex distributed investment transaction information push method can be used for information push and transaction data transmission processes in an investment transaction system. Investment transaction information refers to all transaction-related information that can be transmitted between a client and a server in the securities, futures, and other investment transaction fields. For example, investment transaction information may include real-time stock price fluctuations, the latest quotes for futures contracts, and other market data, as well as user-initiated trading instructions, security codes, subscription services, and other information.

[0023] An investment trading system is a server-side data interaction system that interacts with user clients to process, push, and store investment trading information in response to user commands. It requires real-time acquisition of massive amounts of investment trading information, such as market data, and rapid delivery of investor trading orders to the trading engine. This meets the demands for timeliness and interactivity in data transmission driven by the high-frequency trading and real-time decision-making needs of the financial market.

[0024] To meet the timeliness requirements for processing investment transaction information, in some embodiments, the investment transaction system can adopt a monolithic architecture, relying on independent information sending and receiving channels to push investment transaction information in simplex or half-duplex mode. The simplex mode can only transmit investment transaction information unidirectionally, while the half-duplex mode can transmit investment transaction information through bidirectional alternating transmission.

[0025] Because the investment trading system uses a monolithic architecture, it struggles to cope with the ever-increasing trading volume and complex business needs. Furthermore, the monolithic architecture results in poor scalability and flexibility, high upgrade and maintenance costs, and a susceptibility to single points of failure, impacting the system's stability and reliability.

[0026] Furthermore, with the development of financial markets, the volume of transaction data has exploded. However, due to insufficient data processing capabilities in some investment and trading systems, they are unable to efficiently process and analyze massive amounts of real-time market and transaction data in a timely manner, resulting in data delays and affecting the timeliness of trading decisions. For example, during periods of sharp market fluctuations, the system may be unable to quickly calculate accurate risk indicators, making it difficult for investors to adjust their strategies in a timely manner.

[0027] Furthermore, in the mobile internet era, investors hope to be able to trade anytime, anywhere across different devices and platforms. However, some investment trading systems perform poorly in terms of multi-platform compatibility, offering poor display quality and user experience on mobile devices such as smartphones and tablets, or experiencing untimely data synchronization between different platforms, causing inconvenience to investors.

[0028] To address the issue of poor real-time delivery of investment transaction information, some embodiments of this application provide a full-duplex distributed investment transaction information delivery method, such as... Figure 1 As shown, the method utilizes a distributed microservice framework and simultaneously employs Redis publish-subscribe channels and WebSocket full-duplex communication channels to achieve global message push under a distributed microservice multi-active multi-node environment.

[0029] A distributed microservice framework refers to a distributed system based on a microservice architecture. In a distributed microservice framework, microservices are an architectural style that divides a single application into a set of small, loosely coupled services. Each service runs in its own process and collaborates through lightweight communication mechanisms such as HTTP / REST and gRPC. A distributed system refers to these microservices deployed in a network cluster of multiple computers (nodes) to collaboratively complete a common task.

[0030] A distributed microservice framework enables high scalability and flexibility in systems. This means that as business grows, the workload of an investment trading system may increase with the number of users, the variety of trading instruments, and the frequency of transactions. The distributed microservice framework allows each service to scale independently, flexibly adding or removing resources based on the load requirements of different business modules. For example, during peak trading periods, server instances can be added separately for core services such as order processing and market data acquisition to ensure the system can stably handle a large number of concurrent transactions.

[0031] Distributed microservice frameworks can also adapt to real-time business changes, namely the continuous evolution of financial markets and investment operations, and the emergence of new trading strategies, product types, and business rules. Microservice architecture enables systems to respond quickly to these changes by modifying, upgrading, or replacing individual microservices without requiring large-scale modifications to the entire system. For example, when launching a new investment product, only the relevant functionality needs to be added to the corresponding product management microservice, without affecting the normal operation of other services.

[0032] Distributed microservice frameworks offer high reliability and stability, implementing fault isolation and tolerance mechanisms. Regarding fault isolation, in an investment trading system, the failure of any single service can lead to severe consequences. Microservice architecture breaks down the system into multiple small, relatively independent services. When a microservice fails, only that service is affected, preventing the entire system from crashing. For example, if the market data service encounters a problem, only market data display and related analytical functions that rely on it will be affected, while other critical services such as order processing and account management will continue to operate normally, ensuring that the core business of the system remains unaffected.

[0033] Regarding fault tolerance mechanisms, microservice distributed frameworks can provide rich fault tolerance mechanisms, such as circuit breakers, retries, and degradation. Taking circuit breakers as an example, when calls to a microservice fail frequently, the circuit breaker automatically cuts off calls to that service, preventing system resource exhaustion due to a large number of invalid requests. Simultaneously, the system can retry service calls under certain conditions through retry mechanisms, improving system resilience. Degradation strategies allow for providing basic alternative functions or returning default values ​​when services are unavailable, ensuring the availability of basic system functions and improving user experience.

[0034] In a distributed microservice framework, the required functionalities can be implemented through microservice instances. An instance is a running process or container of a microservice. Each instance can be deployed with corresponding memory space, CPU time, and network ports. Furthermore, multiple instances are isolated from each other; the crash of one instance will not directly affect other instances. For example, a long-lived connection used to implement data transfer between a client and a server is called a session instance.

[0035] A Redis channel is a message channel within the Redis publish / subscribe (Pub / Sub) model. As a messaging mechanism, Redis channels enable communication between publishers and subscribers. Publishers can send messages to specific channels, while subscribers can subscribe to one or more channels to receive messages sent to them. The Redis server maintains a list of subscribers for each channel. When a message is published to a channel, it iterates through the subscriber list and pushes the message to each subscriber.

[0036] WebSocket is a network communication protocol that allows full-duplex communication between browsers and servers, meaning both parties can send and receive data simultaneously. Data can flow freely in both directions within a WebSocket channel. The WebSocket channel goes through four stages: handshake, connection establishment, data transmission, and connection closure. It boasts advantages such as strong real-time performance, low network overhead, and full-duplex communication, thus meeting the high real-time requirements of investment transactions.

[0037] Based on the WebSocket network communication protocol, a session can also be established between the client and the server, known as a WebSocket session. A WebSocket session is a persistent connection established between the client and the server via the WebSocket protocol, during which bidirectional real-time data can be exchanged.

[0038] The method can be applied to a server. The server establishes a communication connection with the client, and the server includes a transaction gateway and multiple transaction service nodes based on a distributed microservice framework. The method can also be applied to electronic devices with data processing capabilities. These electronic devices include, but are not limited to, computers, mobile terminals, smart wearable devices, and industrial control machines. For ease of description, this application embodiment uses a server as the execution subject of the method. It should be understood that the method can also be applied to other types of execution subjects, which are not shown one by one in this application embodiment. Figure 2 As shown, the method includes: S101. Obtain the transaction request message sent by the client.

[0039] To process investment transaction information, the server can first obtain the transaction request message sent by the client. This transaction request message includes the instruction elements for placing the order and the transaction strategy, and the instruction elements include the authorized user ID.

[0040] Transaction request messages can be obtained through the communication channel between the client and the server. This communication channel can be based on full-duplex WebSocket communication. WebSocket is a full-duplex communication protocol provided by HTML5, establishing a persistent connection through a single HTTP handshake, effectively avoiding the overhead of frequent handshakes in the HTTP request and response model. In investment trading systems, WebSocket can be used to implement real-time market data pushes and trading instruction interaction.

[0041] Therefore, in order to obtain the transaction request messages sent by the client, a WebSocket connection can be established between the client and the server first. That is, Figure 3 As shown, in some embodiments, the server may first obtain a connection request message sent by the client. This connection request message is used to establish a WebSocket connection between the transaction service node and the client.

[0042] Next, authorization information is extracted from the request header of the connection request message. This authorization information includes the user ID and the role permissions corresponding to the user ID. Then, the authentication and authorization service is invoked to perform permission verification on the current client based on the authorization information. If the permission verification is successful, at least one transaction service node is invoked according to the load balancing strategy, and a WebSocket connection is established between the transaction service node and the client based on the handshake protocol.

[0043] For example, a user can request a WebSocket connection with the server through the user interface client, that is, send a connection request message to the server through the client. After the connection request message is sent to the server, the transaction gateway on the server will receive the connection request message first. At this time, the transaction gateway can forward the connection request message to the authorization node, so that the authorization node can determine the current user and the user's role permissions based on the authorization information in the request header of the message.

[0044] The server-side authentication node verifies the authorization information to obtain the authentication result. When the authentication fails, it directly returns a message to the client indicating that the current user does not have the required permissions. Conversely, when the server-side authentication succeeds, it proceeds to the next step: through the transaction gateway, based on the load balancing strategy, it calls one of the transaction service nodes to perform a connection protocol handshake. After completing the three-way handshake, a WebSocket connection is established between the client and the server (transaction service node).

[0045] After establishing a reliable WebSocket connection through a three-way handshake, the application layers of both communicating parties can send and receive data to each other simultaneously, ensuring the synchronous interaction of trading instructions and market information. Therefore, in investment trading scenarios, investors can place trading orders instantly while continuously receiving the latest market data such as asset prices and trading volumes, without waiting for the data transmission direction to switch.

[0046] In some embodiments, to maintain a WebSocket connection, when establishing a WebSocket connection between the transaction service node and the client based on a handshake protocol, the server can also extract a user ID from the authorization information and allocate a session instance for the WebSocket connection. This session instance can be configured with a session ID (sessionId). Then, a session binding mapping is established based on the user ID and the session ID. This session binding mapping includes a binding mapping between the session ID and the session instance, and a binding mapping between the user ID and the session ID. The session binding mapping is then stored in the transaction service node as a credential for maintaining the WebSocket connection between the transaction service node and the client.

[0047] For example, when the three-way handshake protocol is completed and a WebSocket connection is established between the client and the server (transaction service node), a binding mapping between session IDs and session instances can be established in the server's memory.<sessionId,session> The mapping. And establishing the binding mapping between user ID and session ID, i.e.<userId,sessionId> The mapping.<sessionId,session> The mapping can be used to establish a mapping from a session ID to a specific session instance.<userId,sessionId> The mapping can be used to establish a mapping relationship between user ID and session ID.

[0048] After a WebSocket connection is established, the client and server can maintain a persistent connection using heartbeat signals. Specifically, in some embodiments, the server can set a heartbeat strategy for the WebSocket connection, whereby the heartbeat strategy is used to maintain a persistent connection between the client and the transaction service node through heartbeat signals.

[0049] The session instance status is then monitored based on a heartbeat policy, and the session binding mapping is cleared when the session instance status is invalid. The invalid status is triggered when the client actively closes the session instance or when the session instance's authentication and authorization expire.

[0050] For example, if the client and server can maintain a persistent connection via heartbeats during communication, then when the client actively closes the connection / session, it can trigger server-side cleanup.<sessionId, session> mapping and<userId,sessionId> The mapping. Furthermore, asynchronous scheduled tasks can be started on the server side to periodically clean up expired sessions and sessions with expired authentication and authorization, while also cleaning up the aforementioned...<sessionId, session> mapping and<userId, sessionId> The mapping.

[0051] Furthermore, if a WebSocket connection needs to be re-established between the server and the client after the client stops monitoring the heartbeat signal, the steps described above—obtaining the connection request message, extracting authorization information from the request header of the connection request message, performing permission verification on the current client based on the authorization information, calling the transaction service node according to the load balancing strategy, and establishing a WebSocket connection based on the handshake protocol—must be repeated to complete the WebSocket connection reconnection.

[0052] After establishing a WebSocket connection between the client and server, the user can place an order by filling in the instruction elements and trading strategy through the client, thus forming a transaction request. The transaction request message corresponding to the transaction request is then sent to the server through the established WebSocket connection.

[0053] In some embodiments, after receiving a transaction request message, the server's transaction gateway can also verify the user's permissions corresponding to the client. This involves calling the authentication and authorization service to verify the user's role permissions, transaction type permissions, and other permissions. If the server-side verification fails, it will directly return a message to the client indicating that the current user does not have the required permissions. If the server-side verification succeeds, subsequent operations can continue.

[0054] S102. In response to the transaction request message, at least one transaction service node is invoked according to the load balancing strategy to generate a transaction instruction.

[0055] After receiving the transaction request message and verifying it through the authentication and authorization service, the server can respond to the transaction request message by invoking at least one transaction service node according to the load balancing strategy to generate transaction instructions. The load balancing strategy, deployed on the server, is used to distribute network requests among multiple transaction service nodes using rules and algorithms. The load balancing strategy can reasonably distribute external or internal workloads (requests) across multiple transaction service nodes (or service instances) to avoid overloading a single transaction service node, thereby improving the throughput, availability, and fault tolerance of the entire system.

[0056] The trading instruction refers to the control command used to trigger the transmission of investment trading information. That is, the server can perform relevant operations on investment trading with exchanges and other trading institutions based on the trading instruction, thereby generating investment trading information. Therefore, the trading instruction can include an instruction ID. The instruction ID is used to uniquely indicate the trading instruction through numerical or string information. For this purpose, the trading gateway in the server can, according to a load balancing strategy, call one of the trading service nodes to send the trading instruction and generate a unique instruction ID.

[0057] In some embodiments, after invoking at least one trading service node, the server can use the invoked trading service node to approve investment trading-related roles. Following the approval process for these roles, the system can also verify account management service permissions and conduct risk control management checks on positions, risk levels, and other warning thresholds. If any of these verifications fails, an error message can be directly returned to the client. Once all verifications pass, the next step can begin.

[0058] S103. Request a confirmation message based on the transaction instruction.

[0059] After generating a trading instruction, the server can request a commission confirmation message based on the trading instruction. The commission confirmation message is the message data feedback by the trading institution for the trading instruction. That is, the trading service node called by the server can send the trading instruction to the trading institution, so that the trading institution can feedback the commission confirmation message according to the trading instruction and send it to the trading service node.

[0060] In order to obtain the commission confirmation message, in some embodiments, when the server executes the request for the commission confirmation message according to the trading instruction, it can first split the trading instruction into several trading commissions according to the trading strategy, and then send the trading commissions to the relevant trading interfaces of the trading institution through the trading gateway, triggering the trading institution to feedback the commission confirmation message according to the trading commission. Then, the commission confirmation message is received through the trading gateway, and the binding mapping of the user ID and the instruction ID is added based on the instruction ID and the commission confirmation message.

[0061] For example, as Figure 4 shown, the trading service node called in the server can split the trading instruction into several trading commissions according to the trading strategy and send them to the trading gateway respectively. The trading gateway will uniformly send the trading commissions to the relevant trading interfaces of the exchange and the inter-bank market.

[0062] The trading gateway then listens to the relevant trading interfaces to receive the commission confirmation message. Then, the message packet corresponding to the received commission confirmation message is returned to the trading service node. After receiving the commission confirmation message, the trading service node will add the binding mapping of <userId, instruction ID>.

[0063] S104. Send the commission confirmation message to all target service nodes subscribing to the channel through the redis channel.

[0064] After requesting the commission confirmation message, the server can push the commission confirmation message to the client. When pushing the commission confirmation message, the server can first determine the trading service nodes participating in the push. That is, the commission confirmation message is sent to all target service nodes subscribing to the channel through the redis channel.

[0065] The Redis channel refers to a data transmission channel built by the Redis service in the server, which is used to implement the publish or subscribe (Publish / Subscribe) function. The Redis channel allows clients or trading service nodes to publish messages to a specified channel, enabling other clients subscribing to this channel to receive these messages, thereby achieving message broadcasting and communication between multiple clients.

[0066] The target service node is the transaction service node that contains the binding mapping between user IDs and session IDs. That is, the server can determine the node containing the binding mapping by traversing the binding mapping content within the transaction service node.<userId,sessionId> The transaction service node of the binding mapping is used as the target service node.

[0067] Then, the transaction instruction confirmation message is sent to all other transaction service nodes that have subscribed to the channel via a Redis channel. This ensures that each subscribed channel containing the transaction instruction confirmation message is valid.<userId, sessionId> The mapping transaction service allows transaction nodes to participate in message push.

[0068] S105. Push the delegation confirmation message to the client through the target service node.

[0069] After sending the order confirmation message to all target service nodes of the subscribed channels, the server can push the order confirmation message to the client through the target service nodes. That is, after the server sends the order confirmation message of the transaction instruction to all other transaction service nodes of the subscribed channels via the Redis channel, if any of the transaction service nodes contains...<userId,sessionId> If the binding mapping is established, the transaction service node can be used as the target service node. Therefore, the session instance of the target service node can be used to send a delegation confirmation message to each client, so that each client of that user who receives the delegation confirmation message can trigger subsequent client processing flows such as message notification or list status change.

[0070] After identifying the target service node, the subsequent transaction gateway will directly return the received investment transaction information to the relevant target service node, where it will process the information to form pushable investment transaction information. Therefore, in some embodiments, the server can construct a client list based on transaction instructions and order confirmation messages. The client list includes transaction element information of the transaction instructions; the transaction element information includes at least one of order progress, transaction progress, and average transaction price.

[0071] The transaction gateway then receives transaction flow information and performs logical calculations on it to update the transaction element information. This transaction flow information is the transaction log information issued by the trading institution in response to the transaction order. Finally, the element fields in the client list are modified based on the updated transaction element information.

[0072] For example, after determining the target service node and pushing investment transaction information through the target service node, the trading gateway will continuously return the received transaction settlement information to the relevant trading service nodes. The target service node then updates the transaction elements information such as the entrustment progress, transaction progress, and transaction average price of the relevant instructions through logical calculation based on the received transaction settlement information, and then returns the received entrustment confirmation message to the trading service node through the trading gateway. A similar information transfer process continuously updates the fields such as the entrustment progress, transaction progress, and transaction price in the client list.

[0073] The server can also perform event listening on the investment transaction information and make corresponding adjustments based on the monitored events. Therefore, in some embodiments, the server can monitor the terminal form events of the connection status, where the terminal form event is an event triggered when the instruction issuance is abnormal or the policy algorithm stops.

[0074] Then, generate a terminal message based on the terminal form event, and send the terminal message to all target service nodes subscribing to the channel through the redis channel. Then, push the terminal message to the client through the target service node, and clear the binding mapping between the user ID and the instruction ID.

[0075] For example, through continuous listening to the investment transaction data pushing process, if an abnormality occurs during the instruction issuance process, or a terminal form such as the policy algorithm stops, the terminal message will be pushed to all other trading service nodes subscribing to the channel through the redis channel. If each trading service node contains a mapping of <userId, sessionId>, the terminal message will be sent to each client through the session instance (session) of the trading service node. At the same time, each trading service node can correspondingly clear the binding mapping of <userId, instruction ID>.

[0076] By applying the technical solution of the above embodiment, the full-duplex distributed investment transaction information pushing method described in the above embodiment can adopt a distributed microservice framework and use both the redis subscription and publishing channel and the websocket full-duplex communication connection to achieve real-time feedback of the relevant entrustments after the investment instruction is placed in the investment trading system. Due to the use of full-duplex communication, investment trading information such as market data can be continuously pushed from the data provider to the investor terminal, and at the same time, the buy and sell instructions issued by the investor can also be transmitted reversely to the trading server with low latency, ensuring that trading decisions are based on the latest market information and improving the instruction execution speed.

[0077] Moreover, due to the characteristic of full-duplex communication allowing data to be transmitted simultaneously in both directions, it can significantly improve trading efficiency, reduce latency risks, adapt to the requirements of high-frequency trading and real-time decision-making in the financial market, and meet the high requirements of the investment trading system for the timeliness and interactivity of data transmission.

[0078] In some embodiments, as a refinement and extension of the specific implementation manners of the above embodiments, in order to completely illustrate the specific implementation process of this embodiment, some embodiments of this application further provide a full-duplex distributed investment trading information pushing method, as Figure 5 shown, the method includes: S201. Obtain a subscription message sent by a client; S202. According to the load balancing policy, call at least one trading service node to add a binding mapping between a session ID and a security code; S203. Subscribe to the message queue topic of the security code by calling the market information service to obtain relevant underlying market information; S204. Send the relevant underlying market information to all subscription service nodes subscribing to the redis channel through the redis channel; S205. Send the market information to the client through a websocket connection.

[0079] In order to implement real-time feedback of relevant entrustment and transaction results after an investment order is placed in an investment trading system, the server can obtain a subscription message sent by a client, where the subscription message includes a specified security code.

[0080] Then, according to the load balancing policy, call at least one trading service node to add a binding mapping between a session ID and a security code. Then subscribe to the message queue topic of the security code by calling the market information service to obtain relevant underlying market information.

[0081] For example, as Figure 6 shown, when performing monitoring on the specified security market, the user can control the client to send several specified security code market subscription messages to the server through the websocket channel. After receiving the market subscription message packet, the trading gateway of the server calls the authentication and authorization service to verify the role permissions and market viewing permissions of the trading user, etc. When the verification fails on the server side, it directly returns that the current user has no such permissions; when the verification passes on the server side, the subsequent operations are continued, that is, the trading gateway calls one of the trading service nodes according to the load balancing policy to add a mapping of <sessionId, security code>. The trading service node can subscribe to the relevant security code by calling the market information service and continuously obtain the latest market information of the relevant underlying through the message queue topic subscription.

[0082] Then, send the relevant underlying market information to all subscription service nodes that subscribe to the redis channel through the redis channel, so as to send the market information to the client through the websocket connection. Among them, the subscription service node is a trading service node that contains the binding mapping of the session ID and the security code.

[0083] For example, after receiving the market information, the trading service node can send the market information of the security code to all trading service nodes that subscribe to the redis channel through the redis channel. If the trading service node contains the binding mapping of <sessionId, security code>, it can be used as a subscription service node for message push. Therefore, the market information can be directly sent to the client through the websocket channel.

[0084] Similarly, if the client stops subscribing to the market message, the client sends a stop subscription message to the server through the websocket channel. The server will clean up the binding mapping of <sessionId, security code>, and at the same time send an unsubscribe message to the market information service to cancel the topic subscription in the message queue.

[0085] By applying the technical solution of the above embodiment, the full-duplex distributed investment trading information push method described in the above embodiment can utilize the distributed microservice framework, and at the same time use the redis subscription and publication channel and the websocket full-duplex communication connection to realize the real-time feedback of the relevant entrustment and relevant transaction results after the investment order is placed in the investment trading system. The method can obtain more comprehensive market information in a more timely manner, including price changes, depth of buy and sell orders, etc., so as to grasp the market dynamics more accurately for investment decision-making. Timely investment trading information interaction helps investors participate in market transactions more actively, increasing the liquidity and activity of the market.

[0086] In some embodiments, as a refinement and extension of the specific implementation manner of the above embodiment, in order to fully illustrate the specific implementation process of this embodiment, some embodiments of this application also provide a full-duplex distributed investment trading information push method, as Figure 7 shown, the method includes: S301. Obtain the market list subscription message specified by the client; S302. According to the load balancing strategy, call at least one trading service node to add the market list corresponding to the session ID; S303. Call the full market information interface of the market information service to return the full amount of market information through the message queue topic subscription; S304. Update the market list based on the full amount of market information, and send the newly added market list to all trading service nodes that subscribe to the channel through the redis channel; S305. If the market data list corresponding to the session ID in the transaction service node is not empty, the newly added market data list will be sent to the client.

[0087] To enable real-time updates of market data, the server can obtain the market data list subscription message specified by the client and, based on the load balancing strategy, call at least one trading service node to add the market data list corresponding to the session ID.

[0088] Then, by calling the full market data interface of the market data service, full market data is returned according to the message queue topic subscription. This updates the market data list based on the full market data and sends the newly added market data list to all subscribed trading service nodes via Redis channels. Finally, by checking the market data list corresponding to the session ID in the trading service node, if the market data list corresponding to the session ID in the trading service node is not empty, the newly added market data list is sent to the client.

[0089] For example, market data monitoring doesn't monitor specific code; instead, it continuously refreshes the market data list globally, using a message propagation mechanism similar to broadcasting. Therefore, the user's client first sends a market data subscription message via a WebSocket channel. Upon receiving this message, the trading gateway on the server calls the authentication and authorization service to verify the trading user's role permissions and market data viewing permissions. If server-side verification fails, it directly returns that the current user does not have the necessary permissions; if server-side verification succeeds, it continues with subsequent operations.

[0090] The transaction gateway then calls one of the transaction service nodes according to the load balancing strategy and adds it. <sessionid>The trading service node then calls the full market data interface of the market data service, and returns the full market data information through message queue topic subscription. At this time, after a trading service node finishes consuming the newly arrived market data message, it sends the newly added market data list to all trading service nodes subscribed to that Redis channel through a Redis channel. If that node... <sessionid>If the market data list is not empty, then the newly added market data list information will be sent to the client. In addition, if a client stops subscribing to market data, it sends a stop-subscription message to the server via WebSocket, and the server will then clean up the subscription. <sessionid>The system displays the market data list and simultaneously sends an unsubscribe message to the market information service, thus disabling the topic subscription in the message queue.

[0091] By applying the technical solutions of the above embodiments, the full-duplex distributed investment transaction information push method described in the above embodiments can utilize a distributed microservice framework and simultaneously use Redis publish-subscribe channels and WebSocket full-duplex communication technology to achieve real-time updates of market data display content, thereby improving the real-time performance of the investment transaction process.

[0092] The method also supports high-frequency trading, and for high-frequency trading strategies, the use of full-duplex communication technology can meet their stringent requirements for high-speed, real-time data transmission and instruction execution. The method can complete a large number of trading operations in a very short time and can detect minute market price fluctuations, thus promoting the market's price discovery function and improving the effectiveness of information push.

[0093] In some embodiments, as a specific implementation of the full-duplex distributed investment transaction information push method described in the above embodiments, some embodiments of this application also provide a full-duplex distributed investment transaction information push system, such as... Figure 8 As shown, the system includes a client and a server.

[0094] The server establishes a communication connection with the client; the server includes a transaction gateway and multiple transaction service nodes based on a distributed microservice framework.

[0095] The client is configured to send a transaction request message to the server, the transaction request message including the instruction elements to be filled in when placing the order and the transaction strategy; the instruction elements include the authorized user ID.

[0096] The server is configured to perform the following steps: Obtain the transaction request message sent by the client; In response to the transaction request message, at least one transaction service node is invoked according to the load balancing strategy to generate a transaction instruction, the transaction instruction including an instruction ID; The transaction instruction request confirmation message is a message data returned by the trading institution in response to the transaction instruction. The delegation confirmation message is sent to all target service nodes of the subscribed channels via a Redis channel. The target service node is the transaction service node that contains the binding mapping between user ID and session ID. The delegation confirmation message is pushed to the client through the target service node.

[0097] By applying the technical solutions of the above embodiments, the full-duplex distributed investment transaction information push system described in the above embodiments can adopt a distributed microservice framework, combining Redis publish-subscribe channels and WebSocket full-duplex communication channels to achieve global message push under a distributed microservice multi-active multi-node environment. The system includes a client and a server. The server, after receiving a transaction request message sent by the client, can call at least one transaction service node according to a load balancing strategy to generate a transaction instruction. Then, it requests a confirmation message based on the transaction instruction and sends the confirmation message to the target service nodes of all subscribed channels via the Redis channel. The target service nodes then push the confirmation message to the client. The system can utilize a distributed microservice framework and simultaneously use Redis publish-subscribe channels and WebSocket full-duplex communication technology to achieve real-time feedback of investment transaction-related order and transaction result information. This method can effectively reduce network overhead, accelerate response speed, and improve the real-time performance of investment transaction information push.

[0098] It should be noted that other corresponding descriptions of the functional units involved in the full-duplex distributed investment transaction information push system provided in this application embodiment can be found in the corresponding descriptions in the full-duplex distributed investment transaction information push method provided in the above embodiments, and will not be repeated here.

[0099] This application also provides a computer device, specifically a personal computer, server, network device, etc. The computer device includes a bus, processor, memory, and communication interface, and may also include input / output interfaces and a display device. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores location information. The network interface of the computer device is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps in the various method embodiments.

[0100] Those skilled in the art will understand that the structure of the computer device described above is only a partial structure related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. A specific computer device may include more or fewer components, or combine certain components, or have different component arrangements.

[0101] In one embodiment, a computer-readable storage medium is also provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0102] In one embodiment, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0103] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0104] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods.

[0105] Any references to memory, database, or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc.

[0106] Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can take many forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0107] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchain. The processors involved in the embodiments provided in this application may be, but are not limited to, general-purpose processors, graphics processors, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc.

[0108] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0109] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.< / sessionid> < / sessionid> < / sessionid>

Claims

1. A full-duplex distributed investment transaction information push method, characterized in that, The method is applied to a server, which establishes a communication connection with a client; the server includes a transaction gateway and multiple transaction service nodes based on a distributed microservice framework; the method includes: Obtain the transaction request message sent by the client, the transaction request message including the instruction elements filled in when placing the order and the transaction strategy; the instruction elements include the authorized user ID; In response to the transaction request message, at least one transaction service node is invoked according to the load balancing strategy to generate a transaction instruction, the transaction instruction including an instruction ID; The transaction instruction request confirmation message is a message data returned by the trading institution in response to the transaction instruction. The delegation confirmation message is sent to all target service nodes of the subscribed channels via a Redis channel. The target service node is the transaction service node that contains the binding mapping between user ID and session ID. The delegation confirmation message is pushed to the client through the target service node.

2. The method according to claim 1, characterized in that, The method further includes: Obtain the connection request message sent by the client, which is used to establish a Websocket connection between the transaction service node and the client; Extract authorization information from the request header of the connection request message. The authorization information includes the user ID and the role permissions corresponding to the user ID. By invoking the authentication and authorization service, permission verification is performed on the current client based on the authorization information. Upon successful permission verification, at least one transaction service node is invoked according to the load balancing strategy. A websocket connection is established between the transaction service node and the client based on the handshake protocol.

3. The method according to claim 2, characterized in that, The process of establishing a WebSocket connection between the transaction service node and the client based on the handshake protocol also includes: Extract the user ID from the authorization information; A session instance is allocated for the websocket connection, and the session instance is set with a session ID; A session binding mapping is established based on the user ID and the session ID. The session binding mapping includes a binding mapping between the session ID and the session instance, and a binding mapping between the user ID and the session ID. The session binding mapping is stored in the transaction service node.

4. The method according to claim 3, characterized in that, The method further includes: A heartbeat strategy is set for the websocket connection, and the heartbeat strategy is used to maintain a long connection between the client and the transaction service node through heartbeat signals; Monitor session instance status based on the aforementioned heartbeat strategy; When the session instance is in an invalid state, the session binding mapping is cleared; the invalid state is the instance state triggered when the client actively closes the session instance or when the authentication and authorization of the session instance expires.

5. The method according to claim 1, characterized in that, The transaction instruction request confirmation message includes: The trading instruction is split into several trading orders according to the trading strategy; The transaction order is sent to the relevant transaction interface of the trading institution through the transaction gateway; The transaction gateway receives the order confirmation message. Based on the instruction ID and the delegation confirmation message, add a binding mapping between the user ID and the instruction ID.

6. The method according to claim 1, characterized in that, The method further includes: A client list is constructed based on the transaction instruction and the order confirmation message; the client list includes transaction element information of the transaction instruction; the transaction element information includes at least one of order progress, transaction progress, and average transaction price; The transaction gateway receives transaction flow information, which is the flow information issued by the transaction institution in response to the transaction instruction. Perform logical calculations on the transaction information to update the transaction element information; Modify the element fields in the client list based on the updated transaction element information.

7. The method according to claim 1, characterized in that, The method further includes: The final state event of the monitoring connection status is an event triggered when the instruction is issued abnormally or the strategy algorithm stops; Generate a final state message based on the final state form event; The final state message is sent to the target service nodes of all subscribed channels via a Redis channel; The final state message is pushed to the client through the target service node, and the binding mapping between user ID and command ID is cleared.

8. The method according to claim 1, characterized in that, The method further includes: Obtain the subscription message sent by the client, wherein the subscription message includes the specified security code; According to the load balancing strategy, at least one transaction service node is invoked to add a binding mapping between session ID and security code; By subscribing to the message queue topic subscription of the aforementioned stock code through the market information service, relevant stock market information can be obtained; The relevant market data is sent to all subscription service nodes that subscribe to the Redis channel via a Redis channel; the subscription service node is a trading service node that contains a binding mapping between session ID and security code. The market information is sent to the client via a WebSocket connection.

9. The method according to claim 1, characterized in that, The method further includes: Retrieve the market data subscription messages specified by the client; According to the load balancing strategy, call at least one transaction service node to add the market data list corresponding to the session ID; Call the full market information interface of the market information service to return full market information through message queue topic subscription; The market data list is updated based on the full market data, and the newly added market data list is sent to all transaction service nodes of the subscribed channels through the Redis channel; If the market data list corresponding to the session ID in the transaction service node is not empty, the newly added market data list will be sent to the client.

10. A full-duplex distributed investment transaction information push system, characterized in that, The system includes a client and a server, and the server establishes a communication connection with the client; the server includes a transaction gateway and multiple transaction service nodes based on a distributed microservice framework; The client is configured to send a transaction request message to the server, the transaction request message including the instruction elements filled in when placing the order and the transaction strategy; the instruction elements include the authorized user ID; The server is configured as follows: Obtain the transaction request message sent by the client; In response to the transaction request message, at least one transaction service node is invoked according to the load balancing strategy to generate a transaction instruction, the transaction instruction including an instruction ID; The transaction instruction request confirmation message is a message data returned by the trading institution in response to the transaction instruction. The delegation confirmation message is sent to all target service nodes of the subscribed channels via a Redis channel. The target service node is the transaction service node that contains the binding mapping between user ID and session ID. The delegation confirmation message is pushed to the client through the target service node.

Images