Redis 服务器管理相关命令
客戶端相關
查看客戶端列表
CLIENT LIST
自2.4.0可用。
時間復雜度：O(N) N是客戶端連接數量。
語法：CLIENT LIST
說明：
Redis CLIENT LIST 命令用于返回所有連接到服務器的客戶端信息和統計數據。
返回值：
一個獨特的字符串，格式如下：
每個已連接客戶端對應一行（以 LF 分割）
每行字符串由一系列 屬性=值（property=value） 形式的域組成，每個域之間以空格分開。
下面是各字段的含義：
客戶端標識
CLIENT LIST 命令中相關字段：
id: 唯一的64位的客戶端1ID(Redis 2.8.12加入)。
addr: 客戶端的地址和端口
fd: 套接字所使用的文件描述符
name:客戶端的名字，后面的 CLIENT SETNAME 和 CLIENT GETNAME 兩個命令會對其進行說明。
輸入緩沖區
Redis 為每個客戶端分配有輸入緩存區，用于將客戶端發送的命令臨時保存。Redis 會從緩存區中拉取命令并執行。輸入緩沖區會根據輸入內容大小的不同動態調整，只是要求每個客戶端緩沖區的大小不能超過 1G ，超過后客戶端將被關閉。
輸入緩沖區不受 maxmemory 控制，假設一個 Redis 實例設置了 maxmemory 為4G，已經存儲了2G數據，但是如果此時輸入緩沖區使用了 3G，已經超過 maxmemory 限制，可能會產生數據丟失、鍵值淘汰、Out Of Memory 等情況。這種情況在正常使用過程中出現較少，但是需要注意防范 Redis 使用不規范導致出現這種情況
造成緩沖區過大的原因是 輸入命令過多，Redis 無法及時處理，可能的情況：
? a) 客戶端過多，命令輸入過多。
? b) 由于命令使用的不恰當（key過大，或運行時間復雜度較高的命令）等原因造成 Redis 阻塞無法處理新的命令，從而導致客戶端輸入的命令積壓在輸入緩沖區，造成了輸入緩沖區過大。
監控輸入緩沖區異常的方法有兩種：
a) 通過定期執行 `CLIENT LIST` 命令，收集 `qbuf` 和 `qbuf-free` 找到異常的連接記錄并分析，最終找到可能出問題的客戶端。該方法可以精準的監控每個客戶端，但執行較慢，在連接數較多時可能會阻塞 Redis。b) 通過 `INFO CLIENTS` 命令，找到最大的輸入緩沖區（`client_biggest_input_buf`），該命令相較于 `CLIENT LIST` 執行較快，結果一目了然，但無法精準到具體客戶端，無法查看緩存區大小等信息。CLIENT LIST 命令中相關字段：
qbuf: 查詢緩沖區的總容量（字節為單位， 0 表示沒有分配查詢緩沖區）
qbuf-free: 查詢緩沖區剩余容量（字節為單位， 0 表示沒有剩余空間）
輸出緩沖區
Redis為每個客戶端分配了輸出緩沖區，它的作用是保存命令執行的結果返回給客戶端，為Redis和客戶端交互返回結果提供緩沖。與輸入緩沖區不同的是，輸出緩沖區的容量可以通過參數 client-outputbuffer-limit 來進行設置，并且輸出緩沖區做得更加細致，按照客戶端的不同分為三種：普通客戶端、發布訂閱客戶端、slave客戶端，不同類型的客戶端的輸出緩沖區不同可以分別進行設置。
在 Redis 配置文件中可以配置：
client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
其中：
-
<class> ：客戶端類型，分為三種。
a）normal：普通客戶端；
b）slave：slave客戶端，用于復制；
c）pubsub：發布訂閱客戶端。
<hard limit>：如果客戶端使用的輸出緩沖區大于<hard limit>，客戶端會被立即關閉。
<soft limit> 和 <soft seconds> ：如果客戶端使用的輸出緩沖區超過了 <soft limit> 并且持續了 <soft limit> 秒，客戶端會被立即關閉。
Redis 中對應的默認配置：
client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60輸出緩沖區同樣存在內存溢出的問題。（見 輸入緩沖區相關內容）
輸出緩沖區由兩部分組成：響應緩沖區（16KB）和回復列表，其中響應緩沖區返回比較小的執行結果，而回復列表返回比較大的結果，例如大的字符串、HGEtALL 、SMEMBERS 命令的結果等。
響應緩沖區使用的是字節數組，回復列表使用的是列表。當響應緩沖區存滿后會將 Redis 新的返回結果存放在回復列表的隊列中，隊列中的每個對象就是每個返回結果。
監控輸出緩沖區異常的方法有兩種：
a) 通過定期執行 `CLIENT LIST` 命令，收集 `obl`、`oll` 和 `omem` 找到異常的連接記錄并分析，最終找到可能出問題的客戶端。該方法可以精準的監控每個客戶端，但執行較慢，在連接數較多時可能會阻塞 Redis。b) 通過 `INFO CLIENTS` 命令，找到最大的回復列表（`client_longest_output_list`），該命令相較于 `CLIENT LIST` 執行較快，結果一目了然，但無法精準到具體客戶端，無法查看緩存區大小等信息。相比于輸入緩沖區，輸出緩沖區出現異常的概率相對會比較大，預防出現問題的方法：
通過上面兩中方法進行監控，設置閾值，超閾值后及時處理。
顯示普通客戶端的輸出緩存區：
client-output-buffer-limit normal 20mb 10mb 120
適當增大 slave 的輸出緩沖區的，如果 master 節點寫入較大，slave 客戶端的輸出緩沖區可能會比較大，一旦 slave 客戶端連接因為輸出緩沖區溢出被 kill ，會造成復制重連。
限制容易讓輸出緩沖區增大的命令，例如，高并發下的 MONITOR 命令就是一個危險的命令。
及時監控內存，一旦發現內存抖動頻繁，可能就是輸出緩沖區過大。
CLIENT LIST 命令中相關字段：
obl: 輸出緩沖區的長度（字節為單位， 0 表示沒有分配輸出緩沖區）
oll: 輸出列表包含的對象數量（當輸出緩沖區沒有剩余空間時，命令回復會以字符串對象的形式被入隊到這個隊列里）
omem: 輸出緩沖區和輸出列表占用的內存總量
客戶端的存活狀態
age: 以秒計算的已連接時長
idle: 最近一次（100ms 或者更長時間）以秒計算的空閑時長
客戶端類型
flags: 客戶端 flag
客戶端 flag 可以由以下部分組成：
O: 客戶端是 MONITOR 模式下的附屬節點（slave）
S: 客戶端是一般模式下（normal）的附屬節點
M: 客戶端是主節點（master）
x: 客戶端正在執行事務
b: 客戶端正在等待阻塞事件
i: 客戶端正在等待 VM I/O 操作（已廢棄）
d: 一個受監視（watched）的鍵已被修改， EXEC 命令將失敗
c: 在將回復完整地寫出之后，關閉鏈接
u: 客戶端未被阻塞（unblocked）
U: 通過Unix套接字連接的客戶端
r: 客戶端是只讀模式的集群節點
A: 盡可能快地關閉連接
N: 未設置任何 flag，普通客戶端
db: 該客戶端正在使用的數據庫 ID
sub: 已訂閱頻道的數量
psub: 已訂閱模式的數量
multi: 在事務中被執行的命令數量
events: 文件描述符事件
cmd: 最近一次執行的命令
文件描述符事件可以是：
r: 客戶端套接字（在事件 loop 中）是可讀的（readable）
w: 客戶端套接字（在事件 loop 中）是可寫的（writeable）
為了 debug 的需要，經常會對域進行添加和刪除。一個版本安全的 Redis 客戶端使用這個命令時應該根據字段解析相應內容。（比如：處理未知的字段，應跳過該字段）。
示例：
coderknock> CLIENT LIST # 連接時間 87 秒 空閑 87 秒 說明該連接一直處于空閑狀態 id=3 addr=127.0.0.1:55773 fd=8 name= age=87 idle=87 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=18446744073709537584 events=r cmd=command id=4 addr=127.0.0.1:55795 fd=7 name= age=58 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=18446744073709537584 events=r cmd=client #響應緩沖區的長度為0，回復列表有4869個對象，兩個部分共使用了133081288字節=126M id=7 addr=127.0.0.1:56358 fd=6 name= age=91 idle=0 flags=O db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=4869 omem=133081288 events=rw cmd=monitor獲取/設置名稱
CLIENT GETNAME
自2.6.9可用。
時間復雜度：O(1)。
語法：CLIENT GETNAME
說明：
CLIENT GETNAME 返回當前連接由CLIENT SETNAME設置的名字。如果沒有用CLIENT SETNAME設置名字，將返回一個空的回復。
返回值：
返回連接名字或者空（沒有設置名字時）
示例：
coderknock> CLIENT GETNAME (nil) # 只針對當前客戶端 coderknock> CLIENT SETNAME coderknock OK coderknock> CLIENT GETNAME "coderknock"CLIENT SETNAME
自2.6.9可用。
時間復雜度：O(1)。
語法：CLIENT SETNAME connection-name
說明：
為當前連接分配一個名字。
這個名字會顯示在 CLIENT LIST 命令的結果中， 用于識別當前正在與服務器進行連接的客戶端。
舉個例子， 在使用 Redis 構建隊列（queue）時， 可以根據連接負責的任務（role）， 為信息生產者（producer）和信息消費者（consumer）分別設置不同的名字。
名字使用 Redis 的字符串類型來保存， 最大可以占用 512 MB 。 另外， 為了避免和 CLIENT LIST 命令的輸出格式發生沖突， 名字里不允許使用空格。
要移除一個連接的名字， 可以將連接的名字設為空字符串 "" 。
使用 CLIENT GETNAME 命令可以取出連接的名字。
新創建的連接默認是沒有名字的。
在 Redis 應用程序發生連接泄漏時，為連接設置名字是一種很好的 debug 手段。
返回值：
設置成功時返回 OK 。
示例：
# 新連接默認沒有名字coderknock> CLIENT GETNAME (nil)# 設置名字 coderknock> CLIENT SETNAME coderknock OK# 返回名字 coderknock> CLIENT GETNAME "coderknock"# 在客戶端列表中查看 coderknock> CLIENT LIST id=5 addr=127.0.0.1:49298 fd=8 name=coderknock age=173 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=18446744073709537584 events=r cmd=client# 清除名字 coderknock> CLIENT SETNAME # 只用空格是不行的！ (error) ERR Syntax error, try CLIENT (LIST | KILL ip:port) coderknock> CLIENT SETNAME "" # 必須雙引號顯示包圍 OK coderknock> CLIENT GETNAME (nil) coderknock> CLIENT LIST id=5 addr=127.0.0.1:49298 fd=8 name= age=203 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=18446744073709537584 events=r cmd=client#別的客戶端同樣可以取名為 coderknock coderknock> CLIENT LIST id=6 addr=127.0.0.1:49438 fd=7 name=coderknock age=67 idle=32 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=18446744073709537584 events=r cmd=client id=7 addr=127.0.0.1:49454 fd=9 name=coderknock age=25 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=18446744073709537584 events=r cmd=client在 Redis 只有一個應用方使用的情況下，IP和端口作為標識會更加清晰。當多個應用方共同使用一個Redis，那么此時 CLIENT SETNAME 可以作為標識客戶端的一個依據。
客戶端限制
maxclients timeout
在之前的 《Redis 配置》一文中我們講過 CONFIG GET CONFIG_SETTING_NAME、CONFIG SET CONFIG_SETTING_NAME NEW_CONFIG_VALUE，命令，其中CONFIG GET/SET maxclients 用于獲取/設置客戶端最大連接數，一旦連接數超過 maxclients 新的連接將被拒絕，maxclients 默認值是10000，可以通過 INFO clients來查詢當前Redis的連接數：
# 查詢最大連接數 coderknock> CONFIG GET maxclients 1) "maxclients" 2) "10000" coderknock> INFO clients # Clients connected_clients:1 #當前連接客戶端數 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0可以通過 CONFIG SET maxclients 對最大客戶端連接數進行動態設置：
# 我們將 maxclients 設置小些 coderknock> CONFIG SET maxclients 2 OK coderknock> CONFIG GET maxclients 1) "maxclients" 2) "2" # 我們啟動再啟動兩個客戶端此時在第一個或第二個客戶端上執行 coderknock> CLIENT LIST id=2 addr=127.0.0.1:51010 fd=7 name= age=386 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=18446744073709537584 events=r cmd=client id=3 addr=127.0.0.1:51091 fd=8 name= age=154 idle=126 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=18446744073709537584 events=r cmd=keys # 在第三個啟動的客戶端上進行操作（命令窗口并沒有關閉所以還是可以執行的） coderknock> keys * Error: 遠程主機強迫關閉了一個現有的連接。 # 可以看到這個客戶端不能正常使用一般情況下 maxclients 默認的 10000 大小已經做夠使用了，但是有時由于使用不當可能導致存在大量空閑連接（idle 較大的連接），無論是從網絡連接的成本還是超過maxclients的后果來說都不是什么好事，因此 Redis 提供了 timeout （單位為秒）參數限制連接的最大空閑時間，一旦客戶端空閑時間超過了 timeout 設置，連接將會被關閉。使用 CONFIG GET/SET timeout 可以獲取設置 timeout:
# #Redis默認的 timeout 是0，也就是沒有超時時間 coderknock> CONFIG GET timeout 1) "timeout" 2) "0"Redis的默認配置給出的 timeout=0 ，在這種情況下客戶端基本不會出現上面的異常，這是基于對客戶端開發的一種保護。如果客戶端設置了超時，可能就會出現連接超時的異常，對應用業務造成一定影響，但是如果 Redis 的客戶端使用不當或者客戶端本身的一些問題，造成沒有及時釋放客戶端連接，可能會造成大量的空閑連接占據著很多連接資源，一旦超過 maxclients；后果也是不堪設想。所在在實際開發和運維中，需要將 timeout 設置成大于0 且較大的數字，例如可以設置為300秒，同時在客戶端使用上添加空閑檢測和驗證等等措施。
關閉客戶端
CLINET KILL
自2.4.0可用。
時間復雜度：O(N) N是客戶端連接數量。
語法：CLIENT KILL [ip:port][ID client-id] [normal|slave|pubsub][ADDR ip:port][SKIPME yes/no]
說明：
CLIENT KILL關閉一個指定的連接。在 Redis2.8.11 時可以根據客戶端地址關閉指定連接，關閉方式如下：
CLIENT KILL addr:port addr:port 應該是 CLIENT LIST 命令里面列出的客戶端連接之一。
然而，從Redis 2.8.12開始，這個命令改為如下格式：
CLIENT KILL <filter> <value> ... ... <filter> <value>
新的格式可以根據不同屬性殺死客戶端而不是只按地址殺死。他們有以下一些格式：
CLIENT KILL ADDR ip:port ： 和舊版的三個參數時的行為完全一樣。
CLIENT KILL ID client-id ： 可以通過唯一 ID 字段殺死一個客戶端，唯一 ID 可以通過 Redis 2.8.12 開始的 CLIENT LIST 命令查詢（之前版本可能沒有 ID 字段）。
CLIENT KILL TYPE type ： 這里的 type 可以是 normal , slave , pubsub （Redis 3.2 版本之后增加了 master 類型的支持）。 這將關閉所有特殊類的客戶端。 請注意被認為是屬于正常類的客戶端將會被MONITOR 命令監視到。
CLIENT KILL SKIPME yes/no：默認情況下，該選項設置為yes ，即調用過該命令的客戶端將不會被殺死，將該選項設置為 no 即也會殺死調用過該命令的客戶端。
該命令支持同時使用多個過濾器，或殺死多個過濾器的合集。
由于Redis的單線程特性，在執行命令時無法終止客戶端連接。從客戶端的角度來看，在執行命令的過程中，連接永遠不會被關閉。但是，只有當下一個命令發送（并導致網絡錯誤）時，客戶端才會注意到連接已關閉。
返回值：
當用三個參數格式調用時：
如果連接存在并已關閉返回OK
當使用過濾器/值格式調用時：
客戶端數量被殺。
示例：
# 列出所有已連接客戶端coderknock> CLIENT LIST addr=127.0.0.1:43501 fd=5 age=10 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client# 殺死當前客戶端的連接coderknock> CLIENT KILL 127.0.0.1:43501 OK# 之前的連接已經被關閉，CLI 客戶端又重新建立了連接 # 之前的端口是 43501 ，現在是 43504coderknock> CLIENT LIST addr=127.0.0.1:43504 fd=5 age=0 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client由于一些原因（例如設置 timeout=0 時產生的長時間空閑的客戶端），需要手動殺掉客戶端連接時，可以使用 CLIENT KILL 命令。
阻塞客戶端
CLIENT PAUSE
自2.9.5可用。
時間復雜度：O(1)。
語法：CLIENT PAUSE timeout
說明：
CLIENT PAUSE 是一個連接控制命令，可以在指定的時間（以毫秒為單位）中掛起所有Redis客戶端。
該命令執行以下操作：
只對普通和發布訂閱客戶端有效，對于主從復制（從節點內部偽裝了一個客戶端）是無效的，也就是此期間主從復制是正常進行的，所以此命令可以用來讓主從復制保持一致。
但是它盡可能地返回給調用者，因此 CLIENT PAUSE 命令的執行不會自動暫停（返回之后還是會暫停自身的客戶端）。
當指定的時間量過去時，所有客戶端都被解除阻塞：這將在暫停期間觸發對每個客戶端的查詢緩沖區中累積的所有命令的處理。
此命令非常有用，因為它可以用一種可控的方式將客戶端連接從一個Redis節點切換到另一個Redis節點。例如，在實例升級期間，系統管理員可以執行以下操作：
使用 CLIENT PAUSE 暫停客戶 端
等待幾秒鐘以確保從站從主設備處理最新的復制流。
把一個從節點變成一個主節點。
重新配置客戶端以連接新的主節點。
可以將命令 暫停 發送到 MULTI / EXEC 塊 INFO replication 中，以便在客戶端被阻止時獲取當前的主節點偏移量。這樣，可以在從屬端等待特定的偏移量，以確保處理所有的復制流。
Redis 3.2.10 / 4.0.0 中此命令還可以防止在客戶端暫停期間鍵被釋放或過期。這樣，數據集就被保證是靜態的，而不僅僅是從客戶端無法寫入的角度來看，而且從內部操作的角度來說也是如此。
返回值：
如果超時無效，則該命令返回OK或錯誤。
示例：
coderknock> CLIENT PAUSE 10000 OK coderknock> GET hello "world" (10.06s) # 這里可以看到查詢花費 10s 的時間該命令在生產環境如要使用應挑選操作較少時，不然可能會引發不可預知的情況。
客戶端回復設定
CLIENT REPLY
自3.2.0可用。
時間復雜度：O(1)。
語法：CLIENT REPLY ON|OFF|SKIP
說明：
有時客戶端可以完全禁用Redis服務器的回復
CLIENT REPLY 命令控制服務器是否會回復客戶端的命令。提供以下模式：
ON。這是默認模式服務器返回每個命令的回復。
OFF。在此模式下，服務器將不會回復客戶端命令。
SKIP。此模式會立即跳過命令的回復。
返回值：
當用 OFF 或 SKIP 命令調用時，不作任何回復。調用時ON：返回OK。
該命令是新命令目前兼容客戶端較少
監控
MONITOR
自1.0.0可用。
時間復雜度：不明確。
語法：MONITOR
說明：
MONITOR 是一個調試命令，返回服務器處理的每一個命令，它能幫助我們了解在數據庫上發生了什么操作，可以通過redis-cli和telnet命令使用.
$ redis-cli monitor 1339518083.107412 [0 127.0.0.1:60866] "keys" "*" 1339518087.877697 [0 127.0.0.1:60866] "dbsize" 1339518090.420270 [0 127.0.0.1:60866] "set" "x" "6" 1339518096.506257 [0 127.0.0.1:60866] "get" "x" 1339518099.363765 [0 127.0.0.1:60866] "del" "x" 1339518100.544926 [0 127.0.0.1:60866] "get" "x"使用SIGINT (Ctrl-C)來停止 通過redis-cli使用 MONITOR 命令返回的輸出.
$ telnet localhost 6379 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. MONITOR +OK +1339518083.107412 [0 127.0.0.1:60866] "keys" "*" +1339518087.877697 [0 127.0.0.1:60866] "dbsize" +1339518090.420270 [0 127.0.0.1:60866] "set" "x" "6" +1339518096.506257 [0 127.0.0.1:60866] "get" "x" +1339518099.363765 [0 127.0.0.1:60866] "del" "x" +1339518100.544926 [0 127.0.0.1:60866] "get" "x" QUIT +OK Connection closed by foreign host.使用 QUIT 命令來停止通過telnet使用 MONITOR 返回的輸出.
MONITOR 性能消耗
由于 MONITOR 命令返回 服務器處理的所有的 命令, 所以在性能上會有一些消耗.
在不運行 MONITOR 命令的情況下，benchmark的測試結果:
$ src/redis-benchmark -c 10 -n 100000 -q PING_INLINE: 101936.80 requests per second PING_BULK: 102880.66 requests per second SET: 95419.85 requests per second GET: 104275.29 requests per second INCR: 93283.58 requests per second在運行 MONITOR 命令的情況下，benchmark的測試結果: (redis-cli monitor > /dev/null):
$ src/redis-benchmark -c 10 -n 100000 -q PING_INLINE: 58479.53 requests per second PING_BULK: 59136.61 requests per second SET: 41823.50 requests per second GET: 45330.91 requests per second INCR: 41771.09 requests per second在這種特定的情況下，運行一個 MONITOR 命令能夠降低50%的吞吐量，運行多個 MONITOR 命令 降低的吞吐量更多。
每個客戶端都有自己的輸出緩沖區，既然 MONITOR 能監聽到所有的命令，一旦 Redis 的并發量過大 MONITOR 客戶端的輸出緩沖會暴漲，可能瞬間會占用大量內存。
返回值：
沒有統一標準的返回值, 無限的返回服務器端處理的命令流.或 key 不存在，返回 0 。
示例：
# 方式一 C:\Users\zylia>redis-cli -a admin123 monitor OK 1498547986.670236 [0 127.0.0.1:63859] "AUTH" "admin123" 1498547986.670366 [0 127.0.0.1:63859] "GET" "hello" 1498548024.414979 [0 127.0.0.1:63869] "AUTH" "admin123" 1498548024.415185 [0 127.0.0.1:63869] "COMMAND" 1498548046.317448 [0 127.0.0.1:63872] "AUTH" "admin123" 1498548046.317742 [0 127.0.0.1:63872] "COMMAND" #方式二 登錄后在進行 coderknock> MONITOR OK 1498548046.317448 [0 127.0.0.1:63872] "AUTH" "admin123" 1498548046.317742 [0 127.0.0.1:63872] "COMMAND" #方式三 Telnet C:\Users\zylia>telnet 127.0.0.1 6379 auth admin123 +OK MONITOR +OK +1498548296.621530 [0 127.0.0.1:64068] "AUTH" "admin123" +1498548296.621658 [0 127.0.0.1:64068] "GET" "hello" # 支持同時開啟多個 MONITOR其他配置
tcp-keepalive：檢測TCP連接活性的周期，默認值為0，也就是不進行檢測，如果需要設置，建議為60，那么Redis會每隔60秒對它創建的TCP連接進行活性檢測，防止大量死連接占用系統資源。
-
tcp-backlog：TCP 三次握手后，會將接受的連接放入隊列中，tcpbacklog就是隊列的大小，它在 Redis 中的默認值是 511。通常來講這個參數不需要調整，但是這個參數會受到操作系統的影響，例如在Linux操作系統中，如果/proc/sys/net/core/somaxconn小于tcp-backlog，那么在Redis啟動時會看到如下日志，并建議將/proc/sys/net/core/somaxconn設置更大。
WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/ sys/net/core/somaxconn is set to the lower value of 128.
修改方法也非常簡單，只需要執行如下命令：
echo 511 > /proc/sys/net/core/somaxconn源碼查看
我們來看下 Redis 源碼中客戶端部分的內容：
typedef struct client {uint64_t id; /* Client incremental unique ID.客戶端增量惟一的ID */int fd; /* Client socket. 客戶端套接字*/redisDb *db; /* Pointer to currently SELECTed DB. 指向當前選擇的DB的指針*/robj *name; /* As set by CLIENT SETNAME. 由客戶端 SETNAME命令設置*/sds querybuf; /* Buffer we use to accumulate client queries. 用來累積客戶端查詢的緩沖區*/sds pending_querybuf; /* If this is a master, this buffer represents theyet not applied replication stream that weare receiving from the master.如果這是一個主服務器 ，這個緩沖區表示我們從主服務器接收到的未應用的復制流 */size_t querybuf_peak; /* Recent (100ms or more) peak of querybuf size.最近（100ms 或者更長時間）querybuf 的峰值大小 */int argc; /* Num of arguments of current command. 當前命令的參數個數*/robj **argv; /* Arguments of current command. 當前命令的參數*/struct redisCommand *cmd, *lastcmd; /* Last command executed. 最后一個被執行的命令*/int reqtype; /* Request protocol type: PROTO_REQ_* 請求協議類型：PROTO_REQ_**/int multibulklen; /* Number of multi bulk arguments left to read. 讀取的多批量參數的數量*/long bulklen; /* Length of bulk argument in multi bulk request. 多批量請求的批量參數的長度*/list *reply; /* List of reply objects to send to the client.發送給客戶端的應答對象列表（回復列表 有的翻譯也叫動態緩沖區） */unsigned long long reply_bytes; /* Tot bytes of objects in reply list. 對象個數（列表長度）*/size_t sentlen; /* Amount of bytes already sent in the currentbuffer or object being sent. 在當前的緩沖區或對象已經發送的字節數*/time_t ctime; /* Client creation time. 客戶端創建時間*/time_t lastinteraction; /* Time of the last interaction, used for timeout 最后一次交互的時間，用于超時 */time_t obuf_soft_limit_reached_time;int flags; /* Client flags: CLIENT_* macros. 客戶端標志使用的是 CLIENT_* 宏指令（下面會列出）*/int authenticated; /* When requirepass is non-NULL. 當 requirepass 不是 null 時會為變量賦值*/int replstate; /* Replication state if this is a slave. 復制狀態如果這是一個從機*/int repl_put_online_on_ack; /* Install slave write handler on ACK. */int repldbfd; /* Replication DB file descriptor. */off_t repldboff; /* Replication DB file offset. */off_t repldbsize; /* Replication DB file size. */sds replpreamble; /* Replication DB preamble. */long long read_reploff; /* Read replication offset if this is a master. */long long reploff; /* Applied replication offset if this is a master. */long long repl_ack_off; /* Replication ack offset, if this is a slave. */long long repl_ack_time;/* Replication ack time, if this is a slave. */long long psync_initial_offset; /* FULLRESYNC reply offset other slavescopying this slave output buffershould use. */char replid[CONFIG_RUN_ID_SIZE+1]; /* Master replication ID (if master). */int slave_listening_port; /* As configured with: SLAVECONF listening-port */char slave_ip[NET_IP_STR_LEN]; /* Optionally given by REPLCONF ip-address */int slave_capa; /* Slave capabilities: SLAVE_CAPA_* bitwise OR. */multiState mstate; /* MULTI/EXEC state */int btype; /* Type of blocking op if CLIENT_BLOCKED. */blockingState bpop; /* blocking state */long long woff; /* Last write global replication offset. */list *watched_keys; /* Keys WATCHED for MULTI/EXEC CAS */dict *pubsub_channels; /* channels a client is interested in (SUBSCRIBE) */list *pubsub_patterns; /* patterns a client is interested in (SUBSCRIBE) */sds peerid; /* Cached peer ID. *//* Response buffer 響應緩沖區（固定緩沖區）*/int bufpos;// 字節數組作為響應緩沖區 16K */char buf[PROTO_REPLY_CHUNK_BYTES];//#define PROTO_REPLY_CHUNK_BYTES (16*1024) /* 16k output buffer } client;Client flags
/* Client flags */ #define CLIENT_SLAVE (1<<0) /* This client is a slave server */ #define CLIENT_MASTER (1<<1) /* This client is a master server */ #define CLIENT_MONITOR (1<<2) /* This client is a slave monitor, see MONITOR */ #define CLIENT_MULTI (1<<3) /* This client is in a MULTI context */ #define CLIENT_BLOCKED (1<<4) /* The client is waiting in a blocking operation */ #define CLIENT_DIRTY_CAS (1<<5) /* Watched keys modified. EXEC will fail. */ #define CLIENT_CLOSE_AFTER_REPLY (1<<6) /* Close after writing entire reply. */ #define CLIENT_UNBLOCKED (1<<7) /* This client was unblocked and is stored inserver.unblocked_clients */ #define CLIENT_LUA (1<<8) /* This is a non connected client used by Lua */ #define CLIENT_ASKING (1<<9) /* Client issued the ASKING command */ #define CLIENT_CLOSE_ASAP (1<<10)/* Close this client ASAP */ #define CLIENT_UNIX_SOCKET (1<<11) /* Client connected via Unix domain socket */ #define CLIENT_DIRTY_EXEC (1<<12) /* EXEC will fail for errors while queueing */ #define CLIENT_MASTER_FORCE_REPLY (1<<13) /* Queue replies even if is master */ #define CLIENT_FORCE_AOF (1<<14) /* Force AOF propagation of current cmd. */ #define CLIENT_FORCE_REPL (1<<15) /* Force replication of current cmd. */ #define CLIENT_PRE_PSYNC (1<<16) /* Instance don't understand PSYNC. */ #define CLIENT_READONLY (1<<17) /* Cluster client is in read-only state. */ #define CLIENT_PUBSUB (1<<18) /* Client is in Pub/Sub mode. */ #define CLIENT_PREVENT_AOF_PROP (1<<19) /* Don't propagate to AOF. */ #define CLIENT_PREVENT_REPL_PROP (1<<20) /* Don't propagate to slaves. */ #define CLIENT_PREVENT_PROP (CLIENT_PREVENT_AOF_PROP|CLIENT_PREVENT_REPL_PROP) #define CLIENT_PENDING_WRITE (1<<21) /* Client has output to send but a writehandler is yet not installed. */ #define CLIENT_REPLY_OFF (1<<22) /* Don't send replies to client. */ #define CLIENT_REPLY_SKIP_NEXT (1<<23) /* Set CLIENT_REPLY_SKIP for next cmd */ #define CLIENT_REPLY_SKIP (1<<24) /* Don't send just this reply. */ #define CLIENT_LUA_DEBUG (1<<25) /* Run EVAL in debug mode. */ #define CLIENT_LUA_DEBUG_SYNC (1<<26) /* EVAL debugging without fork() */ #define CLIENT_MODULE (1<<27) /* Non connected client used by some module. */INFO
INFO
自1.0.0可用。
時間復雜度：O(1)。
語法：INFO [section]
說明：
INFO命令以一種易于理解和閱讀的格式，返回關于Redis服務器的各種信息和統計數值。
通過給定可選的參數 section ，可以讓命令只返回某一部分的信息:
server: Redis服務器的一般信息
clients: 客戶端的連接部分
memory: 內存消耗相關信息
persistence: RDB和AOF相關信息
stats: 一般統計
replication: 主/從復制信息
cpu: 統計CPU的消耗
commandstats: Redis命令統計
cluster: Redis集群信息
keyspace: 數據庫的相關統計
它也可以采取以下值:
all: 返回所有信息
default: 值返回默認設置的信息
如果沒有使用任何參數時，默認為default。
請注意不同Redis版本會添加或者刪除一些字段。一個健壯的客戶端應用解析該命令的結果時，應該跳過未知的字段，并且優雅的處理缺少的字段。
已下描述要求 Redis >= 2.4
下面是所有 server （記錄了 Redis 服務器的信息）相關的信息:
redis_version: Redis 服務器版本
redis_git_sha1: Git SHA1
redis_git_dirty: Git dirty flag
os: Redis 服務器的宿主操作系統
arch_bits: 架構（32 或 64 位）
multiplexing_api: Redis 所使用的事件處理機制
gcc_version: 編譯 Redis 時所使用的 GCC 版本
process_id: 服務器進程的 PID
run_id: Redis 服務器的隨機標識符（用于 Sentinel 和集群）
tcp_port: TCP/IP 監聽端口
uptime_in_seconds: 自 Redis 服務器啟動以來，經過的秒數
uptime_in_days: 自 Redis 服務器啟動以來，經過的天數
lru_clock: 以分鐘為單位進行自增的時鐘，用于 LRU 管理
下面是所有 clients（記錄了已連接客戶端的信息） 相關的信息:
connected_clients: 已連接客戶端的數量（不包括通過從屬服務器連接的客戶端）
client_longest_output_list: 當前連接的客戶端當中，最長的輸出列表
client_biggest_input_buf: 當前連接的客戶端當中，最大輸入緩存
blocked_clients: 正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客戶端的數量
下面是所有 memory （記錄了服務器的內存信息）相關的信息:
used_memory: 由 Redis 分配器分配的內存總量，以字節（byte）為單位
used_memory_human: 以人類可讀的格式返回 Redis 分配的內存總量
used_memory_rss: 從操作系統的角度，返回 Redis 已分配的內存總量（俗稱常駐集大小）。這個值和 top 、 ps 等命令的輸出一致。
used_memory_peak: Redis 的內存消耗峰值（以字節為單位）
used_memory_peak_human: 以人類可讀的格式返回 Redis 的內存消耗峰值
used_memory_lua: Lua 引擎所使用的內存大小（以字節為單位）
mem_fragmentation_ratio: used_memory_rss 和 used_memory 之間的比率
mem_allocator: 在編譯時指定的， Redis 所使用的內存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。 在理想情況下， used_memory_rss 的值應該只比 used_memory 稍微高一點兒。
當 rss > used ，且兩者的值相差較大時，表示存在（內部或外部的）內存碎片。
內存碎片的比率可以通過 mem_fragmentation_ratio 的值看出。
當 used > rss 時，表示 Redis 的部分內存被操作系統換出到交換空間了，在這種情況下，操作可能會產生明顯的延遲。
由于Redis無法控制其分配如何被映射到內存頁面，因此較高的 usedmemoryrss 通常是內存使用量激增的結果。
當 Redis 釋放內存時，分配器可能會，也可能不會，將內存返還給操作系統。
如果 Redis 釋放了內存，卻沒有將內存返還給操作系統，那么 used_memory 的值可能和操作系統顯示的 Redis 內存占用并不一致。
查看 used_memory_peak 的值可以驗證這種情況是否發生。
下面是所有 persistence （記錄了跟 RDB 持久化和 AOF 持久化有關的信息）相關的信息:
loading : 一個標志值，記錄了服務器是否正在載入持久化文件。
rdb_changes_since_last_save : 距離最近一次成功創建持久化文件之后，經過了多少秒。
rdb_bgsave_in_progress : 一個標志值，記錄了服務器是否正在創建 RDB 文件。
rdb_last_save_time : 最近一次成功創建 RDB 文件的 UNIX 時間戳。
rdb_last_bgsave_status : 一個標志值，記錄了最近一次創建 RDB 文件的結果是成功還是失敗。
rdb_last_bgsave_time_sec : 記錄了最近一次創建 RDB 文件耗費的秒數。
rdb_current_bgsave_time_sec : 如果服務器正在創建 RDB 文件，那么這個域記錄的就是當前的創建操作已經耗費的秒數。
aof_enabled : 一個標志值，記錄了 AOF 是否處于打開狀態。
aof_rewrite_in_progress : 一個標志值，記錄了服務器是否正在創建 AOF 文件。
aof_rewrite_scheduled : 一個標志值，記錄了在 RDB 文件創建完畢之后，是否需要執行預約的 AOF 重寫操作。
aof_last_rewrite_time_sec : 最近一次創建 AOF 文件耗費的時長。
aof_current_rewrite_time_sec : 如果服務器正在創建 AOF 文件，那么這個域記錄的就是當前的創建操作已經耗費的秒數。
aof_last_bgrewrite_status : 一個標志值，記錄了最近一次創建 AOF 文件的結果是成功還是失敗。
如果 AOF 持久化功能處于開啟狀態，那么這個部分還會加上以下字段：
aof_current_size : AOF 文件目前的大小。
aof_base_size : 服務器啟動時或者 AOF 重寫最近一次執行之后，AOF 文件的大小。
aof_pending_rewrite : 一個標志值，記錄了是否有 AOF 重寫操作在等待 RDB 文件創建完畢之后執行。
aof_buffer_length : AOF 緩沖區的大小。
aof_rewrite_buffer_length : AOF 重寫緩沖區的大小。
aof_pending_bio_fsync : 后臺 I/O 隊列里面，等待執行的 fsync 調用數量。
aof_delayed_fsync : 被延遲的 fsync 調用數量。
If a load operation is on-going, these additional fields will be added:
loading_start_time: Epoch-based timestamp of the start of the load operation
loading_total_bytes: Total file size
loading_loaded_bytes: Number of bytes already loaded
loading_loaded_perc: Same value expressed as a percentage
loading_eta_seconds: ETA in seconds for the load to be complete
下面是所有 stats（記錄了一般統計信息）相關的信息:
total_connections_received : 服務器已接受的連接請求數量。
total_commands_processed : 服務器已執行的命令數量。
instantaneous_ops_per_sec : 服務器每秒鐘執行的命令數量。
rejected_connections : 因為最大客戶端數量限制而被拒絕的連接請求數量。
expired_keys : 因為過期而被自動刪除的數據庫鍵數量。
evicted_keys : 因為最大內存容量限制而被驅逐（evict）的鍵數量。
keyspace_hits : 查找數據庫鍵成功的次數。
keyspace_misses : 查找數據庫鍵失敗的次數。
pubsub_channels : 目前被訂閱的頻道數量。
pubsub_patterns : 目前被訂閱的模式數量。
latest_fork_usec : 最近一次 fork() 操作耗費的毫秒數。
下面是所有 replication（主/從復制信息） 相關的信息:
role : 如果當前服務器沒有在復制任何其他服務器，那么這個域的值就是 master ；否則的話，這個域的值就是 slave。注意，在創建復制鏈的時候，一個從服務器也可能是另一個服務器的主服務器。
如果當前服務器是一個從服務器的話，那么這個部分還會加上以下字段：
master_host : 主服務器的 IP 地址。
master_port : 主服務器的 TCP 監聽端口號。
master_link_status : 復制連接當前的狀態， up 表示連接正常， down 表示連接斷開。
master_last_io_seconds_ago : 距離最近一次與主服務器進行通信已經過去了多少秒鐘。
master_sync_in_progress : 一個標志值，記錄了主服務器是否正在與這個從服務器進行同步。
如果同步操作正在進行，那么這個部分還會加上以下字段：
master_sync_left_bytes : 距離同步完成還缺少多少字節數據。
master_sync_last_io_seconds_ago : 距離最近一次因為 SYNC 操作而進行 I/O 已經過去了多少秒。
如果主從服務器之間的連接處于斷線狀態，那么這個部分還會加上以下字段：
master_link_down_since_seconds : 主從服務器連接斷開了多少秒。
以下是一些總會出現的字段：
connected_slaves : 已連接的從服務器數量。
對于每個從服務器，都會添加以下一行信息：
slaveXXX : ID、IP 地址、端口號、連接狀態
下面是所有 cpu 相關的信息:
used_cpu_sys : Redis 服務器耗費的系統 CPU 。
used_cpu_user : Redis 服務器耗費的用戶 CPU 。
used_cpu_sys_children : 后臺進程耗費的系統 CPU 。
used_cpu_user_children : 后臺進程耗費的用戶 CPU 。
-
commandstats 部分記錄了各種不同類型的命令的執行統計信息，比如命令執行的次數、命令耗費的 CPU 時間、執行每個命令耗費的平均 CPU 時間等等。對于每種類型的命令，這個部分都會添加一行以下格式的信息：
cmdstat_XXX:calls=XXX,usec=XXX,usecpercall=XXX
-
cluster 部分記錄了和集群有關的信息，它包含以下域：
cluster_enabled : 一個標志值，記錄集群功能是否已經開啟。
-
keyspace 部分記錄了數據庫相關的統計信息，比如數據庫的鍵數量、數據庫已經被刪除的過期鍵數量等。對于每個數據庫，這個部分都會添加一行以下格式的信息：
dbXXX:keys=XXX,expires=XXX
除上面給出的這些值以外， section 參數的值還可以是下面這兩個：
all : 返回所有信息
default : 返回默認選擇的信息
返回值：
具體請參見下面的測試代碼。
示例：
coderknock> INFO # Server redis_version:3.2.100 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:dd26f1f93c5130ee redis_mode:standalone os:Windows arch_bits:64 multiplexing_api:WinSock_IOCP process_id:19944 run_id:472a23ff45a04eb3081b48078a0c619c26376ddf tcp_port:6379 uptime_in_seconds:268 uptime_in_days:0 hz:10 lru_clock:5378046 executable:D:\redis\redis-server.exe config_file:D:\redis\redis.windows.conf# Clients connected_clients:1 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0# Memory used_memory:711792 used_memory_human:695.11K used_memory_rss:674008 used_memory_rss_human:658.21K used_memory_peak:787952 used_memory_peak_human:769.48K total_system_memory:0 total_system_memory_human:0B used_memory_lua:37888 used_memory_lua_human:37.00K maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction mem_fragmentation_ratio:0.95 mem_allocator:jemalloc-3.6.0# Persistence loading:0 rdb_changes_since_last_save:0 rdb_bgsave_in_progress:0 rdb_last_save_time:1498550002 rdb_last_bgsave_status:ok rdb_last_bgsave_time_sec:-1 rdb_current_bgsave_time_sec:-1 aof_enabled:0 aof_rewrite_in_progress:0 aof_rewrite_scheduled:0 aof_last_rewrite_time_sec:-1 aof_current_rewrite_time_sec:-1 aof_last_bgrewrite_status:ok aof_last_write_status:ok# Stats total_connections_received:2 total_commands_processed:6 instantaneous_ops_per_sec:0 total_net_input_bytes:165 total_net_output_bytes:11895644 instantaneous_input_kbps:0.02 instantaneous_output_kbps:2286.67 rejected_connections:0 sync_full:0 sync_partial_ok:0 sync_partial_err:0 expired_keys:0 evicted_keys:0 keyspace_hits:1 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:0 migrate_cached_sockets:0# Replication role:master connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0# CPU used_cpu_sys:0.20 used_cpu_user:0.11 used_cpu_sys_children:0.00 used_cpu_user_children:0.00# Cluster cluster_enabled:0# Keyspace db0:keys=43,expires=0,avg_ttl=0 db1:keys=3,expires=0,avg_ttl=0我是廣告
本人的直播課程在 7 月份就要開始了，希望小伙伴們支持一下，現在報名有優惠噢
https://segmentfault.com/l/15...
https://segmentfault.com/l/15...
總結
以上是生活随笔為你收集整理的Redis 服务器管理相关命令的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 反射常用API
- 下一篇： 【FTP】java FTPClient