[TOC] ## Redis管道技術概述 Redis是一種基于`客戶端-服務端模型(C/S模型)`以及`請求/響應協議`的TCP服務。 這意味著通常情況下一個請求會遵循以下步驟： * 客戶端向服務端發送一個查詢請求，并監聽Socket返回，通常是以阻塞模式，等待服務端響應。 * 服務端處理命令，并將結果返回給客戶端。 這就是普通請求模型。  所謂RTT(Round-Trip Time)，就是**往返時延**，在計算機網絡中它是一個重要的性能指標，表示從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據后便立即發送確認），總共經歷的時延。 一般認為，單向時延 = 傳輸時延t1 + 傳播時延t2 + 排隊時延t3 為了解決這個問題，Redis支持通過管道，來達到減少RTT的目的。  ## Redis管道測試 那么管道的性能究竟如何呢？ 下面我們一起來驗證一下。 首先，redis提供了`redis-benchmark`工具測試性能，我在自己的電腦上通過cmd打開命令行，不使用管道，進行了一百萬次set和get操作，效果如下： ``` $ redis-benchmark -n 1000000 -t set,get -q SET: 81466.40 requests per second GET: 81732.73 requests per second ```  平均每秒處理8萬多次操作請求。 通過`-P`命令使用管道，效果如下： ``` $ redis-benchmark -n 1000000 -t set,get -P 16 -q SET: 602409.63 requests per second GET: 720461.06 requests per second ``` 使用管道以后，set和get的速度變成了每秒將近60萬次和72萬次。 ## 使用管道技術的注意事項 當你要進行頻繁的Redis請求的時候，為了達到最佳性能，降低RTT，你應該使用管道技術。 但如果通過管道發送了太多請求，也會造成Redis的CPU使用率過高。 下面是通過循環向Redis發送出隊指令來監聽隊列的CUP使用情況：  當管道中累計了大量請求以后，CUP使用率迅速升到了100%，這是非常危險的操作。 對于監聽隊列的場景，一個簡單的做法是當發現隊列返回的內容為空的時候，就讓線程休眠幾秒鐘，等隊列中累積了一定量數據以后再通過管道去取，這樣就既能享受管道帶來的高性能，又避免了CPU使用率過高的風險。