這篇文章將為大家詳細講解有關redis中管道機制的示例分析,小編覺得挺實用的,因此分享給大家做個參考,希望大家閱讀完這篇文章后可以有所收獲。
創(chuàng)新互聯(lián)公司成都網站建設按需開發(fā),是成都網站推廣公司,為成都除甲醛提供網站建設服務,有成熟的網站定制合作流程,提供網站定制設計服務:原型圖制作、網站創(chuàng)意設計、前端HTML5制作、后臺程序開發(fā)等。成都網站維護熱線:18982081108
Pipeline簡介
Redis客戶端執(zhí)行一條命令:
發(fā)送命令
命令排隊
執(zhí)行命令
返回結果
其中發(fā)送命令和返回結果可以稱為 Round Trip Time (RTT,往返時間)。在Redis中提供了批量操作命令,例如mget、mset等,有效地節(jié)約了RTT。但是大部分命令是不支持批量操作的。
為此Redis提供了一個稱為管道(Pipeline) 的機制將一組Redis命令進行組裝,通過一次 RTT 傳輸給 Redis,再將這些 Redis 命令的執(zhí)行結果按順序傳遞給客戶端。即使用pipeline執(zhí)行了n次命令,整個過程就只需要一次 RTT。
對Pipeline進行性能測試
我們使用redis-benchmark 對Pipeline進行性能測試,該工具提供了 -P 的選項,此選項表示使用管道機制處理 n 條Redis請求,默認值為1。測試如下:
# 不使用管道執(zhí)行get 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ù)量過大,一方面會增加 客戶端等待時間,另一方面會造成一定的網絡阻塞。
從上面的測試中也可以看出,如果一次pipeline組織的命令個數(shù)為 10000,但是它對應的QPS 卻小于 一次pipeline命令個數(shù)為 100的。所以每次組織 Pipeline的命令個數(shù)不是越多越好,可以將一次包含大量命令的 Pipeline 拆分為 多個較小的 Pipeline 來完成。
Pipeline關于RTT的說明
在官網上有一段這樣的描述:

大致意思就是 :
Pipeline管道機制不單單是為了減少RTT的一種方式,它實際上大大提高了Redis的QPS。原因是,在沒有使用管道機制的情況下,從訪問數(shù)據(jù)結構和產生回復的角度來看,為每個命令提供服務是非常便宜的。但是從底層套接字的角度來看,這是非常昂貴的,這涉及read()和write()系統(tǒng)調用,從用戶態(tài)切換到內核態(tài),這種上下文切換開銷是巨大。而使用Pipeline的情況下,通常使用單個read()系統(tǒng)調用讀取許多命令,然后使用單個write()系統(tǒng)調用傳遞多個回復,這樣就提高了QPS
批量命令與Pipeline對比
批量命令是原子的,Pipeline 是非原子的
批量命令是一個命令多個 key,Pipeline支持多個命令
批量命令是 Redis服務端實現(xiàn)的,而Pipeline需要服務端和客戶端共同實現(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)
睡眠結束后,使用 pipeline.sync()完成此次pipeline對象的調用。
127.0.0.1:6379> get hello "world" 127.0.0.1:6379> get counter "1"
必須要執(zhí)行pipeline.sync() 才能最終執(zhí)行命令,當然可以使用 pipeline.syncANdReturnAll回調機制將pipeline響應命令進行返回。
關于“Redis中管道機制的示例分析”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,使各位可以學到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。
網站名稱:Redis中管道機制的示例分析
URL網址:http://www.chinadenli.net/article42/iphjhc.html
成都網站建設公司_創(chuàng)新互聯(lián),為您提供企業(yè)網站制作、網站設計、商城網站、微信公眾號、網站設計公司、
聲明:本網站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)