Method, device and equipment for managing market information data and readable storage medium

Abstract

The invention discloses a method, device and equipment for managing market information data and a readable storage medium, and the method comprises the steps: obtaining the market information data from a preset data source through a main server in a service cluster, and storing the market information data in a local cache of the main server; transferring the market information data in the local cache of the main server to a Redis cache; respectively acquiring the market information data from the Redis cache through each slave server in the service cluster, and respectively storing the market information data into a local cache of each slave server; receiving a query request sent by a client, obtaining target market data corresponding to the query request from a local cache of a target slave server, and sending the target market data to the client; according to the invention, market information data can be provided for users efficiently and accurately.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and particularly relates to a method, device, equipment and readable storage medium for managing market data. Background Art

[0002] The world is changing rapidly, and the market conditions in the financial market are also changing rapidly; for brokerage platforms, being able to obtain market data in a timely and accurate manner is the cornerstone of all functions; for example, trading and risk control business functions rely on real-time market data, report and clearing and settlement business functions rely on historical market data, and real-time exchange rate data is even an indispensable existence for deposit and withdrawal and foreign exchange exchange business; therefore, a stable brokerage market structure can provide real-time and accurate market data to meet the needs of all parties and escort various business functions within the brokerage platform.

[0003] However, in recent years, with the sudden increase in market trading volume, the volume of market service requests has also been increasing continuously, and brokerage platforms are facing great pressure, and there are often situations where market service requests time out, resulting in the inability to provide reliable market data to users in a timely manner. Therefore, in order to provide more stable brokerage market data, it is necessary to upgrade the brokerage market structure to solve the technical problem of how to provide real-time market data to users efficiently and accurately. Summary of the Invention

[0004] The purpose of the present invention is to provide a method, device, equipment and readable storage medium for managing market data, which can provide market data to users efficiently and accurately.

[0005] According to one aspect of the present invention, there is provided a method for managing market data, which is applied to a service cluster, and the method includes:

[0006] Obtain market data from a preset data source through a main server in the service cluster, and store the market data in the local cache of the main server;

[0007] Transfer the market data in the local cache of the main server to a Redis cache;

[0008] Obtain the market data from the Redis cache through each slave server in the service cluster, and store the market data in the local cache of each slave server respectively;

[0009] Receive a query request sent by a client, obtain target market data corresponding to the query request from the local cache of the target slave server, and send the target market data to the client.

[0010] Optionally, transferring the market data in the local cache of the master server to the Redis cache specifically includes:

[0011] Compressing the market data in the local cache of the master server using Thrift serialization with the TCompactProtocol protocol;

[0012] Storing the compressed market data in the Redis cache and updating the version number of the Redis cache.

[0013] Optionally, each slave server in the service cluster separately obtains the market data from the Redis cache and stores the market data in the local cache of each slave server specifically includes:

[0014] Judging whether the version number of the Redis cache is updated. If so, obtaining the compressed market data from the Redis cache;

[0015] Decompressing the compressed market data and storing the decompressed market data in the local cache of the slave server.

[0016] Optionally, after each slave server in the service cluster separately obtains the market data from the Redis cache and stores the market data in the local cache of each slave server, the method further includes:

[0017] Regularly transferring the market data in the local cache of the slave server to the MySQL database at a set time interval.

[0018] Optionally, receiving a query request sent by a client, obtaining target market data corresponding to the query request from the local cache of the target slave server, and sending the target market data to the client specifically includes:

[0019] Judging whether there is target market data corresponding to the query request in the local cache of the target slave server;

[0020] If so, obtaining the target market data from the local cache of the target slave server;

[0021] If not, obtaining the target market data from the MySQL database and storing the target market data in the local cache of each slave server.

[0022] Optionally, the method further includes:

[0023] Statistical query frequency of the client querying market data of various underlying assets;

[0024] Set the target with a query frequency greater than the preset value as a high-frequency market target, and set the target with a query frequency less than the preset value as a low-frequency market target.

[0025] Optionally, obtaining market data from a preset data source by a primary server in the service cluster specifically includes:

[0026] Obtain the market data of the high-frequency market target from the preset data source by the primary server at a first acquisition frequency, and obtain the market data of the low-frequency market target from the preset data source at a second acquisition frequency;

[0027] Wherein, the first acquisition frequency is higher than the second acquisition frequency.

[0028] To achieve the above object, the present invention also provides a device for managing market data, which is applied to a service cluster. The device includes:

[0029] A first acquisition module, configured to obtain market data from a preset data source by a primary server in the service cluster, and store the market data in the local cache of the primary server;

[0030] A transfer module, configured to transfer the market data in the local cache of the primary server to a Redis cache;

[0031] A second acquisition module, configured to obtain the market data from the Redis cache by each slave server in the service cluster respectively, and store the market data in the local cache of each slave server respectively;

[0032] A query module, configured to receive a query request sent by a client, obtain target market data corresponding to the query request from the local cache of a target slave server, and send the target market data to the client.

[0033] To achieve the above object, the present invention also provides a computer device, which specifically includes: a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the steps of the method for managing market data introduced above are implemented.

[0034] To achieve the above object, the present invention also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method for managing market data introduced above are implemented.

[0035] The method, device, equipment and readable storage medium for managing market data provided by the present invention can effectively improve the market service ability of the brokerage platform. It can not only improve the response speed of market service requests to return the required market data to users faster, but also expand the market service ability to support a higher volume of market service requests by adding slave servers, so as to ensure that the brokerage market architecture can provide services continuously, stably and efficiently. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] By reading the following detailed description of the preferred embodiments, various other advantages and benefits will become clear to those of ordinary skill in the art. The drawings are only for the purpose of showing the preferred embodiments and are not considered as limiting the present invention. Moreover, throughout the drawings, the same reference numerals are used to represent the same components. In the drawings:

[0037] Figure 1 It is an optional flowchart of the method for managing market data provided in Embodiment 1;

[0038] Figure 2 It is an optional structural schematic diagram of the device for managing market data provided in Embodiment 2;

[0039] Figure 3 It is an optional hardware architecture schematic diagram of the computer equipment provided in Embodiment 3. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0040] In order to make the purpose, technical solution and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0041] Embodiment 1

[0042] The embodiment of the present invention provides a method for managing market data, which is applied to a service cluster. The service cluster includes: a main server and multiple slave servers. As Figure 1 shown, the method specifically includes the following steps:

[0043] Step S101: Obtain market data from a preset data source through a main server in the service cluster and store the market data in the local cache of the main server.

[0044] Specifically, the obtaining market data from a preset data source through a main server in the service cluster includes:

[0045] The master server regularly obtains market data from the preset data source at a first set time interval.

[0046] Preferably, the first set time interval is 500 ms; the ScheduledExecutorService thread pool scheduling method is adopted to regularly obtain real-time market data.

[0047] Preferably, the market data includes: real-time trading data, historical trading data, real-time exchange rate data, and historical exchange rate data.

[0048] In this embodiment, real-time trading data for multiple markets and multiple underlying assets can be provided; among them, the real-time trading data at least includes one of the following: pre-market price, after-hours price, bid-ask price, latest transaction price, current trading volume, price after corporate action; daily K-line data for multiple markets and multiple underlying assets can also be provided, among which the historical trading data at least includes one of the following: opening price, closing price, highest price, lowest price, trading volume, support for forward adjustment and non-adjusted query. Among them, multiple markets and multiple underlying assets at least include one of the following: support for stocks in the Chinese, US, New Zealand, Singapore, and Australian markets, support for US stock and Hong Kong stock options, support for US stock warrants, Hong Kong stock warrants and bull-bear certificates, support for Hong Kong stock dark pools, support for futures in the US and Singapore markets, support for funds and digital currencies. In addition, this embodiment also provides real-time exchange rate data and historical exchange rate data corresponding to multiple currencies.

[0049] In this embodiment, a server is selected from the service cluster as the master server according to a preset rule, and the other servers in the service cluster are used as slave servers; the master server is responsible for regularly obtaining market data from the data source and storing the obtained market data in the local cache. In addition, when the master server fails, a new master server is re-selected from each of the slave services in the service cluster according to the preset rule, so as to avoid the failure to obtain market data in a timely manner.

[0050] Step S102: Transfer the market data in the local cache of the master server to the Redis cache.

[0051] In this embodiment, the non-relational in-memory database Redis is used to cache market data, and together with the local cache of the server and the MySQL database mentioned later, it constitutes a multi-level storage architecture; the efficient access capability provided by the Redis cache for stored data greatly reduces the average response time of hot interfaces and greatly improves the throughput of the entire system.

[0052] Specifically, step S102 includes:

[0053] Compress the market data in the local cache of the master server using Thrift serialization with the TCompactProtocol protocol;

[0054] Store the compressed market data in the Redis cache and update the version number of the Redis cache.

[0055] In this embodiment, in order to save server bandwidth, the market data needs to be compressed and then transferred to the Redis cache for storage.

[0056] In this embodiment, a version number is set for the Redis cache. Whenever new market data is stored in the Redis server, the version number is incremented by 1 for update.

[0057] Step S103: Each slave server in the service cluster respectively obtains the market data from the Redis cache and stores the market data in the local cache of each slave server.

[0058] Specifically, step S103 includes:

[0059] The slave server regularly obtains the market data from the Redis cache at a second set time interval and stores the market data in the local cache of the slave server; wherein, the first set time interval and the second set time interval may be the same or different.

[0060] In this embodiment, the Redis cache is used to decouple the master server and the slave servers. Without using the Redis cache, the master server not only needs to regularly obtain data from the data source but also needs to regularly send the obtained data to each slave server, thus bringing a great processing pressure to the master server. In this embodiment, by using the Redis cache, the market data obtained by the master server can be cached in the Redis first, and then the Redis distributes the market data to each slave server, thereby reducing the processing pressure on the master server.

[0061] Further, step S103 specifically includes:

[0062] Step A1: The slave server determines whether the version number of the Redis cache is updated. If so, it obtains the compressed market data from the Redis cache;

[0063] Step A2: The slave server decompresses the compressed market data and stores the decompressed market data in the local cache of the slave server.

[0064] In this embodiment, the slave server determines whether to update the local cache data by the version number cached in Redis, avoiding the bandwidth waste caused by meaningless pulling of the Redis cache.

[0065] It should also be noted that the market data stored in each slave server in the service cluster is consistent.

[0066] Furthermore, after step S103, the method further includes:

[0067] At regular intervals of the third set time, the market data in the local cache of the slave server is periodically transferred to the MySQL database.

[0068] Preferably, the third set time interval is 24 hours, that is, at the end of each day, the market data in the local cache of a slave server in the service cluster is persistently stored in the MySQL database. That is, the market data of the current day is stored by the slave server, and the historical market data is stored by the MySQL database.

[0069] Step S104: Receive the query request sent by the client, obtain the target market data corresponding to the query request from the local cache of the target slave server, and send the target market data to the client.

[0070] In this embodiment, when the client initiates a market data query request, first, according to the occupancy rate of each slave server in the service cluster, the slave server with the lowest occupancy rate is set as the target slave server, and the query request is sent to the target slave server to query the target market data corresponding to the query request from the target slave server.

[0071] Specifically, step S104 includes:

[0072] Determine whether there is target market data corresponding to the query request in the local cache of the target slave server;

[0073] If so, obtain the target market data from the local cache of the target slave server;

[0074] If not, obtain the target market data from the MySQL database and store the target market data in the local cache of each slave server.

[0075] In this embodiment, since only the market data of the current day is stored in the slave server and historical market data is not stored, it is necessary to first determine whether the target market data corresponding to the query request exists in the target slave server. If it exists, it is directly returned; if not, the target market data corresponding to the query request is obtained from the MySQL database. Additionally, to prevent the client from obtaining the target market data stored in the MySQL database again, the target market data can be stored in the local cache of the target slave server, or stored in the local caches of all slave servers. In this embodiment, a multi-level cache architecture of local cache + Redis cache + MySQL database is adopted to ensure the access speed of market data. Additionally, in practical applications, when the target market data corresponding to the query request does not exist in the local cache of the target slave server, the target market data can also be obtained from the data source and stored in the local caches of each slave server.

[0076] Furthermore, the method further includes:

[0077] When the acquisition failure message or the target market data sent by the target slave server cannot be received within a set time period, a new target slave server is selected from the service cluster according to a preset rule, and the query request is sent to the new target slave server.

[0078] In this embodiment, when the target slave server has a problem, it can be quickly switched to a new target slave server to reprocess the query request of the client, thus ensuring high availability.

[0079] In this embodiment, the query requests of the client are processed by multiple slave servers. When the number of query requests surges, additional slave servers can be added to the service cluster for dynamic expansion, thereby improving the query request processing ability of the service cluster. When a new slave server is added to the service cluster, the identity identification information and / or address information of the new slave server are sent to the master server, and the market data already stored in other slave servers is synchronized to the local cache of the new slave server.

[0080] In addition, the method further includes:

[0081] Step B1: Statistically analyze the query frequency of the client querying the market data of various underlying assets;

[0082] Step B2: Set the underlying assets with a query frequency greater than the preset value as high-frequency market underlying assets, and set the underlying assets with a query frequency less than the preset value as low-frequency market underlying assets.

[0083] In this embodiment, according to the historical query situation of the client, the query frequencies of various market quotation targets are regularly counted at set time intervals to determine high-frequency market quotation targets and low-frequency market quotation targets. Among them, high-frequency market quotation targets are targets that users need to query frequently, and low-frequency market quotation targets are targets that users do not query frequently.

[0084] At this time, the obtaining of market quotation data from the preset data source by one master server in the service cluster in step S101 specifically includes:

[0085] Obtaining the market quotation data of the high-frequency market quotation targets from the preset data source by the master server at a first obtaining frequency, and obtaining the market quotation data of the low-frequency market quotation targets from the preset data source at a second obtaining frequency;

[0086] Among them, the first obtaining frequency is higher than the second obtaining frequency; preferably, the second obtaining frequency is a multiple of the first obtaining frequency.

[0087] In this embodiment, in order to utilize the master server more reasonably, the master server will obtain the market quotation data of high-frequency market quotation targets from the preset data source more frequently to meet the query requirements of the client in a timely manner; for low-frequency market quotation targets, the master server will not obtain them very frequently. In addition, in step S102, the market quotation data in the local cache of the master server is regularly transferred to the Redis cache at the first obtaining frequency; in step S103, each slave server in the service cluster obtains the market quotation data from the Redis cache at the first obtaining frequency regularly and stores the market quotation data in the local cache of each slave server respectively, so as to ensure that each slave server can obtain the market quotation data of each high-frequency market quotation target in the first time.

[0088] Through this embodiment, the market quotation service ability of the brokerage platform can be effectively improved, which can not only improve the response speed of market quotation service requests to return the required market quotation data to users faster, but also expand the market quotation service ability to support a higher volume of market quotation service requests by adding slave servers, so as to ensure that the brokerage market quotation architecture can provide services continuously, stably and efficiently.

[0089] Embodiment 2

[0090] An embodiment of the present invention provides a device for managing market quotation data, which is applied to a service cluster, as Figure 2 shown. The device specifically includes the following components:

[0091] A first obtaining module 201, configured to obtain market quotation data from a preset data source through a master server in the service cluster and store the market quotation data in the local cache of the master server;

[0092] A transfer module 202 for transferring market data in the local cache of the master server to a Redis cache;

[0093] A second acquisition module 203 for respectively acquiring the market data from the Redis cache through each slave server in the service cluster, and storing the market data into the local caches of the respective slave servers;

[0094] A query module 204 for receiving a query request sent by a client, acquiring target market data corresponding to the query request from the local cache of a target slave server, and sending the target market data to the client.

[0095] Specifically, the transfer module 202 is configured to:

[0096] Compress the market data in the local cache of the master server using Thrift serialization of the TCompactProtocol protocol;

[0097] Store the compressed market data into the Redis cache, and update the version number of the Redis cache.

[0098] At this time, the second acquisition module 203 is specifically configured to:

[0099] Determine whether the version number of the Redis cache is updated. If so, acquire the compressed market data from the Redis cache;

[0100] Decompress the compressed market data, and store the decompressed market data into the local cache of the slave server.

[0101] Furthermore, the device further includes:

[0102] A persistence module for periodically transferring market data in the local cache of the slave server to a MySQL database at set time intervals.

[0103] At this time, the query module 204 is specifically configured to:

[0104] Determine whether target market data corresponding to the query request exists in the local cache of the target slave server;

[0105] If so, acquire the target market data from the local cache of the target slave server;

[0106] If not, acquire the target market data from the MySQL database, and store the target market data into the local caches of each slave server.

[0107] Further, the device further includes:

[0108] A statistics module, configured to count the query frequency of the client for querying market data of various underlying assets; set the underlying assets with a query frequency greater than a preset value as high-frequency market underlying assets, and set the underlying assets with a query frequency less than the preset value as low-frequency market underlying assets.

[0109] At this time, the first acquisition module 201 is specifically configured to:

[0110] Obtain the market data of the high-frequency market underlying assets from the preset data source through the main server at a first acquisition frequency, and obtain the market data of the low-frequency market underlying assets from the preset data source at a second acquisition frequency; wherein, the first acquisition frequency is higher than the second acquisition frequency.

[0111] At this time, the second acquisition module 203 is specifically configured to:

[0112] The slave server obtains the market data from the Redis cache at the first acquisition frequency and stores the market data in the local cache of the slave server.

[0113] Through this embodiment, the market service ability of the brokerage platform can be effectively improved. It can not only improve the response speed of market service requests to return the required market data to users faster, but also expand the market service ability to support a higher volume of market service requests by adding slave servers, thereby ensuring that the brokerage market architecture can provide services continuously, stably, and efficiently.

[0114] Embodiment III

[0115] This embodiment also provides a computer device, such as a smart phone, a tablet computer, a notebook computer, a desktop computer, a rack server, a blade server, a tower server, or a cabinet server (including an independent server or a server cluster composed of multiple servers) that can execute programs. As Figure 3 shown, the computer device 30 of this embodiment at least includes, but is not limited to, a memory 301 and a processor 302 that can communicate with each other through a system bus. It should be noted that Figure 3 only the computer device 30 with components 301-302 is shown, but it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively.

[0116] In this embodiment, the memory 301 (i.e., the readable storage medium) includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory, etc.), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 301 may be an internal storage unit of the computer device 30, such as the hard disk or memory of the computer device 30. In other embodiments, the memory 301 may also be an external storage device of the computer device 30, such as a plug-in hard disk equipped on the computer device 30, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. Of course, the memory 301 may also include both the internal storage unit and the external storage device of the computer device 30. In this embodiment, the memory 301 is generally used to store the operating system and various application software installed on the computer device 30. In addition, the memory 301 may also be used to temporarily store various data that have been output or will be output.

[0117] In some embodiments, the processor 302 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other chips for managing market data. The processor 302 is generally used to control the overall operation of the computer device 30.

[0118] Specifically, in this embodiment, the processor 302 is used to execute the program of the method for managing market data stored in the memory 301. When the program of the method for managing market data is executed, the following steps are implemented:

[0119] Obtain market data from a preset data source through a primary server in the service cluster, and store the market data in the local cache of the primary server;

[0120] Transfer the market data in the local cache of the primary server to the Redis cache;

[0121] Respectively obtain the market data from the Redis cache through each slave server in the service cluster, and store the market data in the local cache of each slave server;

[0122] Receive a query request sent by the client, obtain target market data corresponding to the query request from the local cache of the target slave server, and send the target market data to the client.

[0123] For the specific implementation process of the above method steps, refer to Embodiment 1, which will not be repeated here.

[0124] Embodiment 4

[0125] This embodiment also provides a computer-readable storage medium, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory, etc.), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disc, server, App application store, etc., on which a computer program is stored. When the computer program is executed by a processor, the following method steps are implemented:

[0126] Obtain market data from a preset data source through a primary server in the service cluster, and store the market data in the local cache of the primary server;

[0127] Transfer the market data in the local cache of the primary server to the Redis cache;

[0128] Obtain the market data from the Redis cache through each secondary server in the service cluster, and store the market data in the local cache of each secondary server respectively;

[0129] Receive a query request sent by a client, obtain target market data corresponding to the query request from the local cache of the target secondary server, and send the target market data to the client.

[0130] For the specific implementation process of the above method steps, refer to Embodiment 1, which will not be repeated here.

[0131] It should be noted that in this article, the term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, article or device including the element.

[0132] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages and disadvantages of the embodiments.

[0133] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-described embodiment methods can be implemented by means of software plus a necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases, the former is a better implementation method.

[0134] The above are only the preferred embodiments of the present invention, and do not limit the patent scope of the present invention accordingly. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present invention, or directly or indirectly applied to other related technical fields, shall be equally included in the patent protection scope of the present invention.

Claims

1. A method for managing market data, characterized in that, Applied to a service cluster, the method includes: Obtain market data from a preset data source through a primary server in the service cluster, and store the market data in the local cache of the primary server; Transfer the market data in the local cache of the primary server to a Redis cache; Obtain the market data from the Redis cache through each slave server in the service cluster respectively, and store the market data in the local cache of each slave server respectively; Receive a query request sent by a client, obtain target market data corresponding to the query request from the local cache of the target slave server, and send the target market data to the client.

2. The method for managing market data according to claim 1, wherein The transferring the market data in the local cache of the primary server to a Redis cache specifically includes: Compress the market data in the local cache of the primary server using Thrift serialization of the TCompactProtocol protocol; Store the compressed market data in the Redis cache, and update the version number of the Redis cache.

3. The method for managing market data according to claim 2, wherein The obtaining the market data from the Redis cache through each slave server in the service cluster respectively, and storing the market data in the local cache of each slave server respectively specifically includes: Judge whether the version number of the Redis cache is updated. If so, obtain the compressed market data from the Redis cache; Decompress the compressed market data, and store the decompressed market data in the local cache of the slave server.

4. The method for managing market data according to claim 1, characterized in that, After the obtaining the market data from the Redis cache through each slave server in the service cluster respectively, and storing the market data in the local cache of each slave server respectively, the method further includes: Regularly transfer the market data in the local cache of the slave server to a MySQL database at a set time interval.

5. The method for managing market data according to claim 4, wherein The receiving a query request sent by a client, obtaining target market data corresponding to the query request from the local cache of the target slave server, and sending the target market data to the client specifically includes: Judge whether there is target market data corresponding to the query request in the local cache of the target slave server; If so, obtain the target market data from the local cache of the target slave server; If not, obtain the target market data from the MySQL database, and store the target market data in the local cache of each slave server.

6. The method for managing market data according to claim 1, wherein The method further includes: Statistical query frequency of the client to query market data of various underlying assets; Set the underlying assets with a query frequency greater than a preset value as high-frequency market underlying assets, and set the underlying assets with a query frequency less than the preset value as low-frequency market underlying assets.

7. The method for managing market data according to claim 6, wherein The obtaining market data from a preset data source through a primary server in the service cluster specifically includes: The master server obtains the market data of the high-frequency market targets from the preset data source at a first acquisition frequency, and obtains the market data of the low-frequency market targets from the preset data source at a second acquisition frequency; Wherein, the first acquisition frequency is higher than the second acquisition frequency.

8. An apparatus for managing market data, characterized in that Applied to a service cluster, the device includes: A first acquisition module, configured to obtain market data from a preset data source through a master server in the service cluster, and store the market data in the local cache of the master server; A transfer storage module, configured to transfer and store the market data in the local cache of the master server to a Redis cache; A second acquisition module, configured to obtain the market data from the Redis cache through each slave server in the service cluster, and store the market data in the local cache of each slave server respectively; A query module, configured to receive a query request sent by a client, obtain target market data corresponding to the query request from the local cache of a target slave server, and send the target market data to the client.

9. A computer device, the computer device comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the steps of the method according to any one of claims 1 to 7 when executing the computer program.

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

Images