Caching method applied to high-concurrency requests

Abstract

The invention discloses a caching method applied to high-concurrency requests, which comprises the following steps: 1) when a distribution platform service is started, reading data from a source database (Redis) into a 2Q cache in advance; 2) when the management end service modifies the data, while updating the data to a source database (Redis), pushing a copy of data to the RabbitMQ; 3) the distribution platform service subscribes to the RabbitMQ service, and when the data is updated, the corresponding data information in the 2Q cache is updated according to the data pushed by the RabbitMQ; 4) when a client initiates a large number of concurrent requests and requests to a distribution platform service, firstly judging whether the requests hit the 2Q cache, if so, executing the step 5), and if not, executing the step 6); (5) judging whether the 2Q cache is invalid, if so, executing the step (6), and if not, returning data to the client; and 6) the server side organizes and suppresses the request, and the organized and suppressed request is subjected to data acquisition in a source database (Redis). According to the method, service paralysis caused by high-concurrency requests can be effectively reduced, and meanwhile, the hardware cost caused by cache is reduced.

Description

Technical Field

[0001] The present invention relates to the field of computer application technology, and in particular to a cache method applied to high-concurrency requests. Background Art

[0002] In the process of computer software development, especially under high concurrent requests, a good caching solution is crucial, which can significantly improve system performance and user experience.

[0003] However, in the actual development process, even if the cache is added, due to the limitations of the cache hardware configuration, the inability to dynamically expand in time, the source database (Redis) service interruption, the request source database (Redis) timeout, etc., in the case of high concurrent requests, the service will be paralyzed, and users will not be able to access the software, which seriously affects the user experience. From another perspective, even if the request does not time out and the dynamic expansion is timely, the dynamic expansion will greatly increase the hardware cost of the cache. Summary of the invention

[0004] In view of the above problems, the present invention provides a caching method applied to high-concurrency requests, which can effectively improve the availability of services, greatly reduce service paralysis caused by high-concurrency requests, and at the same time reduce the hardware cost caused by caching.

[0005] In order to achieve the above technical objectives, the technical solution adopted by the present invention is: a caching method applied to high-concurrency requests, comprising the following steps:

[0006] Step 1): When the distribution platform service is started, data is read from the source database (Redis) into the 2Q cache in advance;

[0007] Step 2): When the management service changes the data, it updates the data to the source database (Redis) and pushes a copy of the data to RabbitMQ;

[0008] Step 3): The distribution platform service subscribes to the RabbitMQ service. When the data is updated, the corresponding data information in the 2Q (Two Queues) cache is updated according to the data pushed by RabbitMQ;

[0009] Step 4): When the client initiates a large number of concurrent requests to the distribution platform service, first determine whether the request hits the 2Q cache. If so, execute step 5), if not, execute step 6);

[0010] Step 5): Determine whether the 2Q cache is invalid. If so, execute step 6. If not, return the data to the client.

[0011] Step 6): The server organizes and suppresses the request, and obtains data from the source database (Redis) after the request is organized and suppressed.

[0012] As a possible implementation method, further, in step 6), the server organizes and suppresses the request, and the organized and suppressed request is used to obtain data from the source database (Redis). The specific steps are as follows:

[0013] When the request parameters of multiple requests are the same, only one request goes to the source database (Redis) to obtain data, and the other requests with the same parameters wait in place;

[0014] After the first request data is acquired, the acquired data is assigned to other requests with the same parameters, and the acquired data is updated to the 2Q cache;

[0015] Finally, the request with the same parameters returns the acquired data to the client.

[0016] As a possible implementation, further, step 6) also includes:

[0017] If the request to the source database (Redis) times out or the connection to the source database (Redis) is disconnected, the invalid cache data hit in 2Q is directly returned to the client.

[0018] As a preferred implementation, preferably, the cache method applied to high concurrent requests further includes step 7): the 2Q cache periodically cleans up the invalid cache.

[0019] Based on the above, the present invention provides a computer device, the computer device comprising:

[0020] at least one processor, and

[0021] A memory and a communication interface communicatively connected to the at least one processor;

[0022] The memory stores instructions that can be executed by the at least one processor, and the at least one processor executes the instructions stored in the memory and uses the communication interface to perform the above-mentioned cache method applied to high-concurrency requests.

[0023] The present invention also provides a computer-readable storage medium, wherein the storage medium stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by a processor to implement the above-mentioned caching method applied to high-concurrency requests.

[0024] By adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art:

[0025] 1) The present invention designs a node for suppressing requests. This node allows a large number of concurrent requests with the same request parameters. If the 2Q cache does not hit or the 2Q cache is invalid, only one request will enter the source database (Redis) to obtain data, and other requests will wait for this request to obtain data and then assign values ​​and return. This operation will greatly reduce the pressure on the source database (Redis), so that the hardware environment where the source database (Redis) is located does not require a very high configuration, so that the entire service can be guaranteed to operate normally under high concurrent requests, and the hardware configuration cost of the server where the source database (Redis) is located is greatly reduced.

[0026] 2) The present invention also performs downgrade processing when the request to the source database (Redis) times out or the connection with the source database (Redis) is disconnected, and directly returns the invalid cache data in the 2Q cache. If the invalid cache in the 2Q cache is cleared, an empty object is directly returned to prevent the service from being paralyzed due to the above situation.

[0027] 3) The present invention adopts 2Q (Two Queues) cache as the distribution platform service data storage library, which regularly cleans up the invalid cache to release the occupied memory space, ensuring that the system has more available resources to process new requests and improve memory utilization.

[0028] 4) The present invention stores data in the 2Q cache in advance before the service is started. The client requests to obtain data from the source database (Redis) only when the 2Q cache fails. In most cases, the client interacts with the 2Q cache, which greatly improves the response speed of the request. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0030] Figure 1 A simplified flowchart of a caching method for high-concurrency requests provided by an embodiment of the present invention;

[0031] Figure 2 A schematic diagram of a module of a computer device provided by an embodiment of the present invention;

[0032] Figure 3 It is a schematic diagram of a computer-readable storage medium provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0033] The present invention will be further described in detail below in conjunction with the accompanying drawings and examples. It is particularly noted that the following examples are only used to illustrate the present invention, but are not intended to limit the scope of the present invention. Similarly, the following examples are only partial embodiments of the present invention rather than all embodiments, and all other embodiments obtained by those of ordinary skill in the art without creative work are within the scope of protection of the present invention.

[0034] Embodiment 1

[0035] See attached Figure 1 As shown, this embodiment provides a caching method applied to high concurrent requests, comprising the following steps:

[0036] Step 1): When the distribution platform service starts, read the data from the source database (Redis) into the 2Q (TwoQueues) cache in advance;

[0037] Step 2): When the management service changes the data, it updates the data to the source database (Redis) and pushes a copy of the data to RabbitMQ;

[0038] Step 3): The distribution platform service subscribes to the RabbitMQ service. When the data is updated, the corresponding data information in the 2Q (Two Queues) cache is updated according to the data pushed by RabbitMQ;

[0039] Step 4): When the client initiates a large number of concurrent requests to the distribution platform service, first determine whether the request hits the 2Q cache. If it hits the 2Q cache, execute step 5); if it does not hit the 2Q cache, execute step 6);

[0040] Step 5): Determine whether the 2Q cache is invalid. If the 2Q cache is invalid, execute step 6). If the 2Q cache is not invalid, return the data to the client.

[0041] Step 6): The server organizes and suppresses the request, and then goes to the source database (Redis) to obtain data. Specifically, the steps include:

[0042] When the request parameters of multiple requests are the same, only one request goes to the source database (Redis) to obtain data, and the other requests with the same parameters wait in place;

[0043] After the first request data is acquired, the data is assigned to other requests with the same parameters. After the acquired data is updated to the 2Q cache, the requests with the same parameters return the acquired data to the client. This design greatly reduces the pressure on the source database (Redis).

[0044] If the request to the source database (Redis) times out or is disconnected from the source database (Redis), the invalid cache data hit in 2Q will be directly returned to the client to avoid service paralysis.

[0045] Step 7): 2Q cache regularly cleans up invalid caches to release occupied memory space and ensure that the system has more available resources to process new requests.

[0046] Embodiment 2

[0047] See attached Figure 2 As shown, based on the same inventive concept, a computer device is provided in an embodiment of the present invention, including at least one processor, and a memory and a communication interface communicatively connected to the at least one processor. FIG4 shows a processor as an example.

[0048] The memory stores instructions that can be executed by the at least one processor, and the at least one processor executes the instructions stored in the memory and uses the communication interface to perform the caching method for high-concurrency requests as described in Example 1.

[0049] Embodiment 3

[0050] See attached Figure 3 As shown, based on the same inventive concept, an embodiment of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer instructions. When the computer instructions are executed on a computer, the computer executes the caching method for high-concurrency requests as described in Embodiment 1.

[0051] In the specific implementation process, computer-readable storage media include: Universal Serial Bus flash drive (USB), mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, and other storage media that can store program codes.

[0052] The device embodiments described above are merely illustrative, wherein the units / modules described as separate components may or may not be physically separated, and the components displayed as units / modules may or may not be physical units / modules, i.e., they may be located in one place, or they may be distributed over multiple network units / modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Those of ordinary skill in the art may understand and implement it without creative effort.

[0053] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0054] The above descriptions are only some embodiments of the present invention, and are not intended to limit the protection scope of the present invention. Any equivalent device or equivalent process transformation made using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A caching method for high concurrent requests, characterized in that: The steps include: Step 1): When the distribution platform service is started, data is read from the source database (Redis) into the 2Q cache in advance; Step 2): When the management service changes the data, it updates the data to the source database (Redis) and pushes a copy of the data to RabbitMQ; Step 3): The distribution platform service subscribes to the RabbitMQ service. When the data is updated, the corresponding data information in the 2Q cache is updated according to the data pushed by RabbitMQ; Step 4): When the client initiates a large number of concurrent requests to the distribution platform service, first determine whether the request hits the 2Q cache. If so, execute step 5), if not, execute step 6); Step 5): Determine whether the 2Q cache is invalid. If so, execute step 6. If not, return the data to the client. Step 6): The server organizes and suppresses the request, and obtains data from the source database (Redis) after the request is organized and suppressed.

2. The caching method for high concurrent requests according to claim 1, characterized in that: In step 6), the server organizes and suppresses the request, and obtains data from the source database (Redis) after the request is organized and suppressed. The specific steps are as follows: When the request parameters of multiple requests are the same, only one request goes to the source database (Redis) to obtain data, and the other requests with the same parameters wait in place; After the first request data is acquired, the acquired data is assigned to other requests with the same parameters, and the acquired data is updated to the 2Q cache; Finally, the request with the same parameters returns the acquired data to the client.

3. The caching method for high concurrent requests according to claim 1, characterized in that: Step 6) also includes: If the request to the source database (Redis) times out or the connection to the source database (Redis) is disconnected, the invalid cache data hit in 2Q is directly returned to the client.

4. The caching method for high concurrent requests according to claim 1, characterized in that: The step 7) is also included: the 2Q cache periodically cleans up the invalid cache.

5. A computer device, characterized in that: The computer device comprises: at least one processor, and A memory and a communication interface communicatively connected to the at least one processor; The memory stores instructions executable by the at least one processor, and the at least one processor executes the caching method for high-concurrency requests according to any one of claims 1 to 4 by using the communication interface by executing the instructions stored in the memory.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the cache method for high-concurrency requests according to any one of claims 1 to 4 is implemented.

Images