主頁 > 知識庫 > Redis基礎(chǔ)學習之管道機制詳析

Redis基礎(chǔ)學習之管道機制詳析

熱門標簽:b2b外呼系統(tǒng) 四川穩(wěn)定外呼系統(tǒng)軟件 地圖標注工廠入駐 400電話辦理的口碑 臺灣電銷 高碑店市地圖標注app 廊坊外呼系統(tǒng)在哪買 南京手機外呼系統(tǒng)廠家 一個地圖標注多少錢

前言

Redis服務(wù)是一種C/S模型,提供請求-響應(yīng)式協(xié)議的TCP服務(wù),所以當客戶端請求發(fā)出,服務(wù)端處理并返回結(jié)果到客戶端,一般是以阻塞形式等待服務(wù)端的響應(yīng),但這在批量處理連接時延遲問題比較嚴重,所以Redis為了提升或彌補這個問題,引入了管道技術(shù):可以做到服務(wù)端未及時響應(yīng)的時候,客戶端也可以繼續(xù)發(fā)送命令請求,做到客戶端和服務(wù)端互不干涉影響,服務(wù)端并最終返回所有服務(wù)端的響應(yīng),這在促進原有C/S模型交互的響應(yīng)速度上有了質(zhì)的提高。

以下是對 Redis管道機制的一個學習記錄

Pipeline簡介

Redis客戶端執(zhí)行一條命令:

  • 發(fā)送命令
  • 命令排隊
  • 執(zhí)行命令
  • 返回結(jié)果

其中發(fā)送命令和返回結(jié)果可以稱為 Round Trip Time (RTT,往返時間)。在Redis中提供了批量操作命令,例如mget、mset等,有效地節(jié)約了RTT。但是大部分命令是不支持批量操作的。

為此Redis提供了一個稱為管道(Pipeline) 的機制將一組Redis命令進行組裝,通過一次 RTT 傳輸給 Redis,再將這些 Redis 命令的執(zhí)行結(jié)果按順序傳遞給客戶端。即使用pipeline執(zhí)行了n次命令,整個過程就只需要一次 RTT。

對Pipeline進行性能測試

我們使用redis-benchmark 對Pipeline進行性能測試,該工具提供了 -P 的選項,此選項表示使用管道機制處理 n 條Redis請求,默認值為1。測試如下:

# 不使用管道執(zhí)行g(shù)et set 100000次請求
[root@iz2zeaf3cg1099kiidi06mz ~]# redis-benchmark -t get,set -q -n 100000
SET: 55710.31 requests per second
GET: 54914.88 requests per second
# 每次pipeline組織的命令個數(shù) 為 100
[root@iz2zeaf3cg1099kiidi06mz ~]# redis-benchmark -P 100 -t get,set -q -n 100000
SET: 1020408.19 requests per second
GET: 1176470.62 requests per second
# 每次pipeline組織的命令個數(shù) 為 10000
[root@iz2zeaf3cg1099kiidi06mz ~]# redis-benchmark -P 10000 -t get,set -q -n 100000
SET: 321543.41 requests per second
GET: 241545.89 requests per second

從上面測試可以看出,使用pipeline的情況下 Redis 每秒處理的請求數(shù)遠大于 不使用 pipeline的情況。

當然每次pipeline組織的命令個數(shù)不能沒有節(jié)制,否則一次組裝Pipeline數(shù)據(jù)量過大,一方面會增加 客戶端等待時間,另一方面會造成一定的網(wǎng)絡(luò)阻塞。

從上面的測試中也可以看出,如果一次pipeline組織的命令個數(shù)為 10000,但是它對應(yīng)的QPS 卻小于 一次pipeline命令個數(shù)為 100的。所以每次組織 Pipeline的命令個數(shù)不是越多越好,可以將一次包含大量命令的 Pipeline 拆分為 多個較小的 Pipeline 來完成。

Pipeline關(guān)于RTT的說明

在官網(wǎng)上有一段這樣的描述:

大致意思就是 :

Pipeline管道機制不單單是為了減少RTT的一種方式,它實際上大大提高了Redis的QPS。原因是,在沒有使用管道機制的情況下,從訪問數(shù)據(jù)結(jié)構(gòu)和產(chǎn)生回復(fù)的角度來看,為每個命令提供服務(wù)是非常便宜的。但是從底層套接字的角度來看,這是非常昂貴的,這涉及read()和write()系統(tǒng)調(diào)用,從用戶態(tài)切換到內(nèi)核態(tài),這種上下文切換開銷是巨大。而使用Pipeline的情況下,通常使用單個read()系統(tǒng)調(diào)用讀取許多命令,然后使用單個write()系統(tǒng)調(diào)用傳遞多個回復(fù),這樣就提高了QPS

批量命令與Pipeline對比

  • 批量命令是原子的,Pipeline 是非原子的
  • 批量命令是一個命令多個 key,Pipeline支持多個命令
  • 批量命令是 Redis服務(wù)端實現(xiàn)的,而Pipeline需要服務(wù)端和客戶端共同實現(xiàn)

使用jedis執(zhí)行 pipeline

public class JedisUtils {
 private static final JedisUtils jedisutils = new JedisUtils();

 public static JedisUtils getInstance() {
 return jedisutils;
 }

 public JedisPool getPool(String ip, Integer port) {
 JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
 jedisPoolConfig.setMaxIdle(RedisConfig.MAX_IDLE);
 jedisPoolConfig.setMaxTotal(RedisConfig.MAX_ACTIVE);
 jedisPoolConfig.setMaxWaitMillis(RedisConfig.MAX_WAIT);
 jedisPoolConfig.setTestOnBorrow(true);
 jedisPoolConfig.setTestOnReturn(true);
 JedisPool pool = new JedisPool(jedisPoolConfig, ip, port,RedisConfig.TIMEOUT,RedisConfig.PASSWORD);
 return pool;
 }

 public Jedis getJedis(String ip, Integer port) {
 Jedis jedis = null;
 int count = 0;
 while (jedis == null  count  RedisConfig.RETRY_NUM) {
  try {
  jedis = getInstance().getPool(ip, port).getResource();
  } catch (Exception e) {
  System.out.println("get redis failed");
  }
  count++;
 }
 return jedis;
 }

 public void closeJedis(Jedis jedis) {
 if (jedis != null) {
  jedis.close();
 }
 }

 public static void main(String[] args) throws InterruptedException {
 Jedis jedis = JedisUtils.getInstance().getJedis("127.0.0.1", 6379);
 Pipeline pipeline = jedis.pipelined();
 pipeline.set("hello", "world");
 pipeline.incr("counter");
 System.out.println("還沒執(zhí)行命令");
 Thread.sleep(100000);
 System.out.println("這里才開始執(zhí)行");
 pipeline.sync();
 }
}

在睡眠100s的時候查看 Redis,可以看到此時在pipeline中的命令并沒有執(zhí)行,命令都被放在一個隊列中等待執(zhí)行:

127.0.0.1:6379> get hello
(nil)
127.0.0.1:6379> get counter
(nil)

睡眠結(jié)束后,使用 pipeline.sync()完成此次pipeline對象的調(diào)用。

127.0.0.1:6379> get hello
"world"
127.0.0.1:6379> get counter
"1"

必須要執(zhí)行pipeline.sync() 才能最終執(zhí)行命令,當然可以使用 pipeline.syncANdReturnAll回調(diào)機制將pipeline響應(yīng)命令進行返回。

參考資料 鳴謝

  • Redis開發(fā)與運維
  • Using pipelining to speedup Redis queries

總結(jié)

以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。

您可能感興趣的文章:
  • 詳解redis大幅性能提升之使用管道(PipeLine)和批量(Batch)操作
  • .NET客戶端實現(xiàn)Redis中的管道(PipeLine)與事物(Transactions)

標簽:河源 拉薩 泰州 定州 畢節(jié) 甘南 南寧 伊春

巨人網(wǎng)絡(luò)通訊聲明:本文標題《Redis基礎(chǔ)學習之管道機制詳析》,本文關(guān)鍵詞  Redis,基礎(chǔ),學,習之,管道,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《Redis基礎(chǔ)學習之管道機制詳析》相關(guān)的同類信息!
  • 本頁收集關(guān)于Redis基礎(chǔ)學習之管道機制詳析的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章