您好,登錄后才能下訂單哦!
本篇內(nèi)容介紹了“Redis中的請求/響應(yīng)模式可以做什么”的有關(guān)知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!
同一個連接上,請求/響應(yīng)模式如下:
交互方向:客戶端發(fā)送請求數(shù)據(jù),服務(wù)器發(fā)送響應(yīng)數(shù)據(jù)
對應(yīng)關(guān)系:每一個請求數(shù)據(jù)有且僅有一個對應(yīng)的響應(yīng)數(shù)據(jù)
時序:響應(yīng)數(shù)據(jù)的發(fā)送發(fā)生在"服務(wù)器完全接收到其對應(yīng)的請求數(shù)據(jù)"之后
串行化實現(xiàn)方式,即同一個連接上,客戶端收完第一個請求的響應(yīng)后,再發(fā)起第二個請求。
同一個連接的每一秒的吞吐量低:
單連接吞吐量 = 1 / (2 * 網(wǎng)絡(luò)延遲 + 服務(wù)器處理單請求的時間 + 客戶端處理單請求的時間)
Redis對單個請求的處理時間非常非常短,因此,在串行化模式下,單連接的大部分時間都處于網(wǎng)絡(luò)等待,滅有充分利用服務(wù)器的能力。
不等上一次結(jié)果返回就發(fā)送下一次請求的模式成為pipeline。
Redis依賴的TCP協(xié)議是全雙工,請求/響應(yīng)穿插進(jìn)行也不會發(fā)生請求和響應(yīng)數(shù)據(jù)的混亂,因此可以將請求數(shù)據(jù)批量發(fā)送到服務(wù)器,再批量地從服務(wù)器連接的字節(jié)流中依次讀取每個響應(yīng)數(shù)據(jù),可極大提高單連接吞吐量。
該模式適合批量的獨立寫入操作。
pipeline的實現(xiàn)取決于客戶端,需要考慮以下方面:
通過批量請求發(fā)送還是異步化請求發(fā)送來實現(xiàn)。
非異步化的批量發(fā)送下需要考慮每個批次的數(shù)據(jù)量,避免連接的buffer滿之后的死鎖
對使用者如何封裝接口,使得pipeline使用簡單
pipeline能達(dá)到的單連接每秒最高吞吐量為:
(n - 2 * 網(wǎng)絡(luò)延遲) / (n * (服務(wù)器單請求處理時間 + 客戶端單請求處理時間))
當(dāng)n無窮大時,網(wǎng)絡(luò)延遲可以忽略不計,吞吐量為:
1 / (服務(wù)器單請求處理時間 + 客戶端單請求處理時間)
“Redis中的請求/響應(yīng)模式可以做什么”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實用文章!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。