# pipeline壓縮請求數量 通常情況下，我們每個操作redis的命令都以一個TCP請求發送給redis，這樣的做法簡單直觀。然而，當我們有連續多個命令需要發送給redis時，如果每個命令都以一個數據包發送給redis，將會降低服務端的并發能力。 為什么呢？大家知道每發送一個TCP報文，會存在網絡延時及操作系統的處理延時。大部分情況下，網絡延時要遠大于CPU的處理延時。如果一個簡單的命令就以一個TCP報文發出，網絡延時將成為系統性能瓶頸，使得服務端的并發數量上不去。 首先檢查你的代碼，是否明確完整使用了redis的長連接機制。作為一個服務端程序員，要對長連接的使用有一定了解，在條件允許的情況下，一定要開啟長連接。驗證方式也比較簡單，直接用tcpdump或wireshark抓包分析一下網絡數據即可。 > set_keepalive的參數：按照業務正常運轉的并發數量設置，不建議使用峰值情況設置。 如果我們確定開啟了長連接，發現這時候Redis的CPU的占用率還是不高，在這種情況下，就要從Redis的使用方法上進行優化。 如果我們可以把所有單次請求，壓縮到一起，如下圖：  很慶幸Redis早就為我們準備好了這道菜，就等著我們吃了，這道菜就叫`pipeline`。pipeline機制將多個命令匯聚到一個請求中，可以有效減少請求數量，減少網絡延時。下面是對比使用pipeline的一個例子： ~~~ # you do not need the following line if you are using # the ngx_openresty bundle: lua_package_path "/path/to/lua-resty-redis/lib/?.lua;;"; server { location /withoutpipeline { content_by_lua ' local redis = require "resty.redis" local red = redis:new() red:set_timeout(1000) -- 1 sec -- or connect to a unix domain socket file listened -- by a redis server: -- local ok, err = red:connect("unix:/path/to/redis.sock") local ok, err = red:connect("127.0.0.1", 6379) if not ok then ngx.say("failed to connect: ", err) return end local ok, err = red:set("cat", "Marry") ngx.say("set result: ", ok) local res, err = red:get("cat") ngx.say("cat: ", res) ok, err = red:set("horse", "Bob") ngx.say("set result: ", ok) res, err = red:get("horse") ngx.say("horse: ", res) -- put it into the connection pool of size 100, -- with 10 seconds max idle time local ok, err = red:set_keepalive(10000, 100) if not ok then ngx.say("failed to set keepalive: ", err) return end '; } location /withpipeline { content_by_lua ' local redis = require "resty.redis" local red = redis:new() red:set_timeout(1000) -- 1 sec -- or connect to a unix domain socket file listened -- by a redis server: -- local ok, err = red:connect("unix:/path/to/redis.sock") local ok, err = red:connect("127.0.0.1", 6379) if not ok then ngx.say("failed to connect: ", err) return end red:init_pipeline() red:set("cat", "Marry") red:set("horse", "Bob") red:get("cat") red:get("horse") local results, err = red:commit_pipeline() if not results then ngx.say("failed to commit the pipelined requests: ", err) return end for i, res in ipairs(results) do if type(res) == "table" then if not res[1] then ngx.say("failed to run command ", i, ": ", res[2]) else -- process the table value end else -- process the scalar value end end -- put it into the connection pool of size 100, -- with 10 seconds max idle time local ok, err = red:set_keepalive(10000, 100) if not ok then ngx.say("failed to set keepalive: ", err) return end '; } } ~~~ 在我們實際應用場景中，正確使用pipeline對性能的提升十分明顯。我們曾經某個后臺應用，逐個處理大約100萬條記錄需要幾十分鐘，經過pileline壓縮請求數量后，最后時間縮小到20秒左右。做之前能預計提升性能，但是沒想到提升如此巨大。 在360企業安全目前的應用中，Redis的使用瓶頸依然停留在網絡上，不得不承認Redis的處理效率相當贊。