Method and apparatus for maintaining request status based on HTTP long connection pool

Abstract

The embodiment of the application provides a request state keeping method and device based on HTTP long connection pool, relates to the field of data transmission, and can also be applied to the financial field, the method comprises the following steps: adding a connection keeping parameter in the request header of an HTTP request of a client to establish a long connection with a server; storing the established long connection instance into a connection pool array, and setting a corresponding mutex lock for each long connection instance; setting a corresponding request ID for each type of request of the client, and recording the mapping relationship of the request ID to the long connection; in response to the number of request IDs mapped to the same long connection exceeding a preset threshold, a new long connection is established and stored into the connection pool array; the application can ensure that the real server connected by each request is the same, directly caches data in the memory of the real server, and reduces the overhead of network IO resources.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data transmission, and can also be applied to the field of finance, and in particular to a request state maintaining method and device based on HTTP long connection pool. BACKGROUND

[0002] In the existing interaction architecture of client and server, the request of the client is usually forwarded to the real server in the backend through the load balancing server. The above architecture allows the request of the client to be load balanced among multiple servers, thereby improving the processing efficiency and fault tolerance. However, when using HTTP short connection, the server needs to obtain and cache the relevant state information of the client (such as the login state of the user, historical operation data, etc.) every time the request is forwarded to a new server, in order to correctly process the request. If the information is not shared among servers, the client needs to provide it again every time the request is made, resulting in repeated data transmission.

[0003] In order to solve the above problem, the industry uses cache technology such as Redis to share the client state information among multiple servers. By using a central cache, each server can obtain the latest client state information from the cache without the client sending it every time.

[0004] However, the above method still faces the problem of high network IO resource consumption when processing a large amount of repeated data. When the cache data is large or in a high concurrency environment, each query and update of the cache can become a performance bottleneck.

[0005] In addition, network IO resources include network bandwidth required for data transmission and server IO capability for processing the data. Repeated transmission of a large amount of state information such as historical data and attribute information in each request will occupy a large amount of network bandwidth and increase the burden of the server for processing the information, not only slowing down the data processing speed, but also reducing the overall efficiency of the system and user experience. SUMMARY

[0006] In view of the problems in the prior art, the present application provides a request state maintaining method and device based on HTTP long connection pool, which can ensure that the real server for each request connection is the same, and directly cache data in the memory of the real server, thereby reducing the overhead of network IO resources.

[0007] In order to solve at least one of the above problems, the present application provides the following technical solutions:

[0008] According to a first aspect of an embodiment of the present application, the present application provides a request state maintaining method based on HTTP long connection pool, comprising:

[0009] Adding a connection maintaining parameter in a request header of an HTTP request to establish a long connection with a server;

[0010] Storing the established long connection instance into a connection pool array and setting a corresponding mutex lock for each long connection instance;

[0011] Setting a corresponding request ID for each type of request of the client and recording a mapping relationship between the request ID and the long connection;

[0012] In response to a number of request IDs mapped to the same long connection exceeding a preset threshold, establishing a new long connection and storing it into the connection pool array.

[0013] According to any one of the embodiments of the present application, further comprising:

[0014] In response to establishing the long connection for the first time, transmitting the request ID and state information to the server to enable the server to reuse the request ID and the state information until the long connection is disconnected.

[0015] According to any one of the embodiments of the present application, the transmitting the request ID and state information to the server comprises:

[0016] In response to the server establishing a long connection with the client, controlling the server to extract the request ID and the state information of the corresponding client;

[0017] Storing the request ID and the state information in the form of key-value pairs into the memory of the server, wherein the key is the request ID and the value is the state information.

[0018] According to any one of the embodiments of the present application, the storing the established long connection instance into a connection pool array and setting a corresponding mutex lock for each long connection instance comprises:

[0019] In response to the client establishing a long connection with the server, generating a long connection instance according to the long connection, the connection instance including a request ID, a connection state and a connection start time stamp of the long connection;

[0020] Adding the connection instance into a predefined array structure, the array structure serving as a connection pool for storing and managing all the long connection instances;

[0021] For each connection instance, setting an initialization mutex lock, the mutex lock being used for synchronization of access to the long connection instance.

[0022] According to any of the embodiments of the present application, after setting a corresponding request ID for each type of request of the client and recording the mapping relationship of the request ID to the long connection, the method further comprises:

[0023] In response to the long connection being established for the first time, a corresponding request ID is allocated to the current long connection according to the request type of the HTTP request initiated by the client;

[0024] The current long connection is quickly located to the corresponding connection instance according to the mapping relationship.

[0025] According to any of the embodiments of the present application, in response to the number of request IDs mapped to the same long connection exceeding a preset threshold, a new long connection is established and stored in the connection pool array, which comprises:

[0026] The number of request IDs mapped to each long connection instance is monitored in real time, and a new long connection instance is initialized in the case that the number of request IDs on a long connection instance exceeds a preset threshold;

[0027] The newly created long connection instance is added to the connection pool array to disperse the load on the original long connection instance.

[0028] According to a second aspect of the embodiments of the present application, the present application provides a request state keeping device based on an HTTP long connection pool, which comprises:

[0029] A connection establishing module, configured to add a connection keeping parameter in the request header of an HTTP request of a client to establish a long connection with a server;

[0030] An instance storing module, configured to store the established long connection instance in a connection pool array, and set a corresponding mutual exclusion lock for each long connection instance;

[0031] A mapping recording module, configured to set a corresponding request ID for each type of request of the client, and record the mapping relationship of the request ID to the long connection;

[0032] A connection pool updating module, configured to, in response to the number of request IDs mapped to the same long connection exceeding a preset threshold, establish a new long connection and store it in the connection pool array.

[0033] According to any of the embodiments of the present application, the device further comprises an information transmission module, configured to, in response to the long connection being established for the first time, transmit the request ID and state information to the server, so that the server reuses the request ID and the state information until the long connection is disconnected.

[0034] According to any of the embodiments of the present application, the information transmission module comprises:

[0035] an information obtaining unit, configured to: in response to that the service end establishes a long connection with the client, control the service end to extract the request ID and the state information of the corresponding client;

[0036] an information storage unit, configured to: store the request ID and the state information in the form of a key-value pair in the memory of the service end, wherein the key is the request ID and the value is the state information.

[0037] According to any one of the embodiments of the present application, the instance storage module comprises:

[0038] an instance generation unit, configured to: in response to that the client establishes a long connection with the service end, generate a long connection instance according to the long connection, wherein the connection instance comprises a request ID, a connection state and a connection start time stamp of the long connection;

[0039] an instance management unit, configured to: add the connection instance to a predefined array structure, and use the array structure as a connection pool to store and manage all the long connection instances;

[0040] a mutex lock adding unit, configured to: for each connection instance, set an initialization mutex lock, and use the mutex lock to synchronize the access to the long connection instance.

[0041] According to any one of the embodiments of the present application, after the mapping recording module sets a corresponding request ID for each type of request of the client and records the mapping relationship between the request ID and the long connection, the method further comprises:

[0042] an ID matching unit, configured to: in response to that the long connection is established for the first time, assign a corresponding request ID to the current long connection according to the request type of the HTTP request initiated by the client;

[0043] an instance matching unit, configured to: quickly locate the current long connection to the corresponding connection instance according to the mapping relationship.

[0044] According to any one of the embodiments of the present application, the connection pool updating module comprises:

[0045] a number monitoring unit, configured to: monitor the number of request IDs mapped on each long connection instance in real time, and initialize a new long connection instance if the number of request IDs on a long connection instance exceeds a preset threshold;

[0046] an instance adding unit, configured to: add the newly created long connection instance to the connection pool array to disperse the load on the original long connection instance.

[0047] According to a third aspect of the embodiments of the present application, the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the HTTP long connection pool based request state keeping method when executing the program.

[0048] According to a fourth aspect of the embodiments of the present application, the present application provides a computer readable storage medium, which stores a computer program, wherein the computer program is executable on a processor to implement the steps of the HTTP long connection pool based request state keeping method.

[0049] According to a fifth aspect of the embodiments of the present application, the present application provides a computer program product, comprising computer programs / instructions, wherein the computer programs / instructions are executable on a processor to implement the steps of the HTTP long connection pool based request state keeping method.

[0050] According to the above technical solution, the present application provides an HTTP long connection pool based request state keeping method and device, wherein a connection keeping parameter is added in a request header of an HTTP request of a client to establish a long connection with a server; the established long connection instance is stored in a connection pool array, and a corresponding mutex is set for each long connection instance; a corresponding request ID is set for each type of request of the client, and a mapping relationship of the request ID to the long connection is recorded; when the number of request IDs mapped to the same long connection exceeds a preset threshold, a new long connection is established and stored in the connection pool array, which can ensure that the real server for each request connection is the same, and the data is directly cached in the memory of the real server, thereby reducing the network IO resource overhead. BRIEF DESCRIPTION OF DRAWINGS

[0051] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings described below are some embodiments of the present application, and those skilled in the art can obtain other drawings according to the drawings without creative labor.

[0052] Figure 1 One of the flowcharts of the HTTP long connection pool based request state keeping method in the embodiments of the present application;

[0053] Figure 2 One of the flowcharts of the HTTP long connection pool based request state keeping method in the embodiments of the present application;

[0054] Figure 3 One of the flowcharts of the HTTP long connection pool based request state keeping method in the embodiments of the present application;

[0055] Figure 4 Figure 4 is a flowchart of a method for maintaining a request state based on a HTTP long connection pool according to an embodiment of the present application;

[0056] Figure 5 Figure 5 is a flowchart of a method for maintaining a request state based on a HTTP long connection pool according to an embodiment of the present application;

[0057] Figure 6 Figure 1 is a structural diagram of a device for maintaining a request state based on a HTTP long connection pool according to an embodiment of the present application;

[0058] Figure 7 Figure 2 is a structural diagram of a device for maintaining a request state based on a HTTP long connection pool according to an embodiment of the present application;

[0059] Figure 8 Figure 3 is a structural diagram of a device for maintaining a request state based on a HTTP long connection pool according to an embodiment of the present application;

[0060] Figure 9 Figure 4 is a structural diagram of a device for maintaining a request state based on a HTTP long connection pool according to an embodiment of the present application;

[0061] Figure 10 Figure 5 is a structural diagram of a device for maintaining a request state based on a HTTP long connection pool according to an embodiment of the present application;

[0062] Figure 11 Figure 6 is a structural diagram of a device for maintaining a request state based on a HTTP long connection pool according to an embodiment of the present application;

[0063] Figure 12 Figure 7 is a structural diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0064] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below in connection with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0065] The acquisition, storage, use, processing and the like of data in the technical solutions of the present application comply with relevant provisions of national laws and regulations.

[0066] The information collected in the technical solutions in the present application is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of relevant data comply with relevant laws, regulations and standards of countries and regions, necessary security measures are taken, do not violate public order and good customs, and provide corresponding operation portal for user to choose authorization or refusal.

[0067] The present application provides a request state keeping method and device based on HTTP long connection pool, which adopts a long connection mode to ensure that the real server connected by each request is the same, directly caches repeated data in each request in the memory of the real server, reduces the network IO resource overhead, and through the management mode of the connection pool, multiple HTTP requests reuse the same connection in the connection pool, thereby reducing the number of long connections, and solving the problem that the number of long connections that can be established by the request server has an upper limit.

[0068] In order to ensure that the real server connected by each request is the same, directly cache data in the memory of the real server, and reduce the network IO resource overhead, the present application provides an embodiment of a request state keeping method based on HTTP long connection pool, as shown in Figure 1 , the request state keeping method based on HTTP long connection pool specifically includes the following contents:

[0069] Step S101: adding a connection keeping parameter in the request header of the HTTP request of the client to establish a long connection with the server.

[0070] In order to optimize the use of network resources and reduce the frequency of connection establishment and disconnection, the client can add a "Connection: Keep-Alive" parameter in the request header when sending an HTTP request. The function of the parameter is to instruct the server not to close the TCP connection after processing the current request, but to keep it open, so that subsequent requests can continue to use the established connection. The above long connection mechanism significantly reduces the delay and processing overhead caused by TCP handshake (three-way handshake), and improves the efficiency of data transmission.

[0071] In addition, long connection reduces the network resource consumption of connection establishment and release required by each request, thereby reducing the load of the server and improving the overall response speed and reliability of the system. For application scenarios that require frequent interaction, such as real-time communication and online games, the application of long connection is particularly critical, which can significantly improve user experience.

[0072] Step S102: storing the established long connection instance into a connection pool array, and setting a corresponding mutex lock for each long connection instance.

[0073] When using long connections, in order to more effectively manage the connections and optimize their utilization, the system stores each established long connection instance in a connection pool.

[0074] The connection pool is a connection that is a channel in the network for transmitting data, which can be expressed using arrays, linked lists, queues, maps in programming, for managing a group of persistent connections, so that the connections can be shared and reused by multiple client requests.

[0075] Each connection instance is assigned a mutex in the connection pool. The mutex ensures that only one thread can use the connection instance at any given time, preventing data conflicts and resource contention issues in a multi-threaded environment. The mutex ensures that the connection instance is thread-safe, which is crucial for maintaining data integrity and consistency in high-concurrency application scenarios.

[0076] Step S103: Set a corresponding request ID for each type of request of the client, and record the mapping relationship between the request ID and the long connection.

[0077] In the management of the long connection pool, in order to more effectively track and control different client requests, a unique request ID can be assigned to each type of request. The request ID is used to identify and distinguish different request types or requests from different clients. Once the request ID is assigned, the mapping relationship between the request ID and the long connection used is recorded internally. The establishment of the above mapping relationship allows the system to quickly find out which long connection is used by which request, thereby achieving more efficient connection reuse and more accurate resource allocation.

[0078] In addition, by maintaining the mapping relationship between the request ID and the long connection, the system can quickly locate the problem and reallocate resources when the long connection has problems or performance degradation.

[0079] Step S104: In response to the number of request IDs mapped to the same long connection exceeding a preset threshold, a new long connection is established and stored in the connection pool array.

[0080] When the system detects that the number of request IDs bound to a long connection exceeds the preset threshold, it indicates that the connection may be affected by excessive load and performance degradation. In order to maintain the response speed and connection quality of the system, the establishment of a new long connection will be automatically triggered. After creating a new connection, the connection will also be added to the connection pool. The addition of new connections helps to disperse the load pressure of the original connection, improving the scalability and reliability of the system. By dynamically adjusting the number of connections in the connection pool, the system can adapt to different load situations and maintain the optimal running state.

[0081] From the above description, the request state keeping method based on the HTTP long connection pool provided by the embodiments of the present application can use the long connection mode to ensure that the real server for each request connection is the same, so as to directly cache the repeated data in each request in the memory of the real server, thereby reducing the network IO resource overhead, and by using the management mode of the connection pool, multiple HTTP requests reuse the same connection in the connection pool, so as to reduce the number of long connections, and solve the problem that the number of long connections that can be established by the request server has an upper limit.

[0082] In an embodiment of the request state keeping method based on the HTTP long connection pool of the present application, the following content can be specifically included:

[0083] In response to the first establishment of the long connection, the request ID and the state information are transmitted to the server, so that the server reuses the request ID and the state information until the long connection is disconnected.

[0084] When the client and the server first establish the long connection, in addition to the creation of the connection itself, the session state information transmitted in the initial stage of the connection establishment is also important.

[0085] In the life cycle of the connection, the amount of data to be transmitted needs to be reduced as much as possible to optimize the communication efficiency. For this purpose, the client sends the request ID and the state information (such as the user's login credentials, user preference settings, historical operation data, etc.) related to the connection to the server. The information will be cached on the server, so that the same data does not need to be repeatedly sent in subsequent requests. The data load of each request is significantly reduced, the data processing speed is improved, and the network delay is reduced. The server uses the cached data to maintain the user state and provide personalized services until the long connection is finally disconnected. Not only the resource utilization efficiency is improved, but also the user experience is improved.

[0086] In an embodiment of the request state keeping method based on the HTTP long connection pool of the present application, referring to Figure 2 the following content can be specifically included:

[0087] Step S201: In response to the establishment of the long connection between the server and the client, the server is controlled to extract the request ID and the state information of the corresponding client.

[0088] After the client and the server successfully establish a long connection, the operation program of the server automatically extracts the request ID and related state information contained in the connection request. The purpose of extracting the information is to use it to process subsequent requests without the client re-submitting the same information each time. For example, if a user logs into a service and performs a series of operations, the server can save the user's login state and operation context through this extraction, so that the user does not need to re-verify the identity in subsequent operations.

[0089] Step S202: Store the request ID and the state information in the form of a key-value pair in the memory of the server, where the key is the request ID and the value is the state information.

[0090] After extracting the request ID and the state information, the server stores the information in the form of a key-value pair in its memory. Since the memory access speed is much faster than any other form of data storage, the above storage method makes the data access extremely efficient and direct.

[0091] The storage model of the key-value pair is very suitable for scenarios of frequent access and modification, which can be indexed by the request ID, and the state information stored in the memory can be quickly called to process new requests, realizing the continuous maintenance of the state and the rapid response to the client operation. Not only reduces the I / O operation of the database or other storage systems, but also significantly improves the processing speed, reduces the complexity of the system to improve the system throughput.

[0092] In an embodiment of the request state keeping method based on the HTTP long connection pool of the present application, referring to Figure 3 , the long connection instance established is stored in the connection pool array, and a corresponding mutex is set for each long connection instance, which can further include the following contents:

[0093] Step S102A: In response to the client and the server establishing a long connection, a long connection instance is generated according to the long connection, which includes the request ID, connection state and connection start timestamp of the long connection.

[0094] The request ID is a unique identifier used to distinguish and track connection requests from different clients. For example, the connection state shows whether the connection is active, waiting or closed, which is extremely important for managing the connection life cycle. The timestamp of the connection start records the exact time of the connection establishment, which helps to perform timeout management, performance analysis and other operations. This makes the connection management more systematic and traceable, and improves the efficiency and reliability of long connection processing.

[0095] Step S102B: Add the connection instance to a predefined array structure, which serves as a connection pool for storing and managing all the long connection instances.

[0096] The generated long connection instance is added to a predefined array structure, which acts as a connection pool. The connection pool is a technique for efficiently managing and reusing long connections by centrally storing all active long connection instances for quick access and deployment. By centrally managing connections, it is easier to implement unified monitoring and maintenance strategies, optimize resource utilization, and reduce the overhead of establishing and disconnecting connections each time.

[0097] Step S102C: For each connection instance, set an initialization mutex, which is used for synchronization of access to the long connection instance.

[0098] A mutex is set for each connection instance, so that only one thread can modify or access the connection instance at any time, preventing data conflicts and race conditions. Through the locking mechanism, it can ensure that each user's operation is executed correctly even in the case of multiple users accessing at the same time, maintaining the stability and response speed of the entire system.

[0099] In an embodiment of the HTTP long connection pool-based request state retention method of the present application, referring to Figure 4 After setting a corresponding request ID for each type of request from the client and recording the mapping relationship between the request ID and the long connection, the following content can also be included:

[0100] Step S103A: In response to the non-first establishment of a long connection, assign a corresponding request ID to the current long connection according to the request type of the HTTP request initiated by the client;

[0101] Step S103B: According to the mapping relationship, quickly locate the current long connection to the corresponding connection instance.

[0102] When a long connection between a client and a server has been established, and the connection is not used for the first time to initiate a request, effective management of the new request is needed. Among them, a suitable request ID can be re-assigned to the current long connection according to the type of HTTP request initiated by the client. That is, each request is assigned a unique identifier according to its characteristics (such as request content, target service or operation type, etc.), so that each request can be accurately tracked and managed, rather than relying on the persistence of the long connection itself.

[0103] After assigning a request ID to each request, the mapping relationship between the request ID and the long connection established previously can be used to quickly locate the corresponding connection instance. Since it relies on the previously established mapping relationship, the request can be quickly routed to the correct connection instance.

[0104] The above embodiments greatly reduce the time required to find and match connection instances, thereby speeding up request processing. By associating each request with the long connection instance it uses, it ensures that each request can be correctly processed in the shortest possible time, optimizing user experience and system response capabilities.

[0105] In an embodiment of the request state maintenance method based on the HTTP long connection pool in the present application, referring to Figure 5 , the response to the number of request IDs mapped to the same long connection exceeding the preset threshold, establishing a new long connection and storing it in the connection pool array, can also specifically include the following content:

[0106] Step S104A: Real-time monitoring of the number of request IDs mapped on each long connection instance, and initializing a new long connection instance if the number of request IDs on a long connection instance exceeds the preset threshold;

[0107] Step S104B: Adding the newly created long connection instance to the connection pool array to distribute the load on the original long connection instance.

[0108] When it is detected that the number of request IDs on any long connection instance reaches or exceeds the pre-set threshold, it indicates that the connection may become unstable or inefficient due to excessive request load. In order to avoid the impact of the above situation on service quality, a new long connection instance can be initialized. The establishment of the new instance is dynamically determined according to the current network conditions and server state, ensuring the reliability and responsiveness of the new connection.

[0109] The main purpose of adding a new connection instance to the connection pool is to distribute the request load on the original connection instance. This distribution strategy can significantly reduce the delay and failure risk of a single connection due to handling too many requests.

[0110] In addition, by expanding the connection pool, it can more flexibly cope with sudden high traffic situations, maintain the continuous stability and high response speed of the service. Managing multiple connection instances in the connection pool also helps to balance the server's workload and optimize resource allocation, thereby improving the processing capacity and efficiency of the entire system.

[0111] In order to ensure that the real server connected by each request is the same, the data is directly cached in the memory of the real server, and the network IO resource overhead is reduced. An embodiment of a request state keeping device based on an HTTP long connection pool is provided for implementing all or part of the contents of the request state keeping method based on the HTTP long connection pool. Referring to Figure 6 , the request state keeping device based on the HTTP long connection pool specifically includes the following contents:

[0112] The connection establishing module 1101 is configured to add a connection keeping parameter in a request header of an HTTP request to establish a long connection with a server.

[0113] The instance storage module 1102 is configured to store the established long connection instance into a connection pool array, and set a corresponding mutex lock for each long connection instance.

[0114] The mapping recording module 1103 is configured to set a corresponding request ID for each type of request of the client, and record the mapping relationship between the request ID and the long connection.

[0115] The connection pool updating module 1104 is configured to, in response to the number of request IDs mapped to the same long connection exceeding a preset threshold, establish a new long connection and store it into the connection pool array.

[0116] According to any embodiment of the present application, the information transmission module is further configured to, in response to the first establishment of the long connection, transmit the request ID and the state information to the server, so that the server reuses the request ID and the state information until the long connection is disconnected.

[0117] According to any embodiment of the present application, referring to Figure 7 , the information transmission module includes:

[0118] The information acquisition unit 2201 is configured to, in response to the establishment of the long connection between the server and the client, control the server to extract the request ID and the state information of the corresponding client.

[0119] The information storage unit 2202 is configured to store the request ID and the state information in the form of a key-value pair in the memory of the server, wherein the key is the request ID and the value is the state information.

[0120] According to any embodiment of the present application, referring to Figure 8 , the instance storage module includes:

[0121] The instance generation unit 1102A is configured to generate a long connection instance according to the long connection in response to that the client establishes a long connection with the server, wherein the connection instance comprises a request ID, a connection state and a connection start time stamp of the long connection;

[0122] The instance management unit 1102B is configured to add the connection instance into a predefined array structure, and the array structure is used as a connection pool to store and manage all the long connection instances;

[0123] The mutex lock adding unit 1102C is configured to set an initialization mutex lock for each connection instance, and the mutex lock is used for synchronization of access to the long connection instance.

[0124] According to any one of the embodiments of the present application, referring to Figure 9 , after the mapping recording module sets a corresponding request ID for each type of request of the client and records the mapping relationship between the request ID and the long connection, the method further comprises:

[0125] The ID matching unit 1103A is configured to assign a corresponding request ID to the current long connection according to the request type of the HTTP request initiated by the client in response to that the long connection is established for the first time.

[0126] The instance matching unit 1103B is configured to quickly locate the current long connection to the corresponding connection instance according to the mapping relationship.

[0127] According to any one of the embodiments of the present application, referring to Figure 10 , the connection pool updating module comprises:

[0128] The number monitoring unit 1104A is configured to monitor the number of request IDs mapped on each long connection instance in real time, and initialize a new long connection instance in the case that the number of request IDs on a long connection instance exceeds a preset threshold.

[0129] The instance adding unit 1104B is configured to add the newly created long connection instance into the connection pool array to disperse the load on the original long connection instance.

[0130] As can be seen from the above description, the request state keeping device based on the HTTP long connection pool provided by the embodiments of the present application can use the long connection mode to ensure that the real server for each request connection is the same, so as to directly cache the repeated data in each request in the memory of the real server, thereby reducing the network IO resource overhead, and by using the management mode of the connection pool, multiple HTTP requests reuse the same connection in the connection pool, so as to reduce the number of long connections, and solve the problem that the number of long connections that can be established by the request server has an upper limit.

[0131] For further illustration of the present solution, the present application further provides a specific application example of the HTTP long connection pool-based request state keeping method implemented by the HTTP long connection pool-based request state keeping device, which is described in detail with reference to Figure 11 , and specifically includes the following contents:

[0132] The request client adds the Connection: Keep-Alive parameter in the request header of the HTTP request to ensure that the long connection mode is used to connect with the request server. After the long connection instance is created, the long connection instance is stored in an array, and a mutex is added for each long connection instance. A subsequent request for each type of client is set with an id, and the mapping relationship between the request id and the long connection is recorded. When the number of request ids mapped to the same long connection exceeds a certain threshold, a new long connection is created and stored in the connection pool array. In the present application, the initial number of long connections in the connection pool is 1, and the number of request ids that can be mapped to each long connection is 10, i.e., requests with ids 1-10 use the first long connection in the connection pool, and the 11th request uses the newly created second long connection (here, the request id is not limited to a number, but only represents a unique identifier of the request). At the same time, the historical data and other state information are transmitted to the request server at one time when each type of request is established. After the request server caches the state information, the information is continuously reused until the long connection is disconnected.

[0133] After the request server receives the long connection request from the client, the connection state of the long connection is maintained, and the contents that need to be cached in the subsequent received requests are stored in the form of key-value pairs in the memory, with the key being the request id and the value being the historical data and other state information that need to be cached. In the present application, the application scenario is mainly to determine whether an exception occurs at the current time point by using historical data and current monitoring data. Therefore, the request id used in the present application is the application name, and the state information is the business success rate and other monitoring data of the application. The message of the first communication is as follows:

[0134] {

[0135] “id”: XX,

[0136] “nowData”: 99%,

[0137] “historyData”: [98%, 99%, 100%, 97%, 98%, 99%, 100%, 96%...]

[0138] }

[0139] The message of the subsequent communication is as follows:

[0140] {

[0141] "id": XX,

[0142] "nowData": 99%

[0143] }

[0144] The historyData field is cached in the memory of the request server, so that the field does not need to be carried in subsequent messages except for the first connection, and in the case of the present application, more than 90% of the network IO communication overhead is reduced. The more repetitive state information carried by each request, the better the optimization effect of the present application.

[0145] From the hardware level, in order to ensure that the real server connected by each request is the same, the data is directly cached in the memory of the real server to reduce the network IO resource overhead, and the present application provides an embodiment of an electronic device for implementing all or part of the contents of the request state keeping method based on the HTTP long connection pool. The electronic device specifically includes the following contents:

[0146] A processor, a memory, a communications interface, and a bus; wherein the processor, the memory, the communications interface, and the bus complete mutual communication through the bus; the communications interface is used for realizing information transmission between the request state keeping device based on the HTTP long connection pool and the core business system, the user terminal, and related databases and related devices; the logic controller can be a desktop computer, a tablet computer, and a mobile terminal, and the present embodiment is not limited thereto. In the present embodiment, the logic controller can be implemented with reference to the embodiments of the request state keeping method based on the HTTP long connection pool and the embodiments of the request state keeping device based on the HTTP long connection pool, the contents of which are incorporated herein, and repeated descriptions are omitted.

[0147] It can be understood that the user terminal can include a smart phone, a tablet electronic device, a network set-top box, a portable computer, a desktop computer, a personal digital assistant (PDA), a vehicle-mounted device, a smart wearable device, etc. The smart wearable device can include smart glasses, a smart watch, a smart bracelet, etc.

[0148] In actual application, part of the request state keeping method based on the HTTP long connection pool can be executed on the electronic device as described above, or all operations can be completed in the client device. Specifically, the selection can be made according to the processing capacity of the client device and the limitation of the user usage scenario, etc. The present application is not limited thereto. If all operations are completed in the client device, the client device can further include a processor.

[0149] The client device described above can have a communication module (i.e., a communication unit) that can be communicatively connected to a remote server to implement data transmission with the server. The server can include a server of a task scheduling center side, and in other implementation scenarios, can also include a server of an intermediate platform, such as a server of a third-party server platform that is communicatively linked to the server of the task scheduling center. The server can include a single computer device, or can include a server cluster composed of multiple servers, or a server structure of a distributed device.

[0150] Figure 12 A schematic block diagram of a system configuration of an electronic device 9600 according to an embodiment of the present application is shown in FIG. 9. As shown in the figure, the electronic device 9600 can include a central processor 9100 and a memory 9140; the memory 9140 is coupled to the central processor 9100. It is noted that the structure shown in the figure is exemplary; other types of structures can also be used to supplement or replace the structure to implement telecommunication functions or other functions. Figure 12 Figure 12 The structure shown in the figure is exemplary; other types of structures can also be used to supplement or replace the structure to implement telecommunication functions or other functions.

[0151] In an embodiment, the request state maintaining method based on the HTTP long connection pool can be integrated into the central processor 9100. The central processor 9100 can be configured to perform the following control:

[0152] Step S101: Adding a connection maintaining parameter in a request header of an HTTP request of a client to establish a long connection with a server.

[0153] Step S102: Storing the established long connection instance into a connection pool array, and setting a corresponding mutual exclusion lock for each long connection instance.

[0154] Step S103: Setting a corresponding request ID for each type of request of the client, and recording a mapping relationship of the request ID to the long connection.

[0155] Step S104: In response to a number of request IDs mapped to the same long connection exceeding a preset threshold, establishing a new long connection and storing it into the connection pool array.

[0156] From the above description, it can be known that the electronic device provided by the embodiment of the present application adopts a long connection mode to ensure that a real server for each request connection is the same, so as to directly cache repeated data in each request in the memory of the real server, thereby reducing the overhead of network IO resources, and by adopting a management mode of a connection pool, multiple HTTP requests reuse the same connection in the connection pool, so as to reduce the number of long connections, and solve the problem that the number of long connections that can be established with a request server has an upper limit.

[0157] ​In another embodiment, the HTTP long connection pool based request state maintaining apparatus can be configured separately from the central processor 9100, for example, the HTTP long connection pool based request state maintaining apparatus can be configured as a chip connected with the central processor 9100, and the HTTP long connection pool based request state maintaining method functions are realized through the control of the central processor.

[0158] As shown in Figure 12 , the electronic device 9600 can further include a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily include all the components shown in Figure 12 ; in addition, the electronic device 9600 can also include components not shown in Figure 12 , which can be referred to prior art.

[0159] As shown in Figure 12 , the central processor 9100, also sometimes referred to as a controller or operating control, can include a microprocessor or other processor device and / or logic device, which receives input and controls the operation of the various components of the electronic device 9600.

[0160] The memory 9140, for example, can be one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, or other suitable device. Information related to failures can be stored, in addition to programs for executing the information. The central processor 9100 can execute the programs stored in the memory 9140 to achieve information storage or processing, etc.

[0161] The input unit 9120 provides input to the central processor 9100. The input unit 9120 is, for example, a key or touch input device. The power supply 9170 is used to provide power to the electronic device 9600. The display 9160 is used to display display objects such as images and text. The display can be, for example, an LCD display, but is not limited thereto.

[0162] The memory 9140 can be a solid state memory such as a read only memory (ROM), a random access memory (RAM), a SIM card, or the like. It can also be a memory that retains information even when power is off, can be selectively erased, and is provided with more data, an example of which is sometimes referred to as an EPROM or the like. The memory 9140 can also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 can include an application / function storage 9142 for storing application programs and function programs or for storing a flow for executing an operation of the electronic device 9600 by the central processing unit 9100.

[0163] The memory 9140 can also include a data storage 9143 for storing data such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. A driver storage 9144 of the memory 9140 can include various drivers of the electronic device for a communication function and / or for performing other functions of the electronic device such as a messaging application, a phonebook application, and the like.

[0164] The communication module 9110 is a transmitter / receiver 9110 that transmits and receives signals via an antenna 9111. The communication module (transmitter / receiver) 9110 is coupled to the central processing unit 9100 to provide input signals and receive output signals, which can be the same as in the case of a conventional mobile communication terminal.

[0165] Based on different communication technologies, a plurality of communication modules 9110 such as a cellular network module, a Bluetooth module, and / or a wireless local area network module, and the like can be provided in the same electronic device. The communication module (transmitter / receiver) 9110 is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby enabling a conventional telecommunication function. The audio processor 9130 can include any suitable buffer, decoder, amplifier, and the like. In addition, the audio processor 9130 is also coupled to the central processing unit 9100, thereby enabling recording on the local by the microphone 9132 and playing a sound stored on the local by the speaker 9131.

[0166] The embodiment of the present application further provides a computer readable storage medium capable of realizing all steps of the HTTP long connection pool based request state keeping method with the execution subject being a server or a client in the above embodiment, and the computer program is stored on the computer readable storage medium, and when the computer program is executed by a processor, all steps of the HTTP long connection pool based request state keeping method with the execution subject being a server or a client in the above embodiment are realized, for example, the processor realizes the following steps when executing the computer program:

[0167] Step S101: adding a connection keeping parameter in a request header of an HTTP request of a client to establish a long connection with a server.

[0168] Step S102: storing the established long connection instance into a connection pool array, and setting a corresponding mutex lock for each long connection instance.

[0169] Step S103: setting a corresponding request ID for each type of request of the client, and recording a mapping relationship of the request ID to the long connection.

[0170] Step S104: in response to a number of request IDs mapped to the same long connection exceeding a preset threshold, establishing a new long connection and storing the new long connection into the connection pool array.

[0171] From the above description, it can be known that the computer readable storage medium provided by the embodiment of the present application adopts a long connection mode to ensure that a real server for each request connection is the same, so as to directly cache repeated data in each request in the memory of the real server, thereby reducing the network IO resource overhead, and through the management mode of the connection pool, multiple HTTP requests reuse the same connection in the connection pool, so as to reduce the number of long connections, and solve the problem that the number of long connections that can be established by a request server has an upper limit.

[0172] The embodiment of the present application further provides a computer program product capable of realizing all steps of the HTTP long connection pool based request state keeping method with the execution subject being a server or a client in the above embodiment, and when the computer program / instruction is executed by a processor, the steps of the HTTP long connection pool based request state keeping method are realized, for example, the computer program / instruction realizes the following steps:

[0173] Step S101: adding a connection keeping parameter in a request header of an HTTP request of a client to establish a long connection with a server.

[0174] Step S102: storing the established long connection instance into a connection pool array, and setting a corresponding mutex lock for each long connection instance.

[0175] Step S103: setting a corresponding request ID for each type of request of the client, and recording a mapping relationship of the request ID to the long connection.

[0176] Step S104: in response to a number of request IDs mapped to the same long connection exceeding a preset threshold, establishing a new long connection and storing it into the connection pool array.

[0177] From the above description, it can be seen that the computer program product provided by the embodiment of the present application adopts the long connection mode to ensure that the real server connected by each request is the same, so as to directly cache repeated data in each request in the memory of the real server, thereby reducing the network IO resource overhead, and by adopting the connection pool management mode, multiple HTTP requests reuse the same connection in the connection pool, so as to reduce the number of long connections, and solve the problem that the number of long connections that can be established by the request server has an upper limit.

[0178] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, device, or computer program product. Therefore, the present application can adopt a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program codes.

[0179] The present application is described with reference to flowcharts and / or block diagrams of the method, device (apparatus), and computer program product according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. The computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device implemented in the flowcharts and / or block diagrams. Figure 1 The device that implements the function specified in one flow or multiple flows and / or blocks. Figure 1 The device that implements the function specified in one flow or multiple flows and / or blocks.

[0180] The computer program instructions can also be stored in a computer readable storage medium capable of guiding a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable storage medium produce a manufactured product including instruction devices, which implement the functions specified in the flowcharts and / or block diagrams. Figure 1 The device that implements the function specified in one flow or multiple flows and / or blocks. Figure 1 The device that implements the function specified in one flow or multiple flows and / or blocks.

[0181] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0182] The principles and implementation manners of the present application are described in the specific embodiments. The above embodiment is only used to help understand the method and core idea of the present application. Meanwhile, for those skilled in the art, according to the idea of the present application, the specific implementation manners and application scopes will be changed. In summary, the content of the specification should not be understood as a limitation of the present application.

Claims

1. A method for keeping a request state based on HTTP long connection pool, characterized in that, The method comprises: adding a connection maintaining parameter in a request header of an HTTP request by a client to establish a long connection with a server; storing a long connection instance established into a connection pool array and setting a corresponding mutual exclusion lock for each long connection instance; setting a corresponding request ID for each type of request of the client and recording a mapping relationship of the request ID to the long connection; in response to a number of request IDs mapped to the same long connection exceeding a preset threshold, establishing a new long connection and storing it into the connection pool array; in response to establishing the long connection for the first time, transmitting the request ID and state information to the server to enable the server to reuse the request ID and the state information until the long connection is disconnected.

2. The method of claim 1, wherein, The transmitting the request ID and the state information to the server comprises: in response to the server establishing a long connection with the client, controlling the server to extract the request ID and the state information of the corresponding client; storing the request ID and the state information in the form of a key-value pair into the memory of the server, wherein the key is the request ID and the value is the state information.

3. The HTTP long connection pool based request state holding method according to claim 1, wherein, The storing the long connection instance established into the connection pool array and setting a corresponding mutual exclusion lock for each long connection instance comprises: in response to the client establishing a long connection with the server, generating a long connection instance according to the long connection, the connection instance comprising a request ID, a connection state and a connection start timestamp of the long connection; adding the connection instance to a predefined array structure, the array structure serving as a connection pool for storing and managing all the long connection instances; for each connection instance, setting an initialization mutual exclusion lock, the mutual exclusion lock being used for synchronization of access to the long connection instance.

4. The method of claim 1, wherein, After setting a corresponding request ID for each type of request of the client and recording a mapping relationship of the request ID to the long connection, the method further comprises: in response to establishing the long connection for the first time, assigning a corresponding request ID to the current long connection according to a request type of an HTTP request initiated by the client; quickly locating the current long connection to the corresponding connection instance according to the mapping relationship.

5. The method of claim 1, wherein, The establishing a new long connection and storing it into the connection pool array in response to a number of request IDs mapped to the same long connection exceeding a preset threshold comprises: monitoring the number of request IDs mapped on each long connection instance in real time, and initializing a new long connection instance in the case that the number of request IDs on a long connection instance exceeds a preset threshold; adding the newly created long connection instance to the connection pool array to disperse the load on the original long connection instance.

6. An apparatus for keeping a request state based on an HTTP long connection pool, characterized by, The apparatus comprises: a connection establishing module, configured to add a connection maintaining parameter in a request header of an HTTP request by a client to establish a long connection with a server; an instance storage module, configured to store a long connection instance established into a connection pool array and set a corresponding mutual exclusion lock for each long connection instance; a mapping recording module, configured to set a corresponding request ID for each type of request of the client and record a mapping relationship of the request ID to the long connection. The connection pool updating module is configured to: in response to the number of request IDs mapped to the same long connection exceeding a preset threshold, establish a new long connection and store it in the connection pool array; The information transmission module is configured to: in response to the first establishment of the long connection, transmit the request ID and the state information to the server, so that the server multiplexes the request ID and the state information until the long connection is disconnected.

7. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor implements the steps of the HTTP long connection pool-based request state keeping method of any one of claims 1 to 5 when executing the program.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the HTTP long connection pool-based request state keeping method of any one of claims 1 to 5.

9. A computer program product comprising computer programs / instructions, characterized in that, The computer program / instruction is executed by the processor to implement the steps of the HTTP long connection pool-based request state keeping method of any one of claims 1 to 5.

Images