Redis Shell

時間 2019-11-07

標籤 redis shell 欄目 Redis 简体版

原文原文鏈接

Redis提供了redis-cli、redis-server、redis-benchmark等Shell工具。它們雖然比較簡單，可是麻雀雖小五臟俱全，有時能夠很巧妙地解決一些問題。redis

redis-cli詳解

用法：redis-cli [OPTIONS][cmd [arg [arg ...]]]

可選項：

可選項	說明
`-h` `<hostname>`	服務端 hostname （默認 127.0.0.1）
`-p` `<port>`	服務端端口（默認 6379）
`-s` `<socket>`	服務端 socket （會覆蓋 -h -p 設置的內容）
`-a` `<password>`	密碼（密碼錯誤之類不會直接保錯，而是在操做時纔會保錯，這時可使用 Redis 的 `AUTH` 命令再次認證）
`-r` `<repeat>`	重複執行特定命令 repeat 次
`-i` `<interval>`	每隔幾秒執行一次，-i 必須與 -r 同時使用，-r 設置的是執行的總次數
`-n <db>`	選擇操做的數據庫，至關於在進入客戶端後使用 `SELECT` 命令
`-x`	-x選項表明從標準輸入（stdin）讀取數據做爲 redis-cli 的最後一個參數
`-d` `<delimiter>`	多行語句分隔符設定（默認 n）
`-c`	-c（cluster）選項是鏈接 Redis Cluster 節點時須要使用的，-c選項能夠防止moved和ask異常。
`--raw`	返回結果必須是原始的格式
`--noraw`	返回格式化後的結果
`--csv`	輸出使用 CSV 格式
`--stat`	滾動打印關於服務端中內存、客戶端等統計信息
`--latency`	進入一個特殊模式連續顯示客戶端到目標 Redis 的網絡延遲信息。
`--latency-history`	與 --latency 相似可是隨着時間的推移跟蹤延遲的變化。迭代時間默認是 15 秒可使用 -i 參數進行設置。
`--latency-dist`	終端 256 色譜的方式顯示延時信息。迭代時間默認是 1 秒可使用 -i 參數進行設置。
`--lru-test` `<keys>`	模擬 LRU 算法的一個二八分佈的緩存的工做量
`--slave`	把當前客戶端模擬成當前 Redis 節點的從節點，能夠用來獲取當前Redis 節點的更新操做。合理的利用這個選項能夠記錄當前鏈接Redis節點的一些更新操做，這
`--rdb` `<filename>`	會請求 Redis 實例生成併發送 RDB 持久化文件，保存在本地。
`--pipe`	用於將命令封裝成Redis通訊協議定義的數據格式，批量發送給 Redis 執行。
`--pipe-timeout <n>`	相似 `--pipe` 只是添加了一個超時處理
`--bigkeys`	使用`SCAN`命令對 Redis 的鍵進行採樣，從中找到內存佔用比較大的鍵值。這些鍵多是系統的瓶頸，經過該命令咱們能夠找到這些瓶頸。
`--scan`	使用 `SCAN` 命令查詢全部 key
`--pattern` `<pat>`	配合 --scan 命令掃描指定模式的鍵
`--intrinsic-latency` `<sec>`	運行一個測試來衡量內在的系統延遲。測試將運行指定的秒。
`--eval` `<file>`	發送一個 EVAL 命令執行 `<file>` 中的 Lua 腳本
`--ldb`	配合 --eval 使用，容許調試 Redis 中的 Lua 腳本
`--ldb-sync-mode`	像 --ldb 採用同步的 Lua 調試器，在這種模式下，服務端將會阻塞，腳本改變的內容是不會從服務端內存回滾的。
`--help`	輸出幫助信息並退出能夠簡化爲 -h
`--version`	輸出 Redis 版本信息並退出能夠簡化爲 -v

示例：

# 在命令行工具中直接 SET 一個 incrTest 
coderknock:CMD> redis-cli -a admin123 SET incrTest 0
# 循環 5 次 爲 incrTest 自增
coderknock:CMD> redis-cli -a admin123 -r 5 INCR incrTest
(integer) 1
(integer) 2
(integer) 3
(integer) 4
(integer) 5
coderknock:CMD>redis-cli -a admin123 GET incrTest
"5"

coderknock:CMD> redis-cli -a admin123 -r 5 INCR incrTest
(integer) 1
(integer) 2
(integer) 3
(integer) 4
(integer) 5

`-i <interval>` 的使用：

`-x` 的使用：

# 注意這裏的 SET 最後沒有指定值
coderknock:CMD>echo "hello" | redis-cli -a admin123 -x GET lastStdin
OK
coderknock:CMD> redis-cli -a admin123 GET lastStdin
"\"hello\" \n"
coderknock:CMD>

`--raw` 使用：

coderknock:CMD>redis-cli -a admin123   --raw
127.0.0.1:6379> KEYS *
中文
lastStdin
zSet
s1
incrTest
set
coderknock:CMD>redis-cli -a admin123
# 這裏第一個 key 中文是亂碼的
127.0.0.1:6379> KEYS *
1) "\xd6\xd0\xce\xc4"
2) "lastStdin"
3) "zSet"
4) "s1"
5) "incrTest"
6) "set"

`--csv` 使用：

coderknock:CMD>redis-cli -a admin123  --csv
127.0.0.1:6379> KEYS *
"\xd6\xd0\xce\xc4","lastStdin","zSet","s1","incrTest","set"
# 下面的示例說明 -- 參數只有最後一個生效
coderknock:CMD>redis-cli -a admin123  --csv --raw
127.0.0.1:6379> KEYS *
中文
lastStdin
zSet
s1
incrTest
set
coderknock:CMD>redis-cli -a admin123  --csv --no-raw
127.0.0.1:6379> KEYS *
1) "\xd6\xd0\xce\xc4"
2) "lastStdin"
3) "zSet"
4) "s1"
5) "incrTest"
6) "set"
coderknock:CMD>redis-cli -a admin123   --no-raw --csv
127.0.0.1:6379> KEYS *
"\xd6\xd0\xce\xc4","lastStdin","zSet","s1","incrTest","set"

`--stat` 使用：

`--latency` 使用：

`--latency-history` 與 `--latency` 相似，可是每隔一段時間會記錄一次：

`--latency-dist` 使用（第一張是 Windows 顯示，沒有效果，第二張是 Linux 下有顏色效果）：

--latency-dist 使用 (Windows)：算法

--latency-dist 使用 (Linux)：shell

`--lru-test` 使用：

`--intrinsic-latency <sec>` 使用：

`--bigkeys` 使用：

coderknock:CMD>redis-cli -a admin123 --bigkeys

# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).

[00.00%] Biggest string found so far 'lastStdin' with 9 bytes
[00.00%] Biggest set    found so far 'set' with 3 members
[00.00%] Biggest zset   found so far 'zSet' with 2 members

-------- summary -------

Sampled 8 keys in the keyspace!
Total key length in bytes is 40 (avg len 5.00)

Biggest string found 'lastStdin' has 9 bytes
Biggest    set found 'set' has 3 members
Biggest   zset found 'zSet' has 2 members

6 strings with 24 bytes (75.00% of keys, avg size 4.00)
0 lists with 0 items (00.00% of keys, avg size 0.00)
1 sets with 3 members (12.50% of keys, avg size 3.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
1 zsets with 2 members (12.50% of keys, avg size 2.00)

`--scan` 使用：

coderknock:CMD>redis-cli -a admin123 --scan
lastStdin
set
zSet
s1
incrTest
Test
ￖ￐ￎￄ
lru:0

`--scan` 配合 `--pattern` 使用：

coderknock:CMD>redis-cli -a admin123 --scan  in*
incrTest

`--version (-v)` 使用：

coderknock:CMD>redis-cli -a admin123 --version
redis-cli 3.2.100

`--help (-h)` 使用：

coderknock:CMD>redis-cli -a admin123 --help
redis-cli 3.2.100

Usage: redis-cli [OPTIONS] [cmd [arg [arg ...]]]
  -h <hostname>      Server hostname (default: 127.0.0.1).
  -p <port>          Server port (default: 6379).
  -s <socket>        Server socket (overrides hostname and port).
  -a <password>      Password to use when connecting to the server.
  -r <repeat>        Execute specified command N times.
  -i <interval>      When -r is used, waits <interval> seconds per command.
                     It is possible to specify sub-second times like -i 0.1.
  -n <db>            Database number.
  -x                 Read last argument from STDIN.
  -d <delimiter>     Multi-bulk delimiter in for raw formatting (default: \n).
  -c                 Enable cluster mode (follow -ASK and -MOVED redirections).
  --raw              Use raw formatting for replies (default when STDOUT is
                     not a tty).
  --no-raw           Force formatted output even when STDOUT is not a tty.
  --csv              Output in CSV format.
  --stat             Print rolling stats about server: mem, clients, ...
  --latency          Enter a special mode continuously sampling latency.
  --latency-history  Like --latency but tracking latency changes over time.
                     Default time interval is 15 sec. Change it using -i.
  --latency-dist     Shows latency as a spectrum, requires xterm 256 colors.
                     Default time interval is 1 sec. Change it using -i.
  --lru-test <keys>  Simulate a cache workload with an 80-20 distribution.
  --slave            Simulate a slave showing commands received from the master.
  --rdb <filename>   Transfer an RDB dump from remote server to local file.
  --pipe             Transfer raw Redis protocol from stdin to server.
  --pipe-timeout <n> In --pipe mode, abort with error if after sending all data.
                     no reply is received within <n> seconds.
                     Default timeout: 30. Use 0 to wait forever.
  --bigkeys          Sample Redis keys looking for big keys.
  --scan             List all keys using the SCAN command.
  --pattern <pat>    Useful with --scan to specify a SCAN pattern.
  --intrinsic-latency <sec> Run a test to measure intrinsic system latency.
                     The test will run for the specified amount of seconds.
  --eval <file>      Send an EVAL command using the Lua script at <file>.
  --ldb              Used with --eval enable the Redis Lua debugger.
  --ldb-sync-mode    Like --ldb but uses the synchronous Lua debugger, in
                     this mode the server is blocked and script changes are
                     are not rolled back from the server memory.
  --help             Output this help and exit.
  --version          Output version and exit.

Examples:
  cat /etc/passwd | redis-cli -x set mypasswd
  redis-cli get mypasswd
  redis-cli -r 100 lpush mylist x
  redis-cli -r 100 -i 1 info | grep used_memory_human:
  redis-cli --eval myscript.lua key1 key2 , arg1 arg2 arg3
  redis-cli --scan --pattern '*:12345*'

  (Note: when using --eval the comma separates KEYS[] from ARGV[] items)

When no command is given, redis-cli starts in interactive mode.
Type "help" in interactive mode for information on available commands
and settings.

redis-server 詳解

redis-server 除了啓動 Redis 外，還有一個--test-memory 選項。redis-server --test-memory 能夠用來檢測當前操做系統可否穩定地分配指定容量的內存給Redis，經過這種檢測能夠有效避免由於內存問題形成Redis崩潰，例以下面操做檢測當前操做系統可否提供1G的內存給 Redis：數據庫

redis-server --test-memory 1024

整個內存檢測的時間比較長（我測試時使用的實際超出一個小時）。當輸出 passed this test 時說明內存檢測完畢，最後會提示 --test-memory 只是簡單檢測，若是質疑可使用更加專業的內存檢測工具，下面是我測試的結果：segmentfault

Your memory passed this test.
Please if you are still in doubt use the following two tools:
1) memtest86: http://www.memtest86.com/
2) memtester: http://pyropus.ca/software/memtester/

redis-benchmark詳解

redis-benchmark 能夠爲 Redis 作基準性能測試。緩存

用法 `redis-benchmark [-h <host>][-p ] [-c <clients>][-n ]> [-k <boolean>]`

選項：

選項	說明
`-h <hostname>`	服務端 hostname （默認 127.0.0.1）
`-p <port>`	服務端端口（默認 6379）
`-s <socket>`	服務端 socket （會覆蓋 -h -p 設置的內容）
`-a <password>`	密碼（密碼錯誤之類不會直接保錯，而是在操做時纔會保錯，這時可使用 Redis 的 AUTH 命令再次認證）
`-c <clients>`	客戶端的併發數量（默認是50）
`-n <requests>`	客戶端請求總量（默認是100000）
`-d <size>`	使用 SET/GET 添加的數據的字節大小 (默認 2)
`-dbnum <db>`	選擇一個數據庫進行測試 (默認 0)
`-k <boolean>`	客戶端是否使用keepalive，1爲使用，0爲不使用，（默認爲 1）
`-r <keyspacelen>`	使用 SET/GET/INCR 命令添加數據 key, SADD 添加隨機數據，keyspacelen 指定的是添加鍵的數量
`-P <numreq>`	每一個請求 pipeline 的數據量（默認爲1，沒有 pipeline ）
`-q`	僅僅顯示redis-benchmark的requests per second信息
`--csv`	將結果按照csv格式輸出，便於後續處理
`-l`	循環測試
`-t <tests>`	能夠對指定命令進行基準測試
`-I`	Idle mode. Just open N idle connections and wait.

`redis-benchmark -c 100 -n 20000`

redis-benchmark -c 100 -n 20000 表明100各個客戶端同時請求 Redis，一
共執行 20000 次。redis-benchmark會對各種數據結構的命令進行測試，並給
出性能指標：服務器

下面咱們詳細介紹性能測試的報告內容：網絡

coderknock:CMD>redis-benchmark -c 100 -n 20000
# 執行的測試命令
====== PING_INLINE ======
  # 這裏說明 在 0.62 秒內完成了 20000 ping 請求
  20000 requests completed in 0.62 seconds
  # 100 個併發客戶端
  100 parallel clients
  # 每一個請求數據量是3個字節
  3 bytes payload
  keep alive: 1
  
# 小於等於指定毫秒數的比率
0.01% <= 1 milliseconds
0.08% <= 2 milliseconds
50.30% <= 3 milliseconds
99.19% <= 4 milliseconds
99.85% <= 5 milliseconds
99.92% <= 6 milliseconds
99.97% <= 7 milliseconds
100.00% <= 7 milliseconds

#每秒處理命令數量
32154.34 requests per second

`-q` 使用

coderknock:CMD>redis-benchmark -c 100 -n 20000  -q
PING_INLINE: 32206.12 requests per second
PING_BULK: 32310.18 requests per second
SET: 32362.46 requests per second
GET: 32679.74 requests per second
INCR: 24539.88 requests per second
LPUSH: 32102.73 requests per second
RPUSH: 32679.74 requests per second
LPOP: 32840.72 requests per second
RPOP: 32733.22 requests per second
SADD: 31746.03 requests per second
SPOP: 31796.50 requests per second
LPUSH (needed to benchmark LRANGE): 29368.58 requests per second
LRANGE_100 (first 100 elements): 27932.96 requests per second
LRANGE_300 (first 300 elements): 32051.28 requests per second
LRANGE_500 (first 450 elements): 32573.29 requests per second
LRANGE_600 (first 600 elements): 32102.73 requests per second
MSET (10 keys): 31595.58 requests per second

`-t` `--csv` 使用

# 沒有設置客戶端以及併發數，這裏會使用默認的數值
coderknock:CMD>redis-benchmark -t get,set --csv
"SET","31595.58"
"GET","31796.50"

使用 pipelining

默認狀況下，每一個客戶端都是在一個請求完成以後才發送下一個請求（benchmark 會模擬 50 個客戶端除非使用 -c 指定特別的數量），這意味着服務器幾乎是按順序讀取每一個客戶端的命令。Also RTT is payed as well.
真實世界會更復雜，Redis 支持 /topics/pipelining，使得能夠一次性執行多條命令成爲可能。 Redis pipelining 能夠提升服務器的 TPS。使用 pipelining 組織 16 條命令的測試範例：數據結構

coderknock:CMD>redis-benchmark -n 1000000 -t set,get -P 16 -q
SET: 448631.66 requests per second
GET: 443655.72 requests per second

影響 Redis 性能的因素

有幾個因素直接決定 Redis 的性能。它們可以改變基準測試的結果，因此咱們必須注意到它們。通常狀況下，Redis 默認參數已經能夠提供足夠的性能，不須要調優。併發

網絡帶寬和延遲一般是最大短板。建議在基準測試以前使用 ping 來檢查服務端到客戶端的延遲。根據帶寬，能夠計算出最大吞吐量。好比將 4 KB 的字符串塞入 Redis，吞吐量是 100000 q/s，那麼實際須要 3.2 Gbits/s 的帶寬，因此須要 10 GBits/s 網絡鏈接， 1 Gbits/s 是不夠的。在不少線上服務中，Redis 吞吐會先被網絡帶寬限制住，而不是 CPU。爲了達到高吞吐量突破 TCP/IP 限制，最後採用 10 Gbits/s 的網卡，或者多個 1 Gbits/s 網卡。
CPU 是另一個重要的影響因素，因爲是單線程模型，Redis 更喜歡大緩存快速 CPU，而不是多核。這種場景下面，比較推薦 Intel CPU。AMD CPU 可能只有 Intel CPU 的一半性能（經過對 Nehalem EP/Westmere EP/Sandy 平臺的對比）。當其餘條件至關時候，CPU 就成了 redis-benchmark 的限制因素。
在小對象存取時候，內存速度和帶寬看上去不是很重要，可是對大對象（> 10 KB），它就變得重要起來。不過一般狀況下面，倒不至於爲了優化 Redis 而購買更高性能的內存模塊。
Redis 在 VM 上會變慢。虛擬化對普通操做會有額外的消耗，Redis 對系統調用和網絡終端不會有太多的 overhead。建議把 Redis 運行在物理機器上，特別是當你很在乎延遲時候。在最早進的虛擬化設備（VMWare）上面，redis-benchmark 的測試結果比物理機器上慢了一倍，不少 CPU 時間被消費在系統調用和中斷上面。
若是服務器和客戶端都運行在同一個機器上面，那麼 TCP/IP loopback 和 unix domain sockets 均可以使用。對 Linux 來講，使用 unix socket 能夠比 TCP/IP loopback 快 50%。默認 redis-benchmark 是使用 TCP/IP loopback。當大量使用 pipelining 時候，unix domain sockets 的優點就不那麼明顯了。
當使用網絡鏈接時，而且以太網網數據包在 1500 bytes 如下時，將多條命令包裝成 pipelining 能夠大大提升效率。事實上，處理 10 bytes，100 bytes， 1000 bytes 的請求時候，吞吐量是差很少的，詳細能夠見下圖。

在多核 CPU 服務器上面，Redis 的性能還依賴 NUMA 配置和處理器綁定位置。最明顯的影響是 redis-benchmark 會隨機使用 CPU 內核。爲了得到精準的結果，須要使用固定處理器工具（在 Linux 上可使用 taskset 或 numactl）。最有效的辦法是將客戶端和服務端分離到兩個不一樣的 CPU 來高校使用三級緩存。這裏有一些使用 4 KB 數據 SET 的基準測試，針對三種 CPU（AMD Istanbul, Intel Nehalem EX，和 Intel Westmere）使用不一樣的配置。請注意，這不是針對 CPU 的測試。

在高配置下面，客戶端的鏈接數也是一個重要的因素。得益於 epoll/kqueue， Redis 的事件循環具備至關可擴展性。Redis 已經在超過 60000 鏈接下面基準測試過，仍然能夠維持 50000 q/s。一條經驗法則是，30000 的鏈接數只有 100 鏈接的一半吞吐量。下面有一個關於鏈接數和吞吐量的測試。

在高配置下面，能夠經過調優 NIC 來得到更高性能。最高性能在綁定 Rx/Tx 隊列和 CPU 內核下面才能達到，還須要開啓 RPS（網卡中斷負載均衡）。更多信息能夠在 thread 。Jumbo frames 還能夠在大對象使用時候得到更高性能。
在不一樣平臺下面，Redis 能夠被編譯成不一樣的內存分配方式（libc malloc, jemalloc, tcmalloc），他們在不一樣速度、連續和非連續片斷下會有不同的表現。若是你不是本身編譯的 Redis，可使用 INFO 命令來檢查內存分配方式。請注意，大部分基準測試不會長時間運行來感知不一樣分配模式下面的差別，只能經過生產環境下面的 Redis 實例來查看。