Information acquisition method and device

Abstract

The present application discloses an information acquisition method and device. The method includes: creating several call threads for obtaining call results based on a target call request received from an upstream application server; searching for a target storage location based on a request identifier carried by a currently running call thread to obtain a search result; matching a corresponding target acquisition method for the currently running call thread based on the search result, so as to obtain a call result corresponding to the currently running call thread from the target storage location based on the currently running call thread, or calling a downstream application server based on the currently running call thread to obtain a call result from the downstream application server. The method in the present application obtains the call result from the cache by searching for the target storage location before calling the downstream application server, thereby reducing the load on the downstream application server.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to an information acquisition method and device. Background Art

[0002] With the popularization of Internet technology, local servers process requests from upstream application servers to obtain corresponding information from downstream application servers. Figure 1 As shown, the request of the upstream application server may spread to multiple concurrently executed sub-requests / calling threads on the local server. In the prior art, each sub-request / calling thread needs to call the downstream application server once to obtain the corresponding information, so N sub-requests will generate M calls (0≤M≤N). However, these sub-requests carry the same common parameters, so the input parameters and return results involved in the remote call to the downstream application server are the same, so frequent calls to the downstream application server will cause the downstream application server to have a large load. Summary of the invention

[0003] In view of this, the present invention provides an information acquisition method and device, the main purpose of which is to solve the problem that downstream application servers are frequently called during the current information acquisition process, resulting in a heavy load on the downstream application servers.

[0004] To solve the above problems, the present application provides an information acquisition method, comprising:

[0005] Based on the target call request received from the upstream application server, a plurality of call threads are created for obtaining the call result; each of the call threads carries a request identifier of the target call request;

[0006] Searching for a target storage location based on the request identifier carried by the currently running calling thread to obtain a search result;

[0007] Based on the search result, a corresponding target acquisition method is matched for the currently running calling thread, so as to obtain a calling result corresponding to the currently running calling thread from the target storage location based on the currently running calling thread, or a downstream application server is called based on the currently running calling thread to obtain a calling result from the downstream application server.

[0008] Optionally, before searching for the target storage location based on the request identifier carried by the currently running calling thread, the method further includes:

[0009] Get the target request parameters and target calling method carried by each calling thread;

[0010] The request identifier carried by each calling thread is determined based at least on the target request parameter carried by each calling thread and the target calling method.

[0011] Optionally, the information acquisition method further includes:

[0012] Divide the target storage location into regions in advance to obtain a plurality of storage sections;

[0013] Configuring a corresponding read lock and write lock for each of the storage segments;

[0014] The step of searching the target storage location based on the request identifier carried by the currently running calling thread to obtain the search result specifically includes:

[0015] Based on the target read lock acquired by the currently running calling thread, the target storage segment corresponding to the target read lock in the target storage location is searched to find the calling result corresponding to the request identifier, or if the calling result corresponding to the request identifier is not found, the searching result is obtained.

[0016] Optionally, before searching the target storage segment corresponding to the target read lock in the target storage location based on the target read lock acquired by the currently running calling thread, the method further includes: determining the target read lock to be acquired by each calling thread, specifically including:

[0017] Based on the request identifier carried by each calling thread, determining the to-be-queried segment corresponding to each calling thread as the target storage segment;

[0018] Based on each of the target storage segments, a read lock corresponding to each of the target storage segments is determined as a target read lock to be acquired, so that each of the calling threads acquires the corresponding target read lock.

[0019] Optionally, matching a corresponding target acquisition mode for the currently running calling thread based on the search result, so as to obtain a call result corresponding to the currently running calling thread from the target storage location based on the currently running calling thread, or calling a downstream application server based on the currently running calling thread to obtain a call result from the downstream application server, specifically includes:

[0020] When a call result corresponding to the request identifier is found, acquiring the call result from a target storage segment corresponding to the request identifier based on the currently running call thread;

[0021] If no calling result corresponding to the request identifier is found, a downstream application server is called to obtain the calling result from the downstream application server.

[0022] Optionally, calling the downstream application server to obtain the calling result from the downstream application server specifically includes:

[0023] Based on the currently running calling thread that has acquired the write lock of the target storage segment, a downstream application server is called to obtain a calling result from the downstream application server.

[0024] Optionally, before calling the downstream application server to obtain the calling result from the downstream application server, the method further includes:

[0025] Based on the currently running calling thread that has acquired the write lock of the target storage segment, searching the target storage segment to determine whether a calling result corresponding to the request identifier carried by the currently running calling thread is stored;

[0026] In the case that the calling result corresponding to the request identifier is not found, based on the currently running calling thread that has acquired the write lock of the target storage segment, the downstream application server is called to obtain the calling result from the downstream application server.

[0027] Optionally, after calling a downstream application server based on the currently running calling thread that acquires the write lock of the target storage segment to obtain a calling result from the downstream application server, the method further includes:

[0028] Based on the write lock acquired by the currently running calling thread, the acquired calling result and the mapping relationship between the calling result and the request identifier are stored in the target storage segment.

[0029] Optionally, before storing the acquired call result and the mapping relationship between the call result and the request identifier in the target storage segment based on the write lock acquired by the currently running call thread, the method further includes:

[0030] Get the current timestamp based on the request identifier of the currently running calling thread;

[0031] Obtaining a historical timestamp of each call result stored in the target storage segment;

[0032] Based on the current timestamp and each of the historical timestamps, determining the validity of each of the call results stored in the target storage segment;

[0033] When it is determined that the calling result is invalid, the calling result is deleted.

[0034] In order to solve the above problems, the present application provides an information acquisition device, comprising:

[0035] A creation module, used to create a number of call threads for obtaining call results based on the target call request received from the upstream application server; each of the call threads carries a request identifier of the target call request;

[0036] A search module is used to search for a target storage location based on a request identifier carried by a currently running calling thread and obtain a search result;

[0037] An acquisition module is used to match a corresponding target acquisition method for the currently running calling thread based on the search result, so as to obtain a call result corresponding to the currently running calling thread from the target storage location based on the currently running calling thread, or to call a downstream application server based on the currently running calling thread to obtain a call result from the downstream application server.

[0038] The information acquisition method and device in the present application, before calling the downstream application server, determines whether the target storage location stores historical call results by searching the target storage location. In this way, when the target storage location stores historical call results corresponding to the request identifier, the call results can be directly obtained from the target storage location without calling the downstream application server again. This can reduce the load of the downstream application server and improve the information acquisition rate.

[0039] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0041] Figure 1 It is a logical principle diagram of the information acquisition process in the prior art;

[0042] Figure 2 This is a logical principle diagram of the information acquisition process in the embodiment of the present application;

[0043] Figure 3 This is a flowchart of an information acquisition method according to another embodiment of the present application;

[0044] Figure 4 A schematic diagram of target storage location storage in an embodiment of the present application;

[0045] Figure 5 This is a flow chart of an information acquisition method according to another embodiment of the present application;

[0046] Figure 6 This is a structural block diagram of an information acquisition device according to yet another embodiment of the present application. DETAILED DESCRIPTION

[0047] Various aspects and features of the present application are described herein with reference to the accompanying drawings.

[0048] It should be understood that various modifications may be made to the embodiments of the present application. Therefore, the above description should not be considered as limiting, but only as an example of an embodiment. Other modifications within the scope and spirit of the present application will occur to those skilled in the art.

[0049] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the present application and, together with the general description of the present application given above and the detailed description of the embodiments given below, serve to explain the principles of the present application.

[0050] These and other characteristics of the present application will become apparent from the following description of a preferred form of embodiment given as a non-limiting example with reference to the accompanying drawings.

[0051] It should also be understood that although the present application has been described with reference to some specific examples, those skilled in the art will be able to readily implement many other equivalent forms of the present application.

[0052] The above and other aspects, features and advantages of the present application will become more apparent in view of the following detailed description when taken in conjunction with the accompanying drawings.

[0053] Specific embodiments of the present application are described hereinafter with reference to the accompanying drawings; however, it should be understood that the embodiments applied for are merely examples of the present application, which may be implemented in a variety of ways. Well-known and / or repeated functions and structures are not described in detail to avoid unnecessary or redundant details that obscure the present application. Therefore, the specific structural and functional details applied for herein are not intended to be limiting, but merely serve as a basis and representative basis for the claims to teach those skilled in the art to use the present application in a variety of ways with substantially any suitable detailed structure.

[0054] This specification may use the phrases "in one embodiment," "in another embodiment," "in yet another embodiment," or "in other embodiments," all of which may refer to one or more of the same or different embodiments according to the present application.

[0055] The embodiment of the present application provides an information acquisition method, and the specific application scenario is that after the local server / target server obtains a request from the upstream application service, it calls the downstream application server to obtain the call result / information. That is, the execution subject in this embodiment is a third-party electronic device such as a local server or terminal. Figure 2 and Figure 3 As shown, the method in this embodiment includes the following steps:

[0056] Step S101, based on the target call request received from the upstream application server, create a number of call threads for obtaining the call result; each of the call threads carries a request identifier of the target call request;

[0057] In the specific implementation process of this step, Figure 2 As shown, after receiving the target call request sent by the upstream application server, the local server generates several call threads based on the common parameters in the target call request and other parameters corresponding to each sub-request, such as generating call thread 1, call thread 2 and call thread 3, so that each call thread will have some of the same common parameters.

[0058] Step S102, searching the target storage location based on the request identifier carried by the currently running calling thread to obtain a search result;

[0059] In the specific implementation process of this step, the currently running calling thread specifically refers to the calling thread that obtains the read lock of the target storage location. That is, the calling thread that obtains the read lock can search the historical calling result corresponding to the calling thread request identifier from the target storage location.

[0060] In this step, the request identifier carried by the calling thread is generated based on a predetermined data category, which refers to the data category involved in the common parameter part of each calling thread, for example, the common parameter part may contain data of categories such as calling method, request keyword, current timestamp, etc. That is, in each calling thread created based on the same target calling request, the common parameter part is the same, that is, it carries the same common parameters, and thus the request identifier generated based on the data categories such as calling method, request keyword and current timestamp in the common parameter part is also the same, that is, the request identifiers carried by calling thread 1, calling thread 2 and calling thread 3 are the same.

[0061] In the specific implementation process of this step, the target storage location / local cache is specifically used to store historical call results. For example, after calling the downstream application server for the first time based on calling thread 2 and obtaining the call result, the call result and the corresponding relationship with the request identifier carried by calling thread 2 will be stored in the target storage location. When subsequently calling thread 1 obtains the call result, it can use the request identifier carried by calling thread 1 to search for the target storage location. Since the request identifiers carried by calling thread 1 and calling thread 2 are the same, it is possible to accurately determine whether the target storage location has the corresponding historical call result, and then obtain the search result.

[0062] Step S103, matching a corresponding target acquisition mode for the currently running calling thread based on the search result, so as to acquire a call result corresponding to the currently running calling thread from the target storage location based on the currently running calling thread, or calling a downstream application server based on the currently running calling thread to acquire a call result from the downstream application server;

[0063] In the specific implementation process of this step, the target acquisition method specifically includes the following two methods: acquiring the call result from the target storage location and acquiring the call result from the downstream application server. That is, when it is determined that the call result corresponding to the request identifier is stored in the search result, the call result is acquired from the target storage location, and when it is determined that the call result corresponding to the request identifier is not stored in the search result, the call result is acquired from the downstream application server.

[0064] In this embodiment, before calling the downstream application server, the target storage location is searched to determine whether the target storage location stores historical call results. Therefore, if the target storage location stores historical call results corresponding to the request identifier, the call result can be directly obtained from the target storage location without calling the downstream application server again. This can reduce the load on the downstream application server and increase the rate of information acquisition.

[0065] Another embodiment of the present application provides an information acquisition method, comprising the following steps:

[0066] Step S201, pre-dividing the target storage location into regions to obtain a plurality of storage segments; configuring a corresponding read lock and write lock for each of the storage segments;

[0067] In the specific implementation of this step, the target storage location uses segmented read-write locks and hash tables to read and modify data information. Figure 4As shown, the target storage location can be divided into regions based on the concurrency C, that is, the number of storage segments is determined according to the concurrency C, that is, the number of hash tables is determined. Then a corresponding hash table is configured for each storage segment, so the capacity of a single hash table is Q / C, where Q represents the storage capacity of the target storage location; then a corresponding read-write lock can be configured for each storage segment. Among them, the read-write locks of different storage segments do not interfere with each other, thereby improving the performance of concurrent operations. The calling thread can read the hash table after acquiring the read lock, and can write to the hash table after acquiring the write lock.

[0068] Step S202, based on the target call request received from the upstream application server, create a number of call threads for obtaining the call result; each of the call threads carries a request identifier of the target call request;

[0069] Step S203, obtaining the target request parameters and the target calling method carried by each calling thread; determining the request identifier carried by each calling thread at least based on the target request parameters and the target calling method carried by each calling thread;

[0070] In this step, since each calling thread is created based on the parameters in the target calling request, the data in the common parameter part of each calling thread is the same, that is, the target request parameters / parameter keywords and target calling method in each calling thread are the same, so the request identifier carried by each calling thread is also the same.

[0071] In the specific implementation process of this step, since the current timestamp information corresponding to each calling thread under the same target calling request is also the same, the request identifier can be further calculated in combination with the current timestamp information, that is, the request identifier is obtained according to the target request parameters / parameter keywords, target calling method and current timestamp information carried in each calling thread.

[0072] Step S204, based on the target read lock acquired by the currently running calling thread, searching the target storage segment corresponding to the target read lock in the target storage location to find a call result corresponding to the request identifier, or failing to find a call result corresponding to the request identifier, to obtain the search result;

[0073] In this step, since the target storage segment can be read at the same time, each calling thread corresponding to the same target call request can obtain the read lock of the same target storage segment, and then can simultaneously read the target storage segment to determine whether the target storage segment stores historical call results. In this step, when searching the target storage segment, a hash value is calculated based on the request identifier, and then the corresponding call result is determined based on the hash value.

[0074] Before the specific implementation of this step, it is also possible to first determine that the read lock to be acquired by each calling thread is the target read lock, which specifically includes: based on the request identifier corresponding to each of the calling threads, determining the segment to be queried corresponding to each of the calling threads as the target storage segment; based on each of the target storage segments, determining the read lock corresponding to each of the target storage segments as the target read lock to be acquired, so that each of the calling threads acquires the corresponding target read lock. In the specific implementation process, the corresponding hash value can be calculated by determining the request identifier corresponding to each of the calling threads, and then the target storage segment is determined based on the hash value. In this step, by determining the storage segment to be queried and the read lock of the storage segment according to the request identifier of each calling thread, the read lock acquired by each calling thread corresponding to the same target call request can be the same, and the same storage segment is also searched when the target storage location is queried later, laying the foundation for accurately obtaining the search result.

[0075] Step S205, if the call result corresponding to the request identifier is found, execute step S206, if the call result corresponding to the request identifier is not found, execute step S207.

[0076] Step S206, obtaining the calling result from the target storage segment corresponding to the request identifier based on the currently running calling thread;

[0077] During the specific implementation of this step, when the call result corresponding to the request identifier is found and the call result is obtained from the target storage segment, the search is performed in a traversal manner based on the request identifier carried by the currently running call thread, thereby making the search result more accurate and reliable.

[0078] Step S207: calling a downstream application server based on the currently running calling thread to obtain a calling result from the downstream application server.

[0079] In this step, when the call result corresponding to the request identifier is not found to obtain the call result from the downstream application server, the specific method is: based on the currently running call thread that has obtained the write lock of the target storage segment, call the downstream application server to obtain the call result from the downstream application server. That is to say, when the target storage segment is not queried to store the historical call result corresponding to the request identifier, each currently running call thread needs to further obtain the write lock of the target storage segment, and then only the currently running call thread that has obtained the write lock will call the downstream application server to obtain the call result from the downstream application server. Since the write lock of the same storage segment can only be obtained by one call thread at a time, the above method can avoid the situation where multiple call threads call the downstream application server at the same time, avoid the problem of frequent calls to the downstream application server and high load on the downstream application server, and reduce the load on the downstream application server.

[0080] In the specific implementation process of this embodiment, after determining that a certain calling thread has acquired a write lock, and before the currently running calling thread that has acquired the write lock of the target storage segment calls the downstream application server, the method in this embodiment also includes: based on the currently running calling thread that has acquired the write lock of the target storage segment, searching the target storage segment to determine whether a call result corresponding to the request identifier carried by the currently running calling thread is stored; if the call result corresponding to the request identifier is not found, based on the currently running calling thread that has acquired the write lock of the target storage segment, calling the downstream application server to obtain the call result from the downstream application server. That is, when each calling thread acquires a read lock, searches for the target storage segment corresponding to the read lock, and determines that the target storage segment does not store a call result corresponding to the request identifier, each currently running calling thread will further acquire a write lock of the target storage segment. At this time, since only one currently running calling thread can obtain the write lock at a time, each calling thread needs to obtain the write lock in a queued manner / or randomly. The currently running calling thread that obtains the write lock will query the target storage segment again to further determine whether other calling threads have obtained the write lock, obtained the call result from the downstream server, and stored the call result in the target storage segment based on the write lock before the currently running calling thread obtains the write lock. This prevents the problem of multiple calling threads repeatedly calling the downstream application server and causing a heavy load on the downstream application server when the result of searching the target storage segment is empty (i.e., the historical call result corresponding to the request identifier is not found) when avoiding concurrent calls based on read locks.

[0081] Step S208, obtaining a current timestamp based on the request identifier carried by the currently running calling thread; obtaining a historical timestamp of each calling result stored in the target storage segment; judging the validity of each calling result stored in the target storage segment based on the current timestamp and each historical timestamp; if it is determined that the calling result is invalid, deleting the calling result.

[0082] When making a validity judgment in this step, it can be determined more specifically based on the difference between the current timestamp and the historical timestamp, that is, the difference is compared with the preset time threshold. When it is determined that the difference between the two is greater than the preset time threshold, the call result corresponding to the historical timestamp is determined to be invalid; when it is determined that the difference between the two is less than or equal to the preset time threshold, the call result corresponding to the historical timestamp is determined to be valid.

[0083] In this step, before writing the call result, the validity of each stored call result is judged by adopting the above method, so that the invalid call results can be cleaned up / deleted in time, without starting additional threads, adding additional deletion operations, and reducing the pressure of lock competition.

[0084] Step S209: based on the write lock acquired by the currently running calling thread, the acquired calling result and the mapping relationship between the calling result and the request identifier are stored in the target storage segment.

[0085] In this embodiment, by adopting the local cache method, the call result of the first call is written into the local cache. Subsequent sub-requests / calling threads can directly obtain the call results from the local cache based on the request identifier without having to call the downstream application server again. Only one call is required in total, which greatly reduces the load on the downstream application, saves the time for information acquisition, and improves the rate of information acquisition.

[0086] Based on the above embodiments, the following explanation is given in combination with specific application scenarios. Figure 5 As shown, the following steps are included:

[0087] Step 1: Based on the target call request received from the upstream application server, create several call threads for obtaining the call results;

[0088] In this step, since each calling thread is created based on the request parameters in the target calling request and the downstream calling method, the request parameters / request input parameters and the downstream calling method in each calling thread corresponding to the same target request parameters are also the same.

[0089] Step 2: Construct a string as the query key based on the request input parameter in the calling thread and the downstream calling method;

[0090] In this step, when constructing a string as a query key, the current timestamp can be further combined. That is, the query key corresponding to each calling thread is determined based on the request input parameter, downstream calling method and current timestamp information in each calling request, that is, the request identifier carried by each calling thread is determined.

[0091] In this step, by determining the request identifier carried by each calling thread, a foundation can be laid for subsequent call result search based on the query key / request identifier.

[0092] Step 3: Determine the target storage segment according to the hash value of the query key;

[0093] That is, in this step, the target storage segment is determined based on the hash value. Since the request identifiers of the calling threads corresponding to the same target request are the same, the hash values ​​calculated based on the request identifiers are also the same, and thus the target storage segment determined based on the hash values ​​is also the same.

[0094] Step 4: Acquire a read lock for the target storage segment;

[0095] In this step, after the target storage segment is determined, the corresponding read lock can be acquired based on each calling thread, which lays the foundation for subsequent read operations on the target storage segment based on the read lock.

[0096] Step 5: Perform a read operation based on the acquired read lock, and release the read lock after completion;

[0097] In this step, when performing a read operation based on the read lock, the request identifier carried by the calling thread can be compared with the request identifier corresponding to the historical call result stored in the target storage segment, so as to make the reading result more accurate.

[0098] Step 6, determine whether the read result is empty; if the read result is not empty, execute step 7, and if the read result is empty, execute step 8;

[0099] Step 7: Get the call result and return it to the upstream application server;

[0100] Step 8: Acquire the write lock of the target storage segment;

[0101] In this step, when each calling thread obtains the write lock later, it can specifically obtain the write lock one by one in a random manner or in a queue manner. That is, only one calling thread can obtain the write lock of the target storage segment at a time.

[0102] Step 9: Perform a read operation based on the acquired write lock;

[0103] In this step, after a certain calling thread obtains the write lock, it is impossible to determine whether the calling thread that obtains the write lock is the first thread to obtain the write lock among many calling threads. Therefore, in order to avoid repeated calls to the downstream application server during concurrent calls, the target storage segment will be queried / read again based on the query key / request identifier. In this step, by querying / reading the target storage segment again, it is possible to avoid the problem of multiple threads obtaining and executing to step 6 and determining that the query result is empty during concurrent calls, and then repeatedly calling the downstream application server.

[0104] Step 10, determine whether the read result is empty; if it is determined that the read call result is not empty, execute step 11, and if it is determined that the read result is empty, execute step 12;

[0105] Step 11: Get the call result and return it to the upstream application server;

[0106] Step 12: Execute the downstream calling method and obtain the calling result;

[0107] Step 13, write the call result into the segment; delete the invalid key-value pairs when writing;

[0108] In this step, each storage segment maintains its own hash table, so that the hash table is convenient for writing or deleting the call result. Therefore, when inserting a key-value pair, that is, when the request identifier and the corresponding call result (or the hash value of the request identifier and the corresponding call result) are stored in the target storage segment in the form of a key-value pair, a certain pit position of the hash table will be located first, and then the linked list with the pit position as the first element will be traversed. During the traversal process, it will be judged whether the current key-value pair (wherein the key refers to the request identifier or the hash value corresponding to the request identifier, and the value specifically refers to the call result) is expired. The way to determine the expiration is to obtain the current timestamp, subtract the timestamp in the key to obtain the time difference; compare the time difference with the preset time threshold T; when the time difference is greater than the predetermined time threshold T, it is determined to be invalid. If it is invalid, the linked list element deletion operation is performed, that is, the key-value pair is deleted, and the traversal continues downward; otherwise, the next element is directly traversed.

[0109] In this step, by processing invalid key-value pairs when writing the call results, there is no need to start additional threads, no additional deletion operations are added, and the pressure of lock competition is reduced. Specifically, the invalid call results and the request identifiers corresponding to the call results are deleted.

[0110] Step 14: Release the write lock;

[0111] Step 15: Feedback the call result to the upstream application server.

[0112] In this embodiment, the target storage location only exposes a read method for each thread to call, and the parameters of the target storage location can be set according to actual needs, such as expiration time T, storage capacity Q, concurrency C, etc.

[0113] In this embodiment, before calling the downstream application server, each calling thread determines whether the target storage location stores historical calling results by searching the target storage location. Thus, if the target storage location stores historical calling results corresponding to the request identifier, the calling result can be directly obtained from the target storage location without calling the downstream application server again. This can reduce the load on the downstream application server and improve the rate of information acquisition.

[0114] Another embodiment of the present application provides an information acquisition device, such as Figure 6 As shown, including:

[0115] A creation module 1 is used to create a plurality of call threads for obtaining call results based on the target call request received from the upstream application server; each of the call threads carries a request identifier of the target call request;

[0116] Search module 2, used to search the target storage location based on the request identifier carried by the currently running calling thread and obtain the search result;

[0117] The acquisition module 3 is used to match the corresponding target acquisition method for the currently running calling thread based on the search result, so as to obtain the calling result corresponding to the currently running calling thread from the target storage location based on the currently running calling thread, or to call the downstream application server based on the currently running calling thread to obtain the calling result from the downstream application server.

[0118] The information acquisition device in this embodiment also includes a first determination module, which is used to: obtain the target request parameters and target calling method carried by each calling thread before searching for the target storage location based on the request identifier of the currently running calling thread; and determine the request identifier carried by each calling thread based at least on the target request parameters and the target calling method carried by each calling thread.

[0119] The information acquisition device in this embodiment further includes a division module and a configuration module, wherein the division module is used to pre-divide the target storage location into regions to obtain a plurality of storage segments; the configuration module is used to configure a corresponding read lock and a write lock for each of the storage segments;

[0120] The search module is specifically used to: based on the target read lock obtained by the currently running calling thread, search the target storage segment corresponding to the target read lock in the target storage location to find the call result corresponding to the request identifier, or fail to find the call result corresponding to the request identifier to obtain the search result.

[0121] The information acquisition device in this embodiment also includes a second determination module for determining the target read lock to be obtained by each of the calling threads; the second determination module is specifically used to: before searching for the target storage segment corresponding to the target read lock in the target storage location based on the target read lock obtained by the currently running calling thread, determine, based on the request identifier carried by each of the calling threads, the segment to be queried corresponding to each of the calling threads as the target storage segment; based on each of the target storage segments, determine the read lock corresponding to each of the target storage segments as the target read lock to be obtained, so that each of the calling threads obtains the corresponding target read lock.

[0122] Specifically, the acquisition module is specifically used to: when a call result corresponding to the request identifier is found, obtain the call result from the target storage segment corresponding to the request identifier based on the currently running call thread; when a call result corresponding to the request identifier is not found, call the downstream application server to obtain the call result from the downstream application server.

[0123] In this embodiment, the acquisition module is specifically used to: based on the currently running calling thread that acquires the write lock of the target storage segment, call the downstream application server to obtain the calling result from the downstream application server.

[0124] The information acquisition device in this embodiment further includes a query module, which is used to search the target storage segment based on the currently running calling thread that has acquired the write lock of the target storage segment before calling the downstream application server to obtain the call result from the downstream application server, and determine whether the call result corresponding to the request identifier carried by the currently running calling thread is stored. The acquisition module is specifically used to: if the call result corresponding to the request identifier is not found, call the downstream application server based on the currently running calling thread that has acquired the write lock of the target storage segment to obtain the call result from the downstream application server.

[0125] The information acquisition device in this embodiment also includes a storage module, which is used to, after calling the downstream application server based on the currently running calling thread that has obtained the write lock of the target storage segment to obtain the call result from the downstream application server, store the acquired call result and the mapping relationship between the call result and the request identifier in the target storage segment based on the write lock obtained by the currently running calling thread.

[0126] The information acquisition device in this embodiment also includes a deletion module, which is used to obtain a current timestamp based on the request identifier of the currently running calling thread before storing the acquired call result and the mapping relationship between the call result and the request identifier in the target storage segment based on the write lock acquired by the currently running calling thread; obtain the historical timestamps of each call result stored in the target storage segment; based on the current timestamp and each historical timestamp, determine the validity of each call result stored in the target storage segment; and delete the call result when it is determined that the call result is invalid.

[0127] In this embodiment, before calling the downstream application server, the target storage location is searched to determine whether the target storage location stores historical call results. Therefore, if the target storage location stores historical call results corresponding to the request identifier, the call results can be directly obtained from the target storage location without calling the downstream application server again. This can reduce the load on the downstream application server and increase the rate of information acquisition.

[0128] The above embodiments are only exemplary embodiments of the present application and are not intended to limit the present application. The protection scope of the present application is defined by the claims. Those skilled in the art may make various modifications or equivalent substitutions to the present application within the essence and protection scope of the present application, and such modifications or equivalent substitutions shall also be deemed to fall within the protection scope of the present application.

Claims

1. A method for obtaining information, characterized in that: include: Based on the target call request received from the upstream application server, create a number of call threads for obtaining the call results; Each of the calling threads carries a request identifier of the target calling request; Searching for a target storage segment of a target storage location based on a request identifier carried by a currently running calling thread to obtain a search result; The request identifier is determined based on the target request parameter of the current calling thread and the target calling method of the current calling thread; When a call result corresponding to the request identifier is found, acquiring the call result corresponding to the currently running call thread from the target storage segment of the target storage location based on the currently running call thread; In the case where no call result corresponding to the request identifier is found, calling a downstream application server based on the currently running call thread that has acquired the write lock of the target storage segment, so as to obtain the call result from the downstream application server; The method further comprises: Divide the target storage location into regions in advance to obtain a plurality of storage sections; A corresponding write lock is configured for each of the storage segments.

2. The method according to claim 1, characterized in that Before searching the target storage location based on the request identifier carried by the currently running calling thread, the method further includes: Get the target request parameters and target calling method carried by each calling thread; The request identifier carried by each calling thread is determined based at least on the target request parameter carried by each calling thread and the target calling method.

3. The method according to claim 1, characterized in that The method further comprises: Configuring a corresponding read lock for each of the storage segments; The step of searching the target storage location based on the request identifier carried by the currently running calling thread to obtain the search result specifically includes: Based on the target read lock acquired by the currently running calling thread, the target storage segment corresponding to the target read lock in the target storage location is searched to find the calling result corresponding to the request identifier, or if the calling result corresponding to the request identifier is not found, the searching result is obtained.

4. The method according to claim 3, characterized in that Before searching the target storage segment corresponding to the target read lock in the target storage location based on the target read lock acquired by the currently running calling thread, the method further includes: determining the target read lock to be acquired by each calling thread, specifically including: Based on the request identifier carried by each calling thread, determining the to-be-queried segment corresponding to each calling thread as the target storage segment; Based on each of the target storage segments, a read lock corresponding to each of the target storage segments is determined as a target read lock to be acquired, so that each of the calling threads acquires the corresponding target read lock.

5. The method according to claim 1, characterized in that In the case where the call result corresponding to the request identifier is found, obtaining the call result corresponding to the currently running call thread from the target storage segment of the target storage location based on the currently running call thread specifically includes: When the calling result corresponding to the request identifier is found, the calling result is obtained from the target storage segment corresponding to the request identifier based on the currently running calling thread.

6. The method according to claim 1, characterized in that Before calling the downstream application server to obtain the calling result from the downstream application server, the method further includes: Based on the currently running calling thread that has acquired the write lock of the target storage segment, searching the target storage segment to determine whether a calling result corresponding to the request identifier carried by the currently running calling thread is stored; In the case that the calling result corresponding to the request identifier is not found, based on the currently running calling thread that has acquired the write lock of the target storage segment, the downstream application server is called to obtain the calling result from the downstream application server.

7. The method according to claim 1, characterized in that After calling a downstream application server based on the currently running calling thread that acquires the write lock of the target storage segment to obtain a calling result from the downstream application server, the method further includes: Based on the write lock acquired by the currently running calling thread, the acquired calling result and the mapping relationship between the calling result and the request identifier are stored in the target storage segment.

8. The method according to claim 7, characterized in that Before storing the acquired call result and the mapping relationship between the call result and the request identifier in the target storage segment based on the write lock acquired by the currently running call thread, the method further includes: Get the current timestamp based on the request identifier of the currently running calling thread; Obtaining a historical timestamp of each call result stored in the target storage segment; Based on the current timestamp and each of the historical timestamps, determining the validity of each of the call results stored in the target storage segment; When it is determined that the calling result is invalid, the calling result is deleted.

9. An information acquisition device, characterized in that: include: A creation module is used to create a number of call threads for obtaining call results based on the target call request received from the upstream application server; Each of the calling threads carries a request identifier of the target calling request; A search module, used to search for a target storage segment of a target storage location based on a request identifier carried by a currently running calling thread, and obtain a search result; The request identifier is determined based on the target request parameter of the current calling thread and the target calling method of the current calling thread; an acquisition module, configured to acquire, when a call result corresponding to the request identifier is found, the call result corresponding to the currently running call thread from the target storage location based on the currently running call thread; In the case where no call result corresponding to the request identifier is found, calling a downstream application server based on the currently running call thread that has acquired the write lock of the target storage segment, so as to obtain the call result from the downstream application server; The information acquisition device also includes a division module and a configuration module; The partitioning module is used to: pre-divide the target storage location into regions to obtain a plurality of storage sections; The configuration module is used to configure a corresponding write lock for each of the storage segments.

10. The information acquisition device according to claim 9, characterized in that: It also includes a first determination module, which is used to: before searching for the target storage location based on the request identifier of the currently running calling thread, obtain the target request parameters and the target calling method carried by each calling thread; The request identifier carried by each calling thread is determined based at least on the target request parameter carried by each calling thread and the target calling method.

11. The information acquisition device according to claim 9, characterized in that: The configuration module is also used to: configure a corresponding read lock for each storage segment; The search module is specifically used to: based on the target read lock obtained by the currently running calling thread, search the target storage segment corresponding to the target read lock in the target storage location to find the call result corresponding to the request identifier, or fail to find the call result corresponding to the request identifier to obtain the search result.

12. The information acquisition device according to claim 11, characterized in that: Also included is a second determination module for determining a target read lock to be acquired by each of the calling threads; The second determination module is specifically configured to: determine the to-be-queried segment corresponding to each calling thread as the target storage segment based on the request identifier carried by each calling thread before searching the target storage segment corresponding to the target read lock in the target storage location based on the target read lock acquired by the currently running calling thread; Based on each of the target storage segments, a read lock corresponding to each of the target storage segments is determined as a target read lock to be acquired, so that each of the calling threads acquires the corresponding target read lock.

13. The information acquisition device according to claim 9, characterized in that: The acquisition module is specifically configured to: when a call result corresponding to the request identifier is found, acquire the call result from a target storage segment corresponding to the request identifier based on the currently running call thread.

14. The information acquisition device according to claim 9, characterized in that: The system further includes a query module, which is used to: before calling a downstream application server to obtain a call result from the downstream application server, based on the currently running call thread that has acquired a write lock of the target storage segment, search the target storage segment to determine whether a call result corresponding to the request identifier carried by the currently running call thread is stored; The acquisition module is specifically used to: when no call result corresponding to the request identifier is found, based on the currently running call thread that acquires the write lock of the target storage segment, call the downstream application server to obtain the call result from the downstream application server.

15. The information acquisition device according to claim 9, characterized in that: It also includes a storage module, which is used to, after the currently running calling thread obtains the write lock of the target storage segment, calls the downstream application server to obtain the call result from the downstream application server, and then stores the obtained call result and the mapping relationship between the call result and the request identifier in the target storage segment based on the write lock obtained by the currently running calling thread.

16. The information acquisition device according to claim 14, characterized in that: It also includes a deletion module, which is used to obtain a current timestamp based on the request identifier of the currently running calling thread before storing the obtained calling result and the mapping relationship between the calling result and the request identifier in the target storage segment based on the write lock obtained by the currently running calling thread; Obtaining a historical timestamp of each call result stored in the target storage segment; Based on the current timestamp and each of the historical timestamps, determining the validity of each of the call results stored in the target storage segment; When it is determined that the calling result is invalid, the calling result is deleted.

Images