Redis之管道的使用
關(guān)鍵詞
Redis Pipelining: 客戶端可以向服務(wù)器發(fā)送多個(gè)請(qǐng)求而無需等待回復(fù), 最后只需一步即可讀取回復(fù).
RTT(Round Trip Time): 往返時(shí)間.
為什么要用管道
Redis是使用client-server模型和Request/Response協(xié)議的TCP服務(wù)器. 這意味著通常通過以下步驟完成請(qǐng)求：
- 客戶端向服務(wù)器發(fā)送查詢, 并通常以阻塞方式從套接字讀取服務(wù)器響應(yīng).
- 服務(wù)器處理該命令并將響應(yīng)發(fā)送回客戶端.
應(yīng)用程序與Redis通過網(wǎng)絡(luò)進(jìn)行連接, 可能非呈硬快(本地回環(huán)), 也可能很慢. 但無論網(wǎng)絡(luò)延遲是多少, 數(shù)據(jù)包都需要時(shí)間從客戶端傳輸?shù)椒?wù)器, 然后從服務(wù)器返回到客戶端以進(jìn)行回復(fù)(此時(shí)間稱為RTT). 當(dāng)客戶端需要連續(xù)執(zhí)行許多請(qǐng)求時(shí)(例如, 將多個(gè)元素添加到同一列表或使用多個(gè)鍵填充數(shù)據(jù)庫), 很容易發(fā)現(xiàn)這種頻繁操作很影響性能. 使用管道將多次操作通過一次IO發(fā)送給Redis服務(wù)器, 然后一次性獲取每一條指令的結(jié)果, 以減少網(wǎng)絡(luò)上的開銷.
頻繁操作但未使用管道的情形如下圖:
使用管道后如下圖:
如何使用
Jedis
/** jedis pool */
private final Logger LOGGER = LoggerFactory.getLogger(getClass());
private static final JedisPool POOL =
new JedisPool(new JedisPoolConfig(), "test-redis-server", 6379);
/**
* test pipelining with Jedis
*/
@Test
public void testPipelining() {
try (Jedis jedis = POOL.getResource()) {
Pipeline pipelined = jedis.pipelined(); // (一)
Response<String> response1 = pipelined.set("mykey1", "myvalue1");
Response<String> response2 = pipelined.set("mykey2", "myvalue2");
Response<String> response3 = pipelined.set("mykey3", "myvalue3");
pipelined.sync(); // (二)
LOGGER.info("cmd: SET mykey1 myvalue1, result: {}", response1.get()); // (三)
LOGGER.info("cmd: SET mykey2 myvalue2, result: {}", response2.get());
LOGGER.info("cmd: SET mykey3 myvalue3, result: {}", response3.get());
}
}
- (一):
jedis.pipelined(): 獲取一個(gè)Pipeline用以批量執(zhí)行指令. - (二):
pipelined.sync(): 同步執(zhí)行, 通過讀取全部Response來同步管道, 這個(gè)操作會(huì)關(guān)閉管道. - (三):
response1.get(): 獲取執(zhí)行結(jié)果. 注意: 在執(zhí)行pipelined.sync()之前,get是無法獲取到結(jié)果的.
Lettuce
private final Logger LOGGER = LoggerFactory.getLogger(getClass());
/** redis client */
private static final RedisClient CLIENT
= RedisClient.create("redis://@test-redis-server:6379/0");
/**
* test pipelining with Lettuce
*/
@Test
public void testPipelining() throws ExecutionException, InterruptedException {
try (StatefulRedisConnection<String, String> connection = CLIENT.connect()) {
RedisAsyncCommands<String, String> async = connection.async();
async.setAutoFlushCommands(false);
RedisFuture<String> future1 = async.set("mykey1", "myvalue1");
RedisFuture<String> future2 = async.set("mykey2", "myvalue2");
RedisFuture<String> future3 = async.set("mykey3", "myvalue3");
async.flushCommands();
LOGGER.info("cmd: SET mykey1 myvalue1, result: {}", future1.get());
LOGGER.info("cmd: SET mykey2 myvalue2, result: {}", future1.get());
LOGGER.info("cmd: SET mykey3 myvalue3, result: {}", future1.get());
}
}
RedisTemplate
private final Logger LOGGER = LoggerFactory.getLogger(getClass());
@Resource
private StringRedisTemplate stringRedisTemplate;
/**
* test pipelining with RedisTemplate
*/
@Test
public void testPipelining() {
List<Object> objects
= stringRedisTemplate.executePipelined((RedisCallback<Object>)connection -> {
connection.set("mykey1".getBytes(), "myvalue1".getBytes());
connection.set("mykey2".getBytes(), "myvalue2".getBytes());
connection.set("mykey3".getBytes(), "myvalue3".getBytes());
return null; // (一)
});
LOGGER.info("cmd: SET mykey myvalue, result: {}", objects);
}
- (一): 此處必須返回
null
簡單對(duì)比測(cè)試
redis服務(wù)器運(yùn)行在同一個(gè)路由器下的樹莓派上.
/**
* pipeline vs direct
*/
@Test
public void compared() {
try (Jedis jedis = POOL.getResource()) { // warm up
jedis.set("mykey", "myvalue");
}
try (Jedis jedis = POOL.getResource()) {
long start = System.nanoTime();
Pipeline pipelined = jedis.pipelined();
for (int index = 0; index < 500; index++) {
pipelined.set("mykey" + index, "myvalue" + index);
}
pipelined.sync();
long end = System.nanoTime();
LOGGER.info("pipeline cost: {} ns", end - start);
}
try (Jedis jedis = POOL.getResource()) {
long start = System.nanoTime();
for (int index = 0; index < 500; index++) {
jedis.set("mykey" + index, "myvalue" + index);
}
long end = System.nanoTime();
LOGGER.info("direct cost: {} ns", end - start);
}
}
使用Jedis執(zhí)行500條set, 執(zhí)行結(jié)果如下:
22:16:00.523 [main] INFO - pipeline cost: 73681257 ns // 管道
22:16:03.040 [main] INFO - direct cost : 2511915103 ns // 直接執(zhí)行
500次set執(zhí)行時(shí)間總和已經(jīng)和管道執(zhí)行一次的所消耗的時(shí)間不在一個(gè)量級(jí)上了.
擴(kuò)展
摘自redis官方文檔
使用管道不僅僅是為了降低RTT以減少延遲成本, 實(shí)際上使用管道也能大大提高Redis服務(wù)器中每秒可執(zhí)行的總操作量. 這是因?yàn)? 在不使用管道的情況下, 盡管操作單個(gè)命令開起來十分簡單, 但實(shí)際上這種頻繁的I/O操作造成的消耗是巨大的, 這涉及到系統(tǒng)讀寫的調(diào)用, 這意味著從用戶域到內(nèi)核域.上下文切換會(huì)對(duì)速度產(chǎn)生極大的損耗.
使用管道操作時(shí), 通常使用單個(gè)read() 系統(tǒng)調(diào)用讀取許多命令，并通過單個(gè)write()系統(tǒng)調(diào)用傳遞多個(gè)回復(fù). 因此, 每秒執(zhí)行的總查詢數(shù)最初會(huì)隨著較長的管道線性增加, 并最終達(dá)到不使用管道技術(shù)獲的10倍, 如下圖所示:
參考文獻(xiàn)
歡迎關(guān)注公眾號(hào): 代碼如詩
[版權(quán)聲明]
本文發(fā)布于樸瑞卿的博客, 非商業(yè)用途允許轉(zhuǎn)載, 但轉(zhuǎn)載必須保留原作者樸瑞卿 及鏈接:blog.piaoruiqing.com. 如有授權(quán)方面的協(xié)商或合作, 請(qǐng)聯(lián)系郵箱: piaoruiqing@gmail.com.
