CN108073414B - Implementation method for merging multithreading concurrent requests and submitting and distributing results in batches based on Jedis - Google Patents
Implementation method for merging multithreading concurrent requests and submitting and distributing results in batches based on Jedis Download PDFInfo
- Publication number
- CN108073414B CN108073414B CN201611029743.7A CN201611029743A CN108073414B CN 108073414 B CN108073414 B CN 108073414B CN 201611029743 A CN201611029743 A CN 201611029743A CN 108073414 B CN108073414 B CN 108073414B
- Authority
- CN
- China
- Prior art keywords
- request
- pipelinewrapper
- batch
- requests
- lock
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
- G06F9/3885—Concurrent instruction execution, e.g. pipeline, look ahead using a plurality of independent parallel functional units
Abstract
The invention provides a realization method for merging multithreading concurrent requests and submitting in batches and distributing results based on Jedis. The invention combines a plurality of Redis requests in the same process into the same Pipeline for batch submission and then distributes the returned result to each original request. Two different request modes of synchronous requests and asynchronous requests are provided, and different submission strategies can be realized according to various configurations. In addition, the invention also provides an active submission interface of the client, and each request can trigger batch submission in real time according to the business requirement. Finally, through testing, the technical scheme is adopted to realize the method, and the response performance of the concurrent requests of the client can be greatly improved.
Description
Technical Field
The invention belongs to the technical field of databases, and particularly relates to a realization method for merging multithreading concurrent requests and submitting in batches and distributing results based on Jedis.
Background
In the single-process multi-thread application, when a Redis server is accessed through the Jedis server, each thread can respectively hold a separate connection and independently initiate a request through the respectively held connection to wait for a response result.
The other mode can also be adopted, the Pipeline mode is adopted, the Pipeline is suitable for batch processing, and the Pipeline can be used when a large number of operations need to be executed at one time. Jedis has provided a Pipeline mode, the mode is asynchronous when a client sends a request, the client can return to send a subsequent request without waiting after sending the request, the client executes a submitting operation after sending all the requests, and then obtains results of all the previous requests at one time. In this way, the throughput of the clients can be asynchronously improved, but because a plurality of clients submit requests concurrently, each client can execute its own submission request, and because the server can only process the request of one client at the same time, the clients can wait for each other when submitting requests, which also affects the overall performance of the application.
Disclosure of Invention
The present invention is directed to solving such problems similar to those described above to improve the overall performance of the application. The general idea of the invention is to collect the multi-thread concurrent requests in the Jedis process, execute asynchronous requests through the original single connection Pipeline at the bottom layer, uniformly submit the requests, then obtain the results of the requests once again, and finally distribute the results of the requests to all calling threads.
The purpose of the invention is realized by the following technical scheme.
The invention provides a realization method for merging multithread concurrent requests and submitting in batch and distributing results based on Jedis, wherein the package of the Jedis comprises the following modules: the system comprises a basic operation module, a monitor module and a wake-up device module; wherein, PipelineWrapper is the main class of the basic operation module, TimeMonitor is the main class of the listener module, and Notifier is the main class of the awakener module;
the method comprises the following steps:
a client thread initiates a request to a PipelineWrapper, wherein the request comprises one of a synchronous request op (), an asynchronous request opAsync () or a batch submission sync ();
the request first requests a global exclusive lock from the PipelineWrapper;
after obtaining the lock, initiating one of an op (), an opsync () request or a sync () request to the underlying Pipeline;
the op (), the opAsync () request executes +1 operation on the operation count attribute opCount of the PipelineWrapper, and once the opCount is greater than maxOpCount, the execution of batch submission sync () is triggered;
releasing the global exclusive lock;
and obtaining and returning a result.
For a synchronization request op (), each execution adds a Semaphore (Semaphore) to the synchronization operation report queue (respQueue) indicating whether the request result is readable or not, which Semaphore is woken up by Notifier when batch commit sync () is executed. The TimerMonitor periodically executes the pipelinewrrapper batch commit method sync () according to a set interval time, and triggers execution of bottom-layer batch commit.
When the request is a synchronous request op (), the implementation method for merging the multithreading concurrent requests and submitting in batches and distributing the result based on Jedis specifically comprises the following steps:
a client thread initiates a synchronous request op () call to the PipelineWrapper;
obtaining an exclusive lock of the PipelineWrapper object attribute lock;
initiating a corresponding request to the underlying pipeline, wherein the request is executed in an asynchronous mode;
executing +1 operation on the operation counter opCount;
executing reporopOp () operation of the PipelineWrapper, pushing a Semaphore Semaphore created by' new Semaphore (0) to a synchronous operation waiting queue respQueue, and finally returning the Semaphore;
if at this time opCount > maxOpCount, i.e., the operation count has exceeded the set maximum operand, then execution of batch commit sync () is triggered;
releasing the exclusive lock of the property lock of the PipelineWrapper object and continuously executing other requests;
executing a wait operation acquire () on the created Semaphore until being awakened by a Notifier;
and calling a get method on a Response hook object returned by the underlying pipeline to obtain a result and returning the result.
When the request is an asynchronous request opAsync (), the implementation method for merging the multithreading concurrent requests and submitting batches and distributing the results based on Jedis specifically comprises the following steps:
a client thread initiates an asynchronous request opAsync () call to the PipelineWrapper;
obtaining an exclusive lock of the PipelineWrapper object attribute lock;
initiating a corresponding request to the underlying pipeline, wherein the request is executed in an asynchronous mode;
executing +1 operation on the operation counter opCount;
if at this time the attribute trigerCommitInAsync of PipelineWrapper is true and opCount > maxOpCount, and the operation count has exceeded the set maximum operand, then execution of batch commit sync () is triggered;
releasing an exclusive lock of the PipelineWrapper object attribute lock; continue execution of other requests
The encapsulated Resp for Response is returned directly.
When the request is batch commit sync (), the implementation method for merging the multithreading concurrent requests and distributing the results based on Jedis specifically comprises the following steps:
a client thread initiates a batch submission sync () call to a PipelineWrapper;
obtaining an exclusive lock of the PipelineWrapper object attribute lock;
judging whether the opCount >0 is established or not, and continuing to establish; otherwise, returning directly;
initiating a batch submission request to pipeline of the bottom layer, and waiting for the bottom layer to execute a return;
executing countDown () on the object attribute latch to open the asynchronous request latch, so that the asynchronous request thread obtains a result, and creating a new unopened asynchronous request latch to be assigned to the object attribute latch for a subsequent asynchronous request to use;
if the synchronous request queue respQueue is not empty, packaging the synchronous request queue into a new Notifier, and submitting the Notifier to a thread pool ExecutorService for executing a wakeup task;
setting opCount to 0;
releasing the exclusive lock of the property lock of the PipelineWrapper object and continuously executing other requests;
and calling and returning.
The invention has the beneficial effects that:
1. the concurrent requests of multiple threads in the process are combined and submitted in batch, so that the consumption of connection resources can be reduced, the request submission times when each thread submits the requests independently are reduced, the network throughput is improved to the maximum extent, and the mutual waiting among different requests can be eliminated.
2. A synchronous method, an asynchronous method and an active submission method are provided, and the request mode can be freely determined according to the application service.
3. The method and the device can automatically execute submission according to the set maximum request number and the maximum submission period, ensure the timely completion of the operation and ensure that the number of threads waiting for the client is not excessive.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
FIG. 1 is a diagram of package module classes for Jedis according to an embodiment of the present invention;
FIG. 2 is a schematic diagram of a package module interaction of Jedis according to an embodiment of the present invention;
FIG. 3 is a synchronization request timing diagram according to an embodiment of the present invention;
FIG. 4 is a synchronization request flow diagram according to an embodiment of the present invention;
FIG. 5 is a timing diagram of an asynchronous request according to an embodiment of the invention;
FIG. 6 is a flow diagram of an asynchronous request according to an embodiment of the invention;
FIG. 7 is a flow diagram of obtaining results from Resp in an asynchronous request according to an embodiment of the present invention;
FIG. 8 is a batch commit timing diagram according to an embodiment of the present invention;
FIG. 9 is a flow diagram of batch commit, according to an embodiment of the present invention.
Detailed Description
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
In the scheme of the invention, the merging of the multi-thread concurrent requests and batch submission and result distribution are realized by making a package based on Jedis, and the package comprises the following modules: the basic operation module, the listener module, and the awakener module are described below in detail, and a class diagram and a relationship related to each module are shown in fig. 1.
PipelineWrapper: it is the main class of basic operation module, and provides various synchronous and asynchronous methods and batch submission method. It encapsulates Jedis's asynchronous request class Pipeline inside. Since there are many synchronous and asynchronous methods, the description of the present invention uses op () to represent synchronous type methods and opAsync () to represent asynchronous type methods. Because the Pipeline of the Jedis internally packaged does not support concurrent execution, all requests need to be locked first, and the lock is released after execution is finished.
The Pipeline wrapper (Pipeline wrapper, inmaxOpCount, long period) method is a construction method, and parameters comprise: the construction method uses the three parameters to respectively assign corresponding attributes in the Jedis system to the Jedis system. Meanwhile, a resident thread is created and started to run TimerMoniotr by using the parameters pipeline and period, and the TimerMoniotr can be referred to as the following description.
The technical scheme of the invention provides a plurality of synchronous request methods, asynchronous request methods and batch submission methods for a client, wherein all synchronous request methods are described and represented by op (), all asynchronous requesters are described and represented by opAsync (), and the batch submission method is described and represented by sync ().
The op () method: the synchronous request method provides the calling of the synchronous mode for the outside, and the client synchronously returns the result when calling the method, which is characterized in that the client needs to wait. once op () is executed, a java Semaphore object (new Semaphore (0)) is added to the synchronous operation report queue (respQueue queue), and the method executes a request on the Semaphore, waiting for batch commit and then awakening. The detailed implementation logic and flow of the method can be seen in the synchronization request timing chart of fig. 3.
opAsync () method: the method of asynchronous request provides the calling of asynchronous mode to the outside, when the client terminal calls the method of this type, the client terminal returns a hook object Resp directly, without waiting for the real result. Get () methods may be called on Resp objects to get when a result needs to be read. The detailed implementation logic and flow of the method can be seen in the asynchronous request timing diagram of fig. 5.
sync () method: and the batch submitting method executes the batch submitting request and is responsible for distributing the execution result to each client request thread. The detailed implementation logic and flow of the method can be seen in the batch submission timing chart of fig. 8.
Resp: the class is a hook class of results returned by the asynchronous request opAsync (), and the client thread can obtain real results based on the hook class at any time. However, if the batch commit method sync () has not been executed, the underlying result has not been returned, and the client thread will be suspended when the result is obtained from Resp until the underlying result is returned.
The class comprises three heavy load construction methods which are respectively used for different scenes:
resp (countDown L atch wrapper, Response <.
Resp () method: construction method, which is generally used in scenarios where no value or only null needs to be returned
Resp (T value) method: constructing a method, which is generally used in a scene that only needs to return value, such as: it is not necessary to know the specific return value, but only to know whether the program completes smoothly, if the execution completion returns true, otherwise returns false.
get () method: the method is used for obtaining an execution result from Resp, if the Resp object attribute hasGet is false (namely 1 st execution), an await () method is executed on an object attribute latch, the method is awakened when a batch submission result is returned, if the result is awakened, the await () method is not suspended, the subsequent logic is directly skipped, the get () method is executed on the attribute redisResp to obtain a real result, the hasGet is set to true, and finally the result is assigned to the value attribute; if the hasGet attribute is true (i.e., has already been executed) at execution time, then value is returned directly.
Timer monitor: the method is a main class of a listener module, realizes a Java runtime interface, is mainly used for periodically monitoring PipelineWrapper according to set interval time, and can execute a batch submission method sync () of the PipelineWrapper after each period is finished so as to ensure the periodic execution of batch submission operation.
TimerMonitor (PipelineWrapperpip, long period) method: the method is a construction method, and the transmitted parameters are assigned to the corresponding attributes.
run () method: in the method, while (true) infinite loop is used, dormancy is performed for corresponding time according to attribute period, and then the batch submission method sync () of attribute pip is executed to trigger and request batch submission.
Notifier: the awakener module is a main class of the awakener module, realizes a Java Runnable interface so as to be used as a task to be executed in a thread pool, and is used for awakening a client thread which waits synchronously after the connection execution of a bottom layer is finished and a batch submission is carried out and a result is returned, and further returning respective results.
Notifier (Queue < Semaphore > q) method: the method is a construction method, and the incoming parameter q is assigned to the corresponding attribute. The elements in the parameter queue are semaphores in java, which come from the synchronization type method op () of PipelineWrapper, each Semaphore represents a synchronization request, and a client request thread is on the Semaphore to wait on suspension.
run () method: the method acquires Semaphore elements one by one from a queue respQueue and executes a release () method on the Semaphore elements, namely a wakeup method. When there is no element in the respQueue, the respQueue is destroyed, and the corresponding Notifier object can be also garbage-recovered.
ExecutorService: the class is a thread pool in Java and is used for executing Notifier tasks.
According to the embodiment of the invention, a realization method for merging multithread concurrent requests and submitting in batch and distributing results based on Jedis is provided, and as mentioned above, the package of Jedis comprises the following steps: a basic operation module (pipeline wrapper module), a listener module (TimerMonitor), and a wake-up module (Notifier), wherein the interaction between the modules is as shown in fig. 2, and the method includes:
firstly, a client thread initiates a request to the PipelineWrapper, each thread can initiate any one of three types of requests, i.e. op (), opAsync () or sync (), at the same time, and no matter which operation is performed, a lock is required to be requested to the PipelineWrapper first, after the lock is obtained, the request is initiated to the Pipeline at the bottom layer, and then the lock is released.
Regardless of op () or opAsync (), each request will perform a +1 operation on the operation count attribute opCount of the PipelineWrapper, and once opCount > maxOpCount, it will trigger the execution of the batch commit method sync () (for opAsync (), it is also necessary to determine whether trigerCommitInAsync sync is true). While possibly triggering the execution of a Notifier wakeup task.
For the op () method, each execution adds a Semaphore (Semaphore) to respQueue, representing whether the result of the request is already readable, which is awakened by Notifier when the batch commit method sync () is executed.
The TimerMonitor will periodically perform the PipelineWrapper batch commit method sync (), with a period of periodTime milliseconds. But not necessarily each time sync () is really valid because if opCount is 0, it means there is no request, in which case the bottom layer will not really perform commit.
The implementation (i.e., specific implementation) of the aforementioned synchronous request op (), asynchronous request opAsync () or batch commit sync () is described in detail below with reference to fig. 3 to 9.
The first implementation mode comprises the following steps:
the synchronization request timing is shown in fig. 3, the synchronization request flow is shown in fig. 4, and the synchronization request of the present invention specifically includes:
a client thread initiates a synchronous method op () call to the PipelineWrapper;
obtaining an exclusive lock of the PipelineWrapper object attribute lock;
initiating a corresponding request to the underlying pipeline, wherein the underlying request is executed in an asynchronous mode because the methods of the pipeline are all asynchronous methods, and the returned result is the hook Response of Jedis itself;
the +1 operation is performed on the operation counter opCount.
A reportOp () method is executed to report operation to a waiting queue, a Semaphore Semaphore is created by the method through newSemaphore (0), the Semaphore is pushed to a synchronous operation waiting queue respQueue, and finally the Semaphore is returned;
if at this time opCount > maxOpCount, i.e. the operation count has exceeded the set maximum operand, then the execution of the batch commit method sync () is triggered;
releasing the lock on the property lock of the PipelineWrapper object, and facilitating the continuous execution of other requests;
executing a waiting operation acquire () on the Semaphore created in the above step until being awakened by a Notifier;
and calling a get method on the Response object returned in the above step to obtain a result and returning the result.
The second embodiment:
the asynchronous request timing is shown in fig. 5, the asynchronous request flow is shown in fig. 6-7, and the asynchronous request of the present invention specifically includes:
a client thread initiates an asynchronous method opAsync () call to the PipelineWrapper;
obtaining an exclusive lock of the PipelineWrapper object attribute lock;
initiating a corresponding request to the underlying pipeline, wherein the underlying request is executed in an asynchronous mode because the methods of the pipeline are all asynchronous methods, and the returned result is the hook Response of Jedis itself;
the +1 operation is performed on the operation counter opCount.
If at this time trigercommit inasync ═ true and opCount > maxOpCount, i.e. an asynchronous operation is set that can trigger a batch commit, and the operation count has exceeded the set maximum operand, then execution of the batch commit method sync () is triggered;
releasing the lock on the property lock of the PipelineWrapper object, and facilitating the continuous execution of other requests;
the encapsulated Resp for Response is returned directly.
The "asynchronous request bolt" introduced when the "asynchronous request" is included in Resp, and the Response of the Pipeline asynchronous result hook object, which are used when Resp obtains the final result, are included in Resp, and the flow of obtaining the result from Resp is shown in fig. 7.
The third embodiment is as follows:
the batch submitting time sequence is shown in fig. 8, the batch submitting flow is shown in fig. 9, and the batch submitting method specifically includes:
a client thread initiates a batch submission method sync () call to a PipelineWrapper;
obtaining an exclusive lock of the PipelineWrapper object attribute lock;
judging whether the opCount >0 is established or not, and continuing to establish; otherwise, returning directly;
initiating a batch submission request to pipeline of the bottom layer, and waiting for the bottom layer to execute a return;
executing countDown () on the object attribute latch to open the asynchronous request latch, facilitating the asynchronous request thread to obtain the result, and creating a new unopened asynchronous request latch to assign to the object attribute latch for the subsequent asynchronous request to use;
if the synchronous request queue respQueue is not empty, packaging the synchronous request queue into a new Notifier, and submitting the Notifier to a thread pool ExecutorService for executing a wakeup task;
setting opCount to 0;
releasing the lock on the property lock of the PipelineWrapper object, and facilitating the continuous execution of other requests;
and calling and returning.
The invention combines a plurality of Redis requests in the same process into the same Pipeline for batch submission and then distributes the returned result to each original request. The method provides two different request modes of synchronous requests and asynchronous requests, can realize different submission strategies according to various configurations, can configure the maximum limit of batch submission, and can automatically submit requests as long as a condition is met in the maximum period of batch submission on the premise that at least 1 request is required. In addition, the invention also provides an active submission interface of the client, and each request can trigger batch submission in real time according to the business requirement. Finally, through testing, the technical scheme is adopted to realize the method, and the response performance of the concurrent requests of the client can be greatly improved.
The above description is only for the preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the present invention are included in the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the appended claims.
Claims (6)
1. A realization method for merging multithread concurrent requests to submit in batch and distribute results based on Jedis is characterized in that the package of the Jedis comprises the following modules: the system comprises a basic operation module, a monitor module and a wake-up device module; wherein, PipelineWrapper is the main class of the basic operation module, TimeMonitor is the main class of the listener module, and Notifier is the main class of the awakener module;
the method comprises the following steps:
a client thread initiates a request to a PipelineWrapper, wherein the request comprises one of a synchronous request op (), an asynchronous request opAsync () or a batch submission sync ();
the request first requests a global exclusive lock from the PipelineWrapper;
after obtaining the lock, initiating one of an op (), an opsync () request or a sync () request to the underlying Pipeline;
the op (), the opAsync () request executes +1 operation on the operation count attribute opCount of the PipelineWrapper, and once the opCount is greater than maxOpCount, the execution of batch submission sync () is triggered;
releasing the global exclusive lock;
and obtaining and returning a result.
2. The method as claimed in claim 1, wherein for a synchronization request op (), each execution adds a Semaphore (Semaphore) to the synchronization operation report queue, which Semaphore represents whether the result of the request is readable or not, and is awakened by Notifier when the sync () is committed in bulk.
3. The method as claimed in claim 1, wherein the TimerMonitor periodically executes the pipelinewrrapper batch commit method sync () at a set interval to trigger execution of the underlying batch commit.
4. The method of claim 1, wherein: when the request initiated by the client thread to the pipeline wrapper is a synchronous request op (), the implementation method for merging the multi-thread concurrent requests and submitting in batch and distributing the result based on Jedis specifically comprises the following steps:
a client thread initiates a synchronous request op () call to the PipelineWrapper;
obtaining an exclusive lock of the PipelineWrapper object attribute lock;
initiating a corresponding request to the underlying pipeline, wherein the request is executed in an asynchronous mode;
executing +1 operation on the operation counter opCount;
executing reporopOp () operation of the PipelineWrapper, pushing a Semaphore Semaphore created by' new Semaphore (0) to a synchronous operation waiting queue respQueue, and finally returning the Semaphore;
if at this time opCount > maxOpCount, i.e., the operation count has exceeded the set maximum operand, then execution of batch commit sync () is triggered;
releasing the exclusive lock of the property lock of the PipelineWrapper object and continuously executing other requests;
executing a wait operation acquire () on the created Semaphore until being awakened by a Notifier;
and calling a get method on a Response hook object returned by the underlying pipeline to obtain a result and returning the result.
5. The method of claim 1, wherein: when the request initiated by the client thread to the pipeline wrapper is an asynchronous request opAsync (), the implementation method for merging the multi-thread concurrent requests and submitting in batch and distributing the result based on Jedis specifically comprises the following steps:
a client thread initiates an asynchronous request opAsync () call to the PipelineWrapper;
obtaining an exclusive lock of the PipelineWrapper object attribute lock;
initiating a corresponding request to the underlying pipeline, wherein the request is executed in an asynchronous mode;
executing +1 operation on the operation counter opCount;
if at this time the attribute trigerCommitInAsync of PipelineWrapper is true and opCount > maxOpCount, and the operation count has exceeded the set maximum operand, then execution of batch commit sync () is triggered;
releasing the exclusive lock of the property lock of the PipelineWrapper object and continuously executing other requests;
the encapsulated Resp for Response is returned directly.
6. The method of claim 1, wherein: when the request initiated by the client thread to the pipeline wrapper is batch commit sync (), the implementation method for merging the multi-thread concurrent requests and performing batch commit and result distribution based on Jedis specifically comprises the following steps:
a client thread initiates a batch submission sync () call to a PipelineWrapper;
obtaining an exclusive lock of the PipelineWrapper object attribute lock;
judging whether the opCount >0 is established or not, and continuing to establish; otherwise, returning directly;
initiating a batch submission request to pipeline of the bottom layer, and waiting for the bottom layer to execute a return;
executing countDown () on the object attribute latch to open the asynchronous request latch, so that the asynchronous request thread obtains a result, and creating a new unopened asynchronous request latch to be assigned to the object attribute latch for a subsequent asynchronous request to use;
if the synchronous request queue respQueue is not empty, packaging the synchronous request queue into a new Notifier, and submitting the Notifier to a thread pool ExecutorService for executing a wakeup task;
setting opCount to 0;
releasing the exclusive lock of the property lock of the PipelineWrapper object and continuously executing other requests;
and calling and returning.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201611029743.7A CN108073414B (en) | 2016-11-15 | 2016-11-15 | Implementation method for merging multithreading concurrent requests and submitting and distributing results in batches based on Jedis |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201611029743.7A CN108073414B (en) | 2016-11-15 | 2016-11-15 | Implementation method for merging multithreading concurrent requests and submitting and distributing results in batches based on Jedis |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108073414A CN108073414A (en) | 2018-05-25 |
| CN108073414B true CN108073414B (en) | 2020-07-28 |
Family
ID=62160985
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201611029743.7A Active CN108073414B (en) | 2016-11-15 | 2016-11-15 | Implementation method for merging multithreading concurrent requests and submitting and distributing results in batches based on Jedis |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108073414B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110413594A (en) * | 2019-06-25 | 2019-11-05 | 苏州浪潮智能科技有限公司 | A kind of more example method for testing pressure of Redis and device |
| CN110519364A (en) * | 2019-08-23 | 2019-11-29 | 深圳前海环融联易信息科技服务有限公司 | A kind of method and its system of the high concurrent performance optimization based on jdk8 |
| CN110611746B (en) * | 2019-09-03 | 2021-06-29 | 深圳市云网万店电子商务有限公司 | Multi-camera synchronization method and distributed system |
| CN110572474B (en) * | 2019-09-26 | 2021-09-21 | 四川长虹电器股份有限公司 | Method for embedded terminal long-connection communication |
| CN113761433A (en) * | 2020-11-04 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | Service processing method and device |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5872947A (en) * | 1995-10-24 | 1999-02-16 | Advanced Micro Devices, Inc. | Instruction classification circuit configured to classify instructions into a plurality of instruction types prior to decoding said instructions |
| CN102880475A (en) * | 2012-10-23 | 2013-01-16 | 上海普元信息技术股份有限公司 | Real-time event handling system and method based on cloud computing in computer software system |
| CN105260376A (en) * | 2015-08-17 | 2016-01-20 | 北京京东尚科信息技术有限公司 | Method, equipment and system used for cluster node contraction and expansion |
-
2016
- 2016-11-15 CN CN201611029743.7A patent/CN108073414B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5872947A (en) * | 1995-10-24 | 1999-02-16 | Advanced Micro Devices, Inc. | Instruction classification circuit configured to classify instructions into a plurality of instruction types prior to decoding said instructions |
| CN102880475A (en) * | 2012-10-23 | 2013-01-16 | 上海普元信息技术股份有限公司 | Real-time event handling system and method based on cloud computing in computer software system |
| CN105260376A (en) * | 2015-08-17 | 2016-01-20 | 北京京东尚科信息技术有限公司 | Method, equipment and system used for cluster node contraction and expansion |
Non-Patent Citations (1)
| Title |
|---|
| 分布式内存缓存技术在数据处理平台中的研究与应用;崔解宾;《中国优秀硕士学位论文全文数据库（信息科技辑）》;20150815;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108073414A (en) | 2018-05-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108073414B (en) | Implementation method for merging multithreading concurrent requests and submitting and distributing results in batches based on Jedis | |
| CN100530107C (en) | Single process contents server device and method based on IO event notification mechanism | |
| US8381212B2 (en) | Dynamic allocation and partitioning of compute nodes in hierarchical job scheduling | |
| CN101452404B (en) | Task scheduling apparatus and method for embedded operating system | |
| CN102455933B (en) | Method for increasing multi-tasking efficiency through thread management | |
| CN105045658A (en) | Method for realizing dynamic dispatching distribution of task by multi-core embedded DSP (Data Structure Processor) | |
| CN110795254A (en) | Method for processing high-concurrency IO based on PHP | |
| JP2003518286A (en) | System and method for providing a pool of reusable threads for performing queued work items | |
| US9098359B2 (en) | Durable execution of long running applications | |
| WO2021000758A1 (en) | Robotic resource task cycle management and control method and apparatus | |
| CN103365718A (en) | Thread scheduling method, thread scheduling device and multi-core processor system | |
| WO2009113381A1 (en) | Multiprocessor system and method of sharing device among os in multiprocessor system | |
| CN105786603B (en) | Distributed high-concurrency service processing system and method | |
| CN107479981B (en) | Processing method and device for realizing synchronous call based on asynchronous call | |
| CN113535362B (en) | Distributed scheduling system architecture and micro-service workflow scheduling method | |
| US20080155546A1 (en) | Method of controlling thread access to a synchronization object | |
| CN115495262A (en) | Microkernel operating system and method for processing interprocess message | |
| JP4584935B2 (en) | Behavior model based multi-thread architecture | |
| CN112395062A (en) | Task processing method, device, equipment and computer readable storage medium | |
| CN112181689A (en) | Runtime system for efficiently scheduling GPU kernel under cloud | |
| TWI442323B (en) | Task scheduling and allocation for multi-core/many-core management framework and method thereof | |
| Kalkov et al. | Priority inheritance during remote procedure calls in real-time android using extended binder framework | |
| CN106095535B (en) | A kind of thread management system for supporting Data Stream Processing under multi-core platform | |
| US10713085B2 (en) | Asynchronous sequential processing execution | |
| CN109413489B (en) | Serial multi-thread bullet screen distribution method, device, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |