CN114331445A - API (application programming interface), method, storage medium and electronic equipment for accessing massive users - Google Patents
API (application programming interface), method, storage medium and electronic equipment for accessing massive users Download PDFInfo
- Publication number
- CN114331445A CN114331445A CN202210249078.1A CN202210249078A CN114331445A CN 114331445 A CN114331445 A CN 114331445A CN 202210249078 A CN202210249078 A CN 202210249078A CN 114331445 A CN114331445 A CN 114331445A
- Authority
- CN
- China
- Prior art keywords
- api
- terminal
- api interface
- interface
- token
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
The method includes that a client registers a unique identifier of an API, multi-point login of a user is achieved, link management is conducted on a first terminal and a second terminal inside the API, data streams are persisted to a disk file through a persistence management module, the system can be quickly recovered when the system is recovered due to reasons, dynamic allocation of a memory according to user quantity is achieved through a memory management module, and the method has the advantages of being efficient, convenient, high in performance and the like while multi-point access of massive users is supported.
Description
Technical Field
The embodiment of the disclosure relates to the field of data processing, in particular to an API (application programming interface) interface, an API method, a storage medium and electronic equipment for accessing massive users.
Background
As distributed trading systems are upgraded and a large number of customers are gradually migrated from a centralized trading desk to the distributed trading systems, the distributed trading systems need to provide an interface or method for customer access. The existing transaction scene is that a teller generally carries out bill-making transaction through an over-the-counter client and a common client carries out bill-making transaction through a third-party terminal program. The current trading system can not well support the multi-point login of mass users, and the efficiency of query and trading operation of the mass users is not high.
Disclosure of Invention
The present disclosure aims to provide an API interface, a method, a storage medium, and an electronic device for accessing a large number of users, which support multi-point access of the large number of users and improve query and transaction operation efficiency.
According to an aspect of the present disclosure, an API interface for accessing a mass of users is provided, where the API interface is integrated in a first terminal, and the API interface includes:
the API interface starting module is used for starting the API, and the API provides a static interface to create an API example;
the link management module is used for linking the first terminal and the second terminal, the link management module supports configuration of IP addresses and ports of a plurality of second terminals, and when the second terminals need to be reconnected, the first terminal realizes reconnection of the second terminals in the API interface through the link management module;
the persistence management module is used for persisting the data stream to a disk file;
the memory management module is used for caching user service data and user information and dynamically allocating memory according to user quantity;
the business processing module comprises a login submodule and is used for realizing the login of a user;
the API interface adopts identity registration, and each third terminal using the API interface needs to apply for registering a unique identifier of the API interface.
In some embodiments, the first terminal is a transaction counter terminal or a terminal in a distributed transaction system, the second terminal is a front-end processor of an exchange transaction host, and the third terminal is a user client.
In some embodiments, the data streams include public streams, which refer to data streams common to all users, and private streams, which refer to data streams private to each client.
In some embodiments, each of the data streams has a number.
In some embodiments, the data is stored using an in-memory database.
In some embodiments, the login submodule supports a password-free login, which is specifically implemented by a login token manner, that is, a token is generated after a client logs in, wherein the token is generated by encrypting a core field in a login response message.
In some embodiments, the token ciphertext information includes a timestamp when the token is acquired, the API interface configures an effective time of the token, and when the token is used for verification, the token is invalid when the token exceeds the effective time.
In some embodiments, the same API interface identification supports only one terminal online.
In some embodiments, the service processing module further includes a query submodule, which can implement both API interface local query and background query.
In some embodiments, the business processing module further comprises a transaction sub-module for implementing an entrusted transaction for the user.
According to another aspect of the present disclosure, a method for accessing massive users by using the API interface is provided; the method comprises the following steps:
starting an API through the API starting module, wherein the API provides a static interface to create an API instance;
linking, by the link management module, the first terminal and the second terminal,
through the persistence management module, persisting the data stream to a disk file,
caching user service data and user information through the memory management module, and dynamically allocating a memory according to the user amount;
and logging in the system through the login submodule.
An embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored, where the computer program is suitable for being loaded by a processor to perform the steps in the method for accessing a large number of users according to any of the above embodiments.
An embodiment of the present application further provides an electronic device, where the electronic device includes a memory and a processor, where the memory stores a computer program, and the processor executes, by calling the computer program stored in the memory, the steps in the method for accessing mass users according to any of the above embodiments.
According to the API interface, the method, the computer readable storage medium and the electronic device for mass user access, the unique identification of the API is registered through the client, multi-point login of a user is achieved, the link of the first terminal and the second terminal is achieved inside the API interface through link management, the data stream is persisted to the disk file through the persistence management module, the system can be quickly recovered when the system is recovered due to reasons, the memory is dynamically allocated according to the user quantity through the memory management module, and the method, the computer readable storage medium and the electronic device for mass user access have the advantages of being efficient, convenient, high in performance and the like while supporting mass user multi-point access.
Drawings
The technical solutions and other advantages of the present disclosure will become apparent from the following detailed description of specific embodiments of the present disclosure, which is to be read in connection with the accompanying drawings.
Fig. 1 is a schematic diagram illustrating a position of an API interface in a transaction system according to an embodiment of the present application.
Fig. 2 is a schematic structural diagram of an API interface provided in an embodiment of the present application.
Fig. 3 is a schematic diagram of an API start timing sequence provided in the embodiment of the present application.
Fig. 4 is a schematic diagram of a disconnection reconnection timing sequence according to an embodiment of the present application.
Fig. 5 is a schematic diagram of a downtime recovery timing sequence provided in the embodiment of the present application.
Fig. 6 is a timing diagram for providing client login and token generation according to an embodiment of the present disclosure.
Fig. 7 is another schematic structural diagram of an API interface provided in the embodiment of the present application.
Fig. 8 is a schematic diagram of a data flow timing chart of a commission tentative calculation query according to an embodiment of the present application.
Fig. 9 is a schematic diagram of a local fund query timing sequence according to an embodiment of the present application.
Fig. 10 is a schematic diagram of a delegation transaction timing sequence according to an embodiment of the present application.
Fig. 11 is a flowchart illustrating a method for accessing massive users according to an embodiment of the present application.
Fig. 12 is a flowchart illustrating another method for accessing massive users according to an embodiment of the present application.
Fig. 13 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
The technical solution in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings. The terms "including" and "having," and any variations thereof, in the description and claims of this disclosure and the drawings are intended to cover non-exclusive inclusions. In the description of the present disclosure, "a plurality" means two or more unless specifically limited otherwise.
An API interface, a method, a storage medium, and an electronic device for accessing massive users provided in the embodiments of the present application will be described in detail below. The numbers in the following examples are not intended to limit the order of preference of the examples.
The first embodiment is as follows:
in order to adapt to the existing transaction scenario, the present disclosure implements a set of application programming interfaces (API for short) supporting single-client or multi-client login transactions, where the API is provided to an application developer in the form of a dynamic library, and the application developer uses the API library to complete the integrated development of the over-the-counter client or transaction gateway. The API library supports multi-point login of the same client and unified access of different clients, so that an application scene of single-client login transaction of an over-the-counter client is well supported, and an application scene of massive client login transaction of a transaction gateway is effectively supported.
Specifically, please refer to fig. 2, which is an API interface for accessing massive users according to an embodiment of the present disclosure, where the API interface is integrated in a first terminal, and the API interface includes:
an API starting module 101, wherein the API provides a static interface to create an API example;
and completing the calling of a transaction and query interface through an API example, wherein the example creation interface is as follows:
static KSFTSTraderAPI* CreateTraderAPI(const char* config_path = "config.ini");
a static interface for instance destruction is also provided:
static void DestroyTraderAPI(KSFTSTraderAPI*& api);
the API provides a starting interface, registers the SPI instance through the interface and starts the API working thread, and the interface is:
virtual APIResult ConnectServer(KSFTSTraderSPI* pSpi) = 0;
after the API is started, the API enters preparation work, and after the API is ready, an OnConnected callback interface is called to inform the integrated terminal that the API is ready, so that a client can enter a login transaction process. The above detailed timing diagram is shown in fig. 3.
After the API is started, all public stream data before starting are stored in the memory, and are persisted to a disk file.
And the link management module 102 is configured to link the first terminal and the second terminal, the link management module supports configuration of IP addresses and ports of the plurality of second terminals, and when the second terminals need to be reconnected, the first terminal realizes reconnection of the second terminals in the API interface through the link management module.
In one embodiment, the API interface is a CTP (comprehensive Transaction platform) like interface, and the CTP is a futures Transaction platform, which is a stable, high-speed, open interface suitable for application of program Transaction software.
In one embodiment, the API interface is located in the trading system as shown in FIG. 1.
The first terminal is suitable for WIN32, WIN64 and LINUX platforms, can be integrated to run in Windows environment or Linux environment, and in one embodiment, the first terminal can be a centralized transaction counter terminal in a futures transaction system or a terminal in a distributed transaction system, such as a counter client or a transaction gateway; and the user logs in the first terminal by using the client to realize the exchange of futures.
In one embodiment, the second terminal may be a front-end processor of the exchange host, the counter client or the exchange gateway needs to communicate with the exchange host through the front-end processor, in order to relieve the pressure of the exchange host, the number of the front-end processors is usually multiple, and the transaction speed and efficiency are improved through the load balancing of the multiple front-end processors.
In one embodiment, the link management module supports configuration of IP addresses and ports of a plurality of front-end computers, when network jitter occurs or a connected front-end computer is down, the API automatically initiates reconnection to the original front-end computer, if reconnection is not successful, reconnection is initiated to a standby front-end computer one by one until reconnection is successful, a terminal of the integrated API does not need to care about a reconnection mechanism, the whole reconnection process is completed inside the API, and a disconnection signal and a reconnection success signal of the API are notified to the integrated terminal through a callback interface.
The link management module supports disconnection reconnection and automatic switching of the main and standby front-end computers, and has the key points that disconnection reconnection is completed in an API (application programming interface), disconnection is completed through virtual void on disconnected (Reconnected status, ErrorInfoFieldpErrorinfo), a callback interface is notified to a terminal of the integrated API, the terminal program does not need to destroy an API instance, and the terminal program of the integrated API is notified again through the virtual void on connected callback () interface after reconnection is successful. The timing chart of the specific disconnection reconnection is shown in fig. 4.
When the network is abnormal or the front-end processor is down or the link is interrupted due to other reasons, the API link management thread firstly calls the OnDisconnected callback interface to inform the integrated terminal that the working thread is disconnected, at the moment, the API link management thread initiates reconnection to the front-end processor which is currently connected, and the reconnected front-end processor is updated according to the number of the front-end processor once the reconnection fails until the connection is successful.
A persistence management module 103, configured to persist the data stream to a disk file;
and the API interface adopts the technologies of data stream persistence, stream file inversion and cut-off renewal to ensure reliable recovery after the downtime is restarted.
In one embodiment, the data flow is divided into public and private flows, where a public flow refers to the flow data that is common to all users, such as: securities basic information, ETF basic information, error code information, etc., and private stream refers to stream data private to each client. For example: capital, position taking, entrustment detail, transaction detail and the like; in one embodiment, each data stream has a number, and each piece of data pushed by the background to the API includes a number, which is incremented and ordered. And the design of data stream classification classifies all data streams into public streams and private streams, so that the public data cannot be repeatedly pushed, the public data is reserved by the same API integrated terminal, and the private data is bound with a client.
The API realizes that the data stream is persisted to a disk file, after a terminal program integrating the API is down, an inversion mechanism of the API reloads the data stream in the persisted file into a memory and restores the data stream to a memory state before the down, for the data lost during the down period, the data stream of the API defines a stream sequence number, a data stream renewal can be initiated to the front-end processor through the stream sequence number of a breakpoint, and the front-end processor can push the data stream after the breakpoint to the API again.
In one embodiment, the restart and recovery after the downtime is realized by a method of replying a persistent file and data streams, wherein the persistent file stores all stream data received from a background, including public streams and private streams, and the inversion process is a process of loading the data in the file into a memory one by one, so that the state before the downtime is recovered. In the downtime recovery process, part of data streams in the background are not pushed to the API, the cut-off renewal is automatically initiated after the API is started, and the missing data is supplemented from the background.
In one embodiment, by redefining the subscription data structure, classification of data streams is achieved on the one hand, and the efficiency and speed of downtime recovery can be improved on the other hand.
The elements contained in the subscription data structure are defined as follows:
[ subscription topic, subscription Start number, subscription binding ID ]
Wherein the subscription theme values are respectively: 1-public flow, 2-private flow. The subscription starting sequence number is an unsigned integer value greater than or equal to 0. And when the stream is a public stream, the ID of the subscription binding is the unique identifier of the API, and when the stream is a private stream, the ID of the subscription binding is a specific client number.
The API locally stores the maximum sequence number of the local existing stream data, and the storage format is as follows:
[ APIID, latest public flow number ], where APIID is a key.
[ client number, session information, latest private stream sequence number ], where client number is a key.
The restart process after downtime is substantially similar to the flow of the API when the API is first started, and the difference is that a stream file exists locally in the downtime state, and an inversion flow of the stream file is triggered, and a specific downtime recovery flow is shown in fig. 5.
And the persistent data flow is transmitted to the disk file, so that incremental flow pulling is realized, and the load on the front-end processor caused by flow pulling from the front-end processor after the breakdown of the API integrated terminal is effectively reduced.
And the memory management module 104 is used for caching the user service data and the user information and dynamically allocating the memory according to the user amount.
After the API is started, all public stream data before starting are stored in the memory, and are persisted to a disk file. The size of the memory banks adopted by the API is dynamically allocated, the memory is dynamically allocated along with the increase of the number of clients, and as long as the hardware memory allows, a sufficient amount of client data can be cached.
In one embodiment, the data is stored in a memory database, which is a database with a memory as a main data storage mode. The API memory bank caches client funds, position taken, entrustment details, stock basic information and the like, and meanwhile, the API supports local query, so that part of query with higher frequency can be completed directly in the API without being sent to a background, and resource competition with transaction requests is reduced. The operation of partial query preposition is converted into API local query, thereby reducing the burden of the preposition machine and improving the query performance.
The service processing module 105 includes a login sub-module 501, which is used for realizing the login of the user;
the API interface adopts identity registration, and each third terminal using the API interface needs to apply for registering a unique identifier of the API interface.
In one embodiment, the API uses identity registration, and for each terminal using the API, a unique identifier of the API needs to be applied for registration, so that the same client can be distinguished by logging in through different API terminal devices. API unique identification: is a character string with a defined format, and is used as an identifier when the terminal program of the integrated API runs. And (3) API login: and taking the API unique identifier as an account number to carry out login authentication in a background, wherein the only authenticated API identifier is a legal API identifier.
In one embodiment, login control is realized by adopting a token login mode, namely a token is generated after a client logs in, and a subsequent client can pass validity verification by carrying a correct and effective token when initiating a transaction or query request.
In one embodiment, the token is generated by encrypting several core fields in the login response message and returning the encrypted ciphertext to the integrated terminal through the callback interface, and the time efficiency of the token is valid on the same day, that is, the token can be verified to pass only by carrying token in the calling of all transaction interfaces and part of query interfaces on the same day, and is invalid on the next day after logging out.
In one embodiment, the password-free login functions through a token, the ciphertext of the token contains the session information of the client, and the password-free login can initiate query or entrust as long as the client carries a correct and effective token. the token failure method includes two scenarios, one scenario is that when a client initiates a logout operation, an API clears session information of the client, the token fails, the token operation cannot be found and an error is reported when the token is continuously used, another token is out of date, token ciphertext information includes a timestamp when the token is acquired, an effective time of the token is configured in the API, and if the effective time is 12 hours, when the token is used for verification, whether the token exceeds the aging of 12 hours is checked, and if the token exceeds the aging, the token fails. And a token technology is introduced, so that the problem of secret-free transaction of a client is effectively solved.
In one embodiment, the client data is zero-coupled with all implementation methods in the API, that is, all implementation methods are not associated with any specific client data, so that multiple clients can log in through the same API without influencing each other.
The specific reason why the client can complete the multi-point login is that the unique identifier of the API is designed, each terminal program integrating the API is pre-distributed with one unique identifier of the API, the whole transaction system is unique and can not be reused, the same API identifier only supports one terminal to be on-line, and when multiple terminals are started by using the same API identifier, the later started terminals cannot be started successfully. Therefore, the client logs in the transaction system through the plurality of terminals, the transaction system can also recognize which terminal program the request of the client for logging, transaction, inquiry and the like comes from, and further accurate pushing of private data can be realized.
The key point of supporting different customer login transactions is that customer information is added to all interface parameters from a software design level, so that interface calling is delayed from the original binding of a single customer to a specific customer for calling an interface determined by a terminal program of an integrated API. Compared with the original design of binding a single client by the API, the embodiment effectively supports the login of different clients. A timing diagram for the generation of the client login and token is shown in figure 6.
Example two
The present embodiment is based on the improvement of the above embodiment, and the same parts as the above embodiment are not mentioned again in the present embodiment, as shown in fig. 7, the business processing module 105 further includes a query sub-module 502 for implementing a customer data query, specifically, the data query supports a back-end entrusted transaction query, and also supports a local query.
In one embodiment, the committed transaction query may be a committed trial calculation query, and a data flow sequence chart of the committed trial calculation query is shown in fig. 8.
In one embodiment, the local query may implement a customer's funding query, and the timing diagram is shown in FIG. 9.
All transaction query interface formats are defined as:
a request interface: APIResult KSFTSTRaderAPI: ReqXXX (ReqUser pUser, ReqXXXfield pReqXXX, RequestIDType reqId);
a response interface: void KSFTSTRaderSPI:OnRspXXX (RspUser pUser, RspXXXfield pRspXXX, ErrorInfofield pErrorInfo, RequestIDType reqId);
and (3) a query response interface: void KSFTSTRaderSPI:OnRspQryXXX (RspUser. pUser, RspXXXfield. pRspXXX, ErrorInfofield. pErrorInfo, RequestIDType reqId, boul isLast);
the memory database is used for facilitating the increase, deletion, modification and check of data, and classifying the data stream into public stream and private stream, so that data redundancy is avoided, and massive customer login transactions and query are realized without influencing transaction performance.
The business processing module 105 further includes a transaction sub-module 503 for implementing client's entrusted transaction, for example, a timing diagram of transaction data flow is shown in fig. 10.
Through the foregoing, it can be understood that the request interfaces of login, query, and transaction are all completed in the thread of the terminal program of the integrated API, and all the interfaces are thread-safe, thereby improving the flexibility of integrated terminal development, the integrated terminal can call the API interfaces in multiple threads, and the requests are not cached in the API, thereby reducing the complexity of processing the request data loss, and also reducing the performance problem caused by copying the request data.
Example three:
specifically, please refer to fig. 11, which is a flowchart illustrating a method for accessing massive users by using the API interface according to a third embodiment of the present disclosure. The method for accessing massive users comprises the following steps:
s1 starts API through the API start module, and the API provides a static interface to create API instance;
s2 linking the first terminal and the second terminal through the link management module,
s3 persists the data stream to a disk file through the persistence management module,
s4, caching user service data and user information through the memory management module, and dynamically allocating memory according to user quantity;
and S5 logging in the system through the login submodule.
In another embodiment, as shown in fig. 12, the method for accessing massive users by using the API interface further includes:
s6, using the query submodule to realize user data query;
s7 implements the delegated transaction of the user using the transaction submodule.
Example four
Correspondingly, the embodiment of the application also provides the electronic equipment, and the electronic equipment can be a terminal or a server. As shown in fig. 13, fig. 13 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
The electronic device 1300 includes a processor 1301 having one or more processing cores, a memory 1302 having one or more computer-readable storage media, and a computer program stored on the memory 1302 and executable on the processor. The processor 1301 is electrically connected to the memory 1302. Those skilled in the art will appreciate that the electronic device configurations shown in the figures do not constitute limitations of the electronic device, and may include more or fewer components than shown, or some components in combination, or a different arrangement of components.
The processor 1301 is a control center of the electronic apparatus 1300, connects various parts of the entire electronic apparatus 1300 using various interfaces and lines, and performs various functions of the electronic apparatus 1300 and processes data by running or loading a software program (computer program) and/or unit stored in the memory 1302 and calling data stored in the memory 1302, thereby performing overall monitoring of the electronic apparatus 1300.
In this embodiment of the application, the processor 1301 in the electronic device 1300 loads instructions corresponding to processes of one or more application programs into the memory 1302 according to the following steps, and the processor 1301 runs the application programs stored in the memory 1302, thereby implementing various functions:
starting an API through the API starting module, wherein the API provides a static interface to create an API instance;
linking the first terminal and the second terminal through the link management module,
through the persistence management module, persisting the data stream to a disk file,
caching user service data and user information through the memory management module, and dynamically allocating a memory according to the user amount;
and logging in the system through the login submodule.
The above operations can be implemented in the foregoing embodiments, and are not described in detail herein.
Optionally, as shown in fig. 13, the electronic device 1300 further includes: a user access module 1303, a communication module 1304, an input unit 1305, and a power supply 1306. The processor 1301 is electrically connected to the user access module 1303, the communication module 1304, the input unit 1305 and the power source 1306, respectively. Those skilled in the art will appreciate that the electronic device configuration shown in fig. 13 does not constitute a limitation of the electronic device and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.
The user access module 1303 may be used to implement user access.
The communication module 1304 may be used to communicate with other devices.
The input unit 1305 may be used to receive input numbers, character information, or user characteristic information (e.g., fingerprint, iris, face information, etc.), and generate a keyboard, mouse, joystick, optical, or trackball signal input related to user setting and function control.
The power supply 1306 is used to power the various components of the electronic device 1300. Optionally, the power source 1306 may be logically connected to the processor 1301 through a power management system, so that functions of managing charging, discharging, power consumption, and the like are realized through the power management system. The power supply 1306 may also include any component of one or more dc or ac power sources, recharging systems, power failure detection circuitry, power converters or inverters, power status indicators, and the like.
In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.
EXAMPLE five
It will be understood by those skilled in the art that all or part of the steps of the methods of the above embodiments may be performed by instructions or by associated hardware controlled by the instructions, which may be stored in a computer readable storage medium and loaded and executed by a processor.
To this end, embodiments of the present application provide a computer-readable storage medium, in which a plurality of computer programs are stored, where the computer programs can be loaded by a processor to execute the steps in any mass user access method provided in the embodiments of the present application. For example, the computer program may perform the steps of:
starting an API through the API starting module, wherein the API provides a static interface to create an API instance;
linking the first terminal and the second terminal through the link management module,
through the persistence management module, persisting the data stream to a disk file,
caching user service data and user information through the memory management module, and dynamically allocating a memory according to the user amount;
and logging in the system through the login submodule.
The above operations can be implemented in the foregoing embodiments, and are not described in detail herein.
Wherein the computer-readable storage medium may include: read Only Memory (ROM), Random Access Memory (RAM), magnetic or optical disks, and the like.
Since the computer program stored in the storage medium can execute the steps in any data migration method provided in the embodiments of the present application, beneficial effects that can be achieved by any data migration method provided in the embodiments of the present application can be achieved, and detailed descriptions are omitted herein for the foregoing embodiments.
The data migration method, the data migration apparatus, the computer-readable storage medium, and the electronic device provided in the embodiments of the present application are described in detail above, and a specific example is applied in the description to explain the principles and implementations of the present application, and the description of the embodiments is only used to help understand the method and the core concept of the present application; meanwhile, for those skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.
Claims (15)
1. An API interface for accessing by a mass of users, the API interface being integrated in a first terminal, the API interface comprising:
the API interface starting module is used for starting the API, and the API provides a static interface to create an API example;
the link management module is used for linking the first terminal and the second terminal, the link management module supports configuration of IP addresses and ports of a plurality of second terminals, and when the second terminals need to be reconnected, the first terminal realizes reconnection of the second terminals in the API interface through the link management module;
the persistence management module is used for persisting the data stream to a disk file;
the memory management module is used for caching user service data and user information and dynamically allocating memory according to user quantity;
the service processing module comprises a login submodule for realizing the login of the user;
the API interface adopts identity registration, and each third terminal using the API interface needs to apply for registering a unique identifier of the API interface.
2. An API interface as recited in claim 1, wherein the first terminal is a transaction counter terminal or a terminal in a distributed transaction system, the second terminal is a front-end processor of an exchange transaction host, and the third terminal is a user client.
3. The API interface of claim 1 wherein the data streams include a public stream and a private stream, the public stream being a data stream common to all users, and the private stream being a data stream private to each client.
4. An API interface as recited in claim 3, wherein each of the data streams has a number.
5. An API interface as recited in claim 1, wherein said data is stored using an in-memory database.
6. The API interface of claim 1, wherein the login submodule supports a secure login, and is implemented by a login token, that is, a token is generated after a client logs in, wherein the token is generated by encrypting a core field in a login response message.
7. The API interface of claim 6, wherein the token ciphertext information includes a timestamp when the token is acquired, an effective time of the token is configured in the API interface, and when the token is used for verification, the token is invalidated when the token exceeds the effective time.
8. An API interface as recited in claim 1, wherein the same API interface identifier supports only one terminal online.
9. The API interface of claim 1 wherein the service processing module further comprises a query submodule for performing both local and background queries of the API interface.
10. An API interface as recited in claim 1, wherein the transaction handler module further comprises a transaction submodule for implementing a delegated transaction for the user.
11. A method for accessing massive users by using the API interface of any one of claims 1 to 10, the method comprising:
starting an API through the API starting module, wherein the API provides a static interface to create an API instance;
linking, by the link management module, the first terminal and the second terminal,
through the persistence management module, persisting the data stream to a disk file,
caching user service data and user information through the memory management module, and dynamically allocating a memory according to the user amount;
and logging in the system through the login submodule.
12. The method of claim 11, wherein the relevant data is queried by a query module.
13. The method of claim 11, wherein the delegated transaction is implemented by a transaction module.
14. A computer-readable storage medium, characterized in that it stores a computer program adapted to be loaded by a processor for performing the steps of the method for mass user access according to any of claims 11-13.
15. An electronic device, characterized in that the electronic device comprises a memory and a processor, wherein the memory stores a computer program, and the processor executes the steps of the method for mass user access according to any one of claims 11-13 by calling the computer program stored in the memory.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210249078.1A CN114331445A (en) | 2022-03-15 | 2022-03-15 | API (application programming interface), method, storage medium and electronic equipment for accessing massive users |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210249078.1A CN114331445A (en) | 2022-03-15 | 2022-03-15 | API (application programming interface), method, storage medium and electronic equipment for accessing massive users |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114331445A true CN114331445A (en) | 2022-04-12 |
Family
ID=81033469
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210249078.1A Pending CN114331445A (en) | 2022-03-15 | 2022-03-15 | API (application programming interface), method, storage medium and electronic equipment for accessing massive users |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114331445A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114721845A (en) * | 2022-04-14 | 2022-07-08 | 广州有信科技有限公司 | Multi-tenant restful API interface management method and device |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102025648A (en) * | 2009-09-16 | 2011-04-20 | 腾讯科技（深圳）有限公司 | Instant messaging method and server |
| CN102368764A (en) * | 2011-09-10 | 2012-03-07 | 上海量明科技发展有限公司 | Method for carrying out communication through multiple points of presence, system and client thereof |
| CN105897603A (en) * | 2014-11-24 | 2016-08-24 | 泰瑞数创科技(北京)有限公司 | Mass multi-protocol internet of vehicles terminal access technology |
| CN108289063A (en) * | 2017-09-11 | 2018-07-17 | 上海金融期货信息技术有限公司 | A kind of low latency communication system |
| CN110415027A (en) * | 2019-07-16 | 2019-11-05 | 上海金融期货信息技术有限公司 | A kind of big data market plateform system |
| CN110708281A (en) * | 2019-08-26 | 2020-01-17 | 上海商米科技集团股份有限公司 | Service request processing method and device |
| CN112765119A (en) * | 2019-10-21 | 2021-05-07 | 深圳市茁壮网络股份有限公司 | HDFS API calling method, device, equipment and storage medium |
| CN113065963A (en) * | 2021-04-07 | 2021-07-02 | 上海金融期货信息技术有限公司 | Futures chairman trading system |
| CN113065953A (en) * | 2020-12-01 | 2021-07-02 | 上海金融期货信息技术有限公司 | Futures relay trading system based on distribution |
| CN113691378A (en) * | 2021-08-24 | 2021-11-23 | 平安国际智慧城市科技股份有限公司 | Oauth2 single sign-on method and device based on gateway, electronic equipment and storage medium |
| CN114139087A (en) * | 2021-11-29 | 2022-03-04 | 上海金仕达软件科技有限公司 | Transaction information subscription platform system |
-
2022
- 2022-03-15 CN CN202210249078.1A patent/CN114331445A/en active Pending
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102025648A (en) * | 2009-09-16 | 2011-04-20 | 腾讯科技（深圳）有限公司 | Instant messaging method and server |
| CN102368764A (en) * | 2011-09-10 | 2012-03-07 | 上海量明科技发展有限公司 | Method for carrying out communication through multiple points of presence, system and client thereof |
| CN105897603A (en) * | 2014-11-24 | 2016-08-24 | 泰瑞数创科技(北京)有限公司 | Mass multi-protocol internet of vehicles terminal access technology |
| CN108289063A (en) * | 2017-09-11 | 2018-07-17 | 上海金融期货信息技术有限公司 | A kind of low latency communication system |
| CN110415027A (en) * | 2019-07-16 | 2019-11-05 | 上海金融期货信息技术有限公司 | A kind of big data market plateform system |
| CN110708281A (en) * | 2019-08-26 | 2020-01-17 | 上海商米科技集团股份有限公司 | Service request processing method and device |
| CN112765119A (en) * | 2019-10-21 | 2021-05-07 | 深圳市茁壮网络股份有限公司 | HDFS API calling method, device, equipment and storage medium |
| CN113065953A (en) * | 2020-12-01 | 2021-07-02 | 上海金融期货信息技术有限公司 | Futures relay trading system based on distribution |
| CN113065963A (en) * | 2021-04-07 | 2021-07-02 | 上海金融期货信息技术有限公司 | Futures chairman trading system |
| CN113691378A (en) * | 2021-08-24 | 2021-11-23 | 平安国际智慧城市科技股份有限公司 | Oauth2 single sign-on method and device based on gateway, electronic equipment and storage medium |
| CN114139087A (en) * | 2021-11-29 | 2022-03-04 | 上海金仕达软件科技有限公司 | Transaction information subscription platform system |
Non-Patent Citations (8)
| Title |
|---|
| ALGOPLUS: ""CTP量化投资API手册(2)TraderApi初始化与登录"", 《HTTPS://7JIA.COM/70002.HTML》 * |
| K_K: ""如何保证外网开放接口的安全性"", 《HTTPS://WWW.CNBLOGS.COM/GOTOJAVA/P/13700905.HTML》 * |
| LINJIERD: ""基于Token认证的多点登录和WEBAPI保护"", 《HTTPS://DEVELOPER.ALIYUN.COM/ARTICLE/676409?SPM=A2C6H.14164896.0.0.56451B245CYOHA》 * |
| SHAYUNWYH: ""金仕达网关接口规范V11.1"", 《HTTPS://WWW.DOC88.COM/P-3847854043255.HTML?S=REL&ID=9》 * |
| 上海证券交易所: "《债券技术 创新与发展》", 30 June 2013, 上海人民出版社 * |
| 中国物流与采购联合会: "《中国物流与采购信息化优秀案例集 2011》", 31 August 2011, 中国物资出版社 * |
| 泡芙: ""ctp登录、报单回报与成交回报"", 《HTTPS://ZHUANLAN.ZHIHU.COM/P/266393852》 * |
| 黄禅宗: ""如何设计API接口，请求接口时需要进行身份验证，防止第三方随意调用接口？"", 《HTTPS://WWW.ZHIHU.COM/QUESTION/20634933》 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114721845A (en) * | 2022-04-14 | 2022-07-08 | 广州有信科技有限公司 | Multi-tenant restful API interface management method and device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9239868B2 (en) | Virtual session management and reestablishment | |
| US6868442B1 (en) | Methods and apparatus for processing administrative requests of a distributed network application executing in a clustered computing environment | |
| US7653679B2 (en) | Systems and methods for multi-stage message brokering | |
| US5889957A (en) | Method and apparatus for context sensitive pathsend | |
| US20160191662A1 (en) | Automatic data request recovery after session failure | |
| US7801997B2 (en) | Asynchronous interconnect protocol for a clustered DBMS | |
| US7502824B2 (en) | Database shutdown with session migration | |
| US10819641B2 (en) | Highly available servers | |
| CN108063813B (en) | Method and system for parallelizing password service network in cluster environment | |
| US10936591B2 (en) | Idempotent command execution | |
| US6038589A (en) | Apparatus, method and computer program product for client/server computing with a transaction representation located on each transactionally involved server | |
| CN111343262B (en) | Distributed cluster login method, device, equipment and storage medium | |
| US20230052935A1 (en) | Asynchronous accounting method and apparatus for blockchain, medium and electronic device | |
| CN114331445A (en) | API (application programming interface), method, storage medium and electronic equipment for accessing massive users | |
| KR20010024837A (en) | An apparatus, method and computer program product for client/server computing with intelligent location of transaction objects | |
| US6112315A (en) | Process and apparatus for reducing software failures using sparing in distributed systems | |
| CN115098528B (en) | Service processing method, device, electronic equipment and computer readable storage medium | |
| US20050132237A1 (en) | Method, apparatus and program storage device for providing a remote power reset at a remote server through a network connection | |
| CN114090338A (en) | Request processing method and device and electronic equipment | |
| US20050097555A1 (en) | Method, system and program product for processing a transaction | |
| CN112637201A (en) | Request processing method, device, equipment and system of web server | |
| CN112561650B (en) | Order service request processing system | |
| WO2003003244A1 (en) | Method of rapidly eliminating different information in databases | |
| CN112965763B (en) | Service processing system, method, device and storage medium | |
| CN115344366B (en) | Connection pool object switching method and device, electronic equipment and readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20220412 |