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