Redis基礎(chǔ)學(xué)習(xí)之管道機(jī)制詳析
前言
Redis服務(wù)是一種C/S模型,提供請(qǐng)求-響應(yīng)式協(xié)議的TCP服務(wù),所以當(dāng)客戶端請(qǐng)求發(fā)出,服務(wù)端處理并返回結(jié)果到客戶端,一般是以阻塞形式等待服務(wù)端的響應(yīng),但這在批量處理連接時(shí)延遲問(wèn)題比較嚴(yán)重,所以Redis為了提升或彌補(bǔ)這個(gè)問(wèn)題,引入了管道技術(shù):可以做到服務(wù)端未及時(shí)響應(yīng)的時(shí)候,客戶端也可以繼續(xù)發(fā)送命令請(qǐng)求,做到客戶端和服務(wù)端互不干涉影響,服務(wù)端并最終返回所有服務(wù)端的響應(yīng),這在促進(jìn)原有C/S模型交互的響應(yīng)速度上有了質(zhì)的提高。
以下是對(duì) Redis管道機(jī)制的一個(gè)學(xué)習(xí)記錄
Pipeline簡(jiǎn)介
Redis客戶端執(zhí)行一條命令:
- 發(fā)送命令
- 命令排隊(duì)
- 執(zhí)行命令
- 返回結(jié)果
其中發(fā)送命令和返回結(jié)果可以稱為 Round Trip Time (RTT,往返時(shí)間)。在Redis中提供了批量操作命令,例如mget、mset等,有效地節(jié)約了RTT。但是大部分命令是不支持批量操作的。
為此Redis提供了一個(gè)稱為管道(Pipeline) 的機(jī)制將一組Redis命令進(jìn)行組裝,通過(guò)一次 RTT 傳輸給 Redis,再將這些 Redis 命令的執(zhí)行結(jié)果按順序傳遞給客戶端。即使用pipeline執(zhí)行了n次命令,整個(gè)過(guò)程就只需要一次 RTT。
對(duì)Pipeline進(jìn)行性能測(cè)試
我們使用redis-benchmark 對(duì)Pipeline進(jìn)行性能測(cè)試,該工具提供了 -P 的選項(xiàng),此選項(xiàng)表示使用管道機(jī)制處理 n 條Redis請(qǐng)求,默認(rèn)值為1。測(cè)試如下:
# 不使用管道執(zhí)行g(shù)et set 100000次請(qǐng)求 [root@iz2zeaf3cg1099kiidi06mz ~]# redis-benchmark -t get,set -q -n 100000 SET: 55710.31 requests per second GET: 54914.88 requests per second # 每次pipeline組織的命令個(gè)數(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組織的命令個(gè)數(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
從上面測(cè)試可以看出,使用pipeline的情況下 Redis 每秒處理的請(qǐng)求數(shù)遠(yuǎn)大于 不使用 pipeline的情況。
當(dāng)然每次pipeline組織的命令個(gè)數(shù)不能沒(méi)有節(jié)制,否則一次組裝Pipeline數(shù)據(jù)量過(guò)大,一方面會(huì)增加 客戶端等待時(shí)間,另一方面會(huì)造成一定的網(wǎng)絡(luò)阻塞。
從上面的測(cè)試中也可以看出,如果一次pipeline組織的命令個(gè)數(shù)為 10000,但是它對(duì)應(yīng)的QPS 卻小于 一次pipeline命令個(gè)數(shù)為 100的。所以每次組織 Pipeline的命令個(gè)數(shù)不是越多越好,可以將一次包含大量命令的 Pipeline 拆分為 多個(gè)較小的 Pipeline 來(lái)完成。
Pipeline關(guān)于RTT的說(shuō)明
在官網(wǎng)上有一段這樣的描述:
大致意思就是 :
Pipeline管道機(jī)制不單單是為了減少RTT的一種方式,它實(shí)際上大大提高了Redis的QPS。原因是,在沒(méi)有使用管道機(jī)制的情況下,從訪問(wèn)數(shù)據(jù)結(jié)構(gòu)和產(chǎn)生回復(fù)的角度來(lái)看,為每個(gè)命令提供服務(wù)是非常便宜的。但是從底層套接字的角度來(lái)看,這是非常昂貴的,這涉及read()和write()系統(tǒng)調(diào)用,從用戶態(tài)切換到內(nèi)核態(tài),這種上下文切換開銷是巨大。而使用Pipeline的情況下,通常使用單個(gè)read()系統(tǒng)調(diào)用讀取許多命令,然后使用單個(gè)write()系統(tǒng)調(diào)用傳遞多個(gè)回復(fù),這樣就提高了QPS
批量命令與Pipeline對(duì)比
- 批量命令是原子的,Pipeline 是非原子的
- 批量命令是一個(gè)命令多個(gè) key,Pipeline支持多個(gè)命令
- 批量命令是 Redis服務(wù)端實(shí)現(xiàn)的,而Pipeline需要服務(wù)端和客戶端共同實(shí)現(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("還沒(méi)執(zhí)行命令"); Thread.sleep(100000); System.out.println("這里才開始執(zhí)行"); pipeline.sync(); } }
在睡眠100s的時(shí)候查看 Redis,可以看到此時(shí)在pipeline中的命令并沒(méi)有執(zhí)行,命令都被放在一個(gè)隊(duì)列中等待執(zhí)行:
127.0.0.1:6379> get hello (nil) 127.0.0.1:6379> get counter (nil)
睡眠結(jié)束后,使用 pipeline.sync()
完成此次pipeline對(duì)象的調(diào)用。
127.0.0.1:6379> get hello "world" 127.0.0.1:6379> get counter "1"
必須要執(zhí)行pipeline.sync()
才能最終執(zhí)行命令,當(dāng)然可以使用 pipeline.syncANdReturnAll
回調(diào)機(jī)制將pipeline響應(yīng)命令進(jìn)行返回。
參考資料 & 鳴謝
總結(jié)
以上就是這篇文章的全部?jī)?nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,如果有疑問(wèn)大家可以留言交流,謝謝大家對(duì)腳本之家的支持。
- 詳解redis大幅性能提升之使用管道(PipeLine)和批量(Batch)操作
- .NET客戶端實(shí)現(xiàn)Redis中的管道(PipeLine)與事物(Transactions)
- Python redis操作實(shí)例分析【連接、管道、發(fā)布和訂閱等】
- SpringBoot整合Redis管道的示例代碼
- redis批量操作pipeline管道操作方法
- Redis內(nèi)存碎片產(chǎn)生原因及Pipeline管道原理解析
- Springboot下使用Redis管道(pipeline)進(jìn)行批量操作
- Redis中pipeline(管道)的實(shí)現(xiàn)示例
- Redis中管道操作的項(xiàng)目實(shí)踐
相關(guān)文章
Redis的數(shù)據(jù)存儲(chǔ)及String類型的實(shí)現(xiàn)
這篇文章主要介紹了Redis的數(shù)據(jù)存儲(chǔ)及String類型的實(shí)現(xiàn),redis作為k-v數(shù)據(jù)存儲(chǔ),因查找和操作的時(shí)間復(fù)雜度都是O(1)和豐富的數(shù)據(jù)類型及數(shù)據(jù)結(jié)構(gòu)的優(yōu)化,了解了這些數(shù)據(jù)類型和結(jié)構(gòu)更有利于我們平時(shí)對(duì)于redis的使用,需要的朋友可以參考下2022-10-10Redis實(shí)現(xiàn)庫(kù)存扣減的示例代碼
在日常開發(fā)中有很多地方都有類似扣減庫(kù)存的操作,本文主要介紹了Redis實(shí)現(xiàn)庫(kù)存扣減的示例代碼,具有一定的參考價(jià)值,感興趣的可以了解一下2023-07-07Redis總結(jié)筆記(二):C#連接Redis簡(jiǎn)單例子
這篇文章主要介紹了Redis總結(jié)筆記(二):C#連接Redis簡(jiǎn)單例子,需要的朋友可以參考下2015-01-01聊一聊redis奇葩數(shù)據(jù)類型與集群知識(shí)
現(xiàn)在越來(lái)越多的項(xiàng)目都會(huì)利用到redis,多實(shí)例redis服務(wù)比單實(shí)例要復(fù)雜的多,這里面涉及到定位、容錯(cuò)、擴(kuò)容等技術(shù)問(wèn)題,下面這篇文章主要給大家介紹了關(guān)于redis奇葩數(shù)據(jù)類型與集群知識(shí)的相關(guān)資料,需要的朋友可以參考下2022-01-01利用控制臺(tái)如何對(duì)Redis執(zhí)行增刪改查命令
這篇文章主要給大家介紹了關(guān)于利用控制臺(tái)如何對(duì)Redis執(zhí)行增刪改查命令的相關(guān)資料,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2018-08-08基于Redis實(shí)現(xiàn)API接口訪問(wèn)次數(shù)限制
日常開發(fā)中會(huì)有一個(gè)常見(jiàn)的需求,需要限制接口在單位時(shí)間內(nèi)的訪問(wèn)次數(shù),比如說(shuō)某個(gè)免費(fèi)的接口限制單個(gè)IP一分鐘內(nèi)只能訪問(wèn)5次,該怎么實(shí)現(xiàn)呢,本文小編給大家介紹了如何基于Redis實(shí)現(xiàn)API接口訪問(wèn)次數(shù)限制,需要的朋友可以參考下2024-11-11