Shulou(Shulou.com)05/31 Report--

This article is about how redis can improve throughput through pipeline. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Case goal

This paper briefly introduces the mechanism of redis pipeline, and illustrates the effectiveness of pipeline in improving throughput with an example.

Case background

In the process of data push or event processing, there is often a data stream passing through multiple network elements in an application system.

However, in some services, data operations are strongly dependent on redis, as found in a recent analysis:

A data push will produce nearly 30 read and write operations to redis!

In the performance stress test of data push service, the data report-> send reply is regarded as a transaction, but for such a read-write model, the operation of redis is too frequent, which quickly leads to high latency and low throughput of the system, which can not meet the goal.

The optimization process is mainly aimed at the optimization of the business code, in which the redis operation is reduced to the original 1P5 after a large number of merging, and the system throughput is also improved obviously.

Among them, the application of redis pipeline (pipeline mechanism) is a key means.

Pipeline's interpretation

Pipeline refers to the pipeline technology, which means that the client allows multiple requests to be sent to the server in turn without waiting for the reply of the request, and the result can be read at the end.

Plumbing technology is widely used, for example, many POP3 protocols have implemented to support this feature, greatly speeding up the process of downloading new mail from the server. Redis has supported pipeline technology for a long time. (so no matter what version you are running, you can use pipelining to operate Redis.)

General request model

[figure-pipeline1]

Pipeline request model

[figure-pipeline2]

From the comparison of the two diagrams, we can see that the ordinary request model is synchronous, and each request corresponds to an IO operation waiting.

After Pipeline, all requests are merged into one IO, which can not only reduce the delay, but also greatly improve the system throughput.

Code example

Description

Start 50 threads locally, and each thread completes 1000 key writes. Compare the performance of the two scenarios where pipeline is enabled and not enabled.

Correlation constant

/ / concurrent tasks private static final int taskCount = 50 static final boolean usePipeline / pipeline size private static final int batchSize = 10 transaction static final boolean usePipeline / number of commands per task private static final int cmdCount = 1000

Initialize the connection

JedisPoolConfig poolConfig = new JedisPoolConfig (); poolConfig.setMaxActive; poolConfig.setMaxIdle; poolConfig.setMaxWait (2000); poolConfig.setTestOnBorrow (false); poolConfig.setTestOnReturn (false); jedisPool = new JedisPool (poolConfig, host, port)

Start tasks concurrently and count the execution time

Public static void main (String [] args) throws InterruptedException {init (); flushDB (); long T1 = System.currentTimeMillis (); ExecutorService executor = Executors.newCachedThreadPool (); CountDownLatch latch = new CountDownLatch (taskCount); for (int I = 0; I < taskCount; ionization +) {executor.submit (new DemoTask (I, latch));} latch.await (); executor.shutdownNow (); long T2 = System.currentTimeMillis () System.out.println ("execution finish time (s):" + (T2-T1) / 1000.0);}

DemoTask encapsulates the details of performing key writes, distinguishing between different scenarios

Public void run () {logger.info ("Task [{}] start.", id); try {if (usePipeline) {runWithPipeline ();} else {runWithNonPipeline ();}} finally {latch.countDown ();} logger.info ("Task [{}] end.", id);}

Scenarios that do not use Pipeline are relatively simple, and perform set operations in a loop

For (int I = 0; I < cmdCount; iTunes +) {Jedis jedis = get (); try {jedis.set (key (I), UUID.randomUUID (). ToString ());} finally {if (jedis! = null) {jedisPool.returnResource (jedis);}} if (I% batchSize = = 0) {logger.info ("Task [{}] process-- {}", id, I);}}

Using Pipeline, you need to process segments, such as 10 as a batch of commands

For (int I = 0; I < cmdCount;) {Jedis jedis = get (); try {Pipeline pipeline = jedis.pipelined (); int j; for (j = 0; j < batchSize; jacks +) {if (I + j < cmdCount) {pipeline.set (key (I + j), UUID.randomUUID (). ToString ());} else {break;}} pipeline.sync () Logger.info ("Task [{}] pipeline-{}", id, I + j); I + = j;} finally {if (jedis! = null) {jedisPool.returnResource (jedis);}

Running result

Do not use Pipeline, the overall execution of 26s; but the use of Pipeline optimized code, the execution time is only 3 seconds!

NoPipeline-stat

Pipeline-stat

Matters needing attention

The pipeline mechanism optimizes throughput but does not provide atomicity / transaction guarantees, which can be achieved through commands such as Redis-Multi.

Thank you for reading! This is the end of the article on "how redis improves throughput through pipeline". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it out for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.