Redis深刻系列-0x012：redis-cli--Redis命令行接口（下）

0x001 特殊模式概述

目前爲止，咱們使用了redis-cli兩種主要模式:

• 使用命令行執行Redis命令
• 類REPL交互模式

下一章節將會解釋Redis怎樣執行其餘輔助任務：

• 持續監控Redis狀態的監控工具
• 大致積key搜索
• key模糊匹配搜索
• 像發佈/訂閱客戶端同樣訂閱通道
• 監控Redis實例執行的全部命令
• 用不一樣的方式檢測延遲
• 檢查本地系統的調度延遲
• 從遠程Redis實例傳輸RDB備份到本地
• 扮演Redis slave角色，顯示slave接收到了什麼命令
• 模擬LRU工做演示key命中
• 一個lua調試客戶端

0x002 持續監控狀態模式

這多是redis-cli其中一個不多人知道的特性了，一個實時監控Redis實例的工具。能夠經過--stat選項來啓用它，這種模式中能夠很清楚的看到redis-cli的行爲：

$ redis-cli --stat
------- data ------ --------------------- load -------------------- - child -
keys       mem      clients blocked requests            connections
506        1015.00K 1       0       24 (+0)             7
506        1015.00K 1       0       25 (+1)             7
506        3.40M    51      0       60461 (+60436)      57
506        3.40M    51      0       146425 (+85964)     107
507        3.40M    51      0       233844 (+87419)     157
507        3.40M    51      0       321715 (+87871)     207
508        3.40M    51      0       408642 (+86927)     257
508        3.40M    51      0       497038 (+88396)     257

這種模式中，每一秒就會輸出一次很是有用的信息，經過這些信息你能夠很簡單的就知道內存佔用、客戶端鏈接等信息。

-i <interval>選項能夠指定多長時間輸出一次，默認1秒。

0x003 大致積key掃描

在這種模式中，redis-cli分析key的空間，他在掃描大致積key的同時也提供了關於組成數據庫的數據類型的信息。可使用--bigkeys來啓用它：

$ redis-cli --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 'key-419' with 3 bytes
[05.14%] Biggest list   found so far 'mylist' with 100004 items
[35.77%] Biggest string found so far 'counter:__rand_int__' with 6 bytes
[73.91%] Biggest hash   found so far 'myobject' with 3 fields

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

Sampled 506 keys in the keyspace!
Total key length in bytes is 3452 (avg len 6.82)

Biggest string found 'counter:__rand_int__' has 6 bytes
Biggest   list found 'mylist' has 100004 items
Biggest   hash found 'myobject' has 3 fields

504 strings with 1403 bytes (99.60% of keys, avg size 2.78)
1 lists with 100004 items (00.20% of keys, avg size 100004.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
1 hashs with 3 fields (00.20% of keys, avg size 3.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)

在輸出的第一部分，報告中相同類型下的每一個新的的key體積都大於上一個大致積key。summary部分提供了Redis實例中數目的基本信息

這個模式使用SCAN命令，因此他能夠直接執行而不影響Redis實例的運行狀態，固然-i選項能夠經過指定秒的小數來限制每100個key掃描的進程數。好比，-i 0.1將會極大的放慢掃描速度，可是將會較少服務器負載到一個很小的程度。

注意summary也提供了一個格式清晰的報告來顯示它找打的大致積key。若是在一個大數據集中使用這個命令，初始的輸出只提供了一些有趣的信息。

0x005 獲取key列表

在使用像KEYS *的時候將會阻塞Redis服務端，固然在不阻塞Redis服務端的同時掃描key空間也是能夠作到的，它能夠答應出全部的key的名稱，甚至能夠指定模式匹配。這種模式中，像--bigkeys選項，使用SCAN命令，若是數據集一直在改變，key可能會屢次的出現，可是隻要key在開始遍歷的時候存在，就不會被遺漏。由於這個命令使用的選項叫作--scan

$ redis-cli --scan | head -10
key-419
key-71
key-236
key-50
key-38
key-458
key-453
key-499
key-446
key-371

注意head -10是爲了獲取頭10個key

能夠經過 --pattern選項來啓用模糊匹配

$ redis-cli --scan --pattern '*-11*'
key-114
key-117
key-118
key-113
key-115
key-112
key-119
key-11
key-111
key-110
key-116

管道輸出到wc命令能夠用來統計指定類型的對象的數量：

$ redis-cli --scan --pattern 'user:*' | wc -l
3829433

0x006 發佈/訂閱模式

redis-cli可以使用PUBLISH命令在Redis發佈/訂閱通道中發佈消息。PUBLISH命令的使用和其餘命令很像。可是爲了接受消息而去訂閱通道--這種狀況下咱們要阻塞並等待消息，因此這是redis-cli的一種特俗模式。這個模式不像其餘特殊模式同樣經過其餘特殊的選項啓用，只是簡單的使用SUBSCRIBE或者PSUBSCRIBE命令，在交互模式或者非交互模式均可以使用

$ redis-cli psubscribe '*'
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "*"
3) (integer) 1

Reading messages...標誌咱們進入了發佈/訂閱模式。當其餘客戶端在通道中發佈消息的時候，好比你可使用redis-cli執行PUBLISH mychannel mymessage，發佈訂閱模式下的命令行窗口將會顯示一些信息：

1) "pmessage"
2) "*"
3) "mychannel"
4) "mymessage"

這對於調試發佈/訂閱模式很是有益，退出這種模式能夠按CTRL-C

0x007 監控Redis中執行的命令

和發佈訂閱模式很想，你使用MOBITOR模式將會自動進入這個監控模式，它將會輸出Redis接收到的全部命令。

$ redis-cli monitor
OK
1460100081.165665 [0 127.0.0.1:51706] "set" "foo" "bar"
1460100083.053365 [0 127.0.0.1:51707] "get" "foo"

注意：這裏可使用管道操做符重定向結果，因此你可使用相似grep的工具去監控指定模式的命令。

0x008 監控Redis實例的延遲

redis對延遲是很是挑剔的，延遲涉及到應用中很是多的可移動部分，從客戶端庫到網絡棧，再到Redis實例自己。

redis-cli有不少機制能夠知道Redis實例的延遲的最大值、平均值和分配
最基本的延遲檢測工具是--latency選項，使用這個選項將會不停的發送PING命令到Redis實例，返回的時間將會被統計。每秒100次的時候，狀態實時更新在控制檯將會以下顯示：

$ redis-cli --latency
min: 0, max: 1, avg: 0.19 (427 samples)

這個狀態的單位是毫秒。一般狀況下，在一個很是快的實例中，平均延遲是被過度估計的，由於言辭取決於系統運行redis-cli自身的內核調度，因此0.19的平均延遲能夠看作是0.01或者更低。無論如何，這一般不是什麼大問題，咱們一般關心幾毫秒或者更多。

有時候咱們更關心最大延遲和平均延遲隨着時間是如何變化的，--latency-history選項提供給咱們這種實現：他運行的像--latency，可是默認狀況下每15s，新的對話將會被抓取：

$ redis-cli --latency-history
min: 0, max: 1, avg: 0.14 (1314 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.18 (1299 samples) -- 15.00 seconds range
min: 0, max: 1, avg: 0.20 (113 samples)^C

你能夠經過-i <interval>選項來修改每次對話抓取的時間

大多數高級的延遲分析工具，都很是努力的像沒有經驗的用戶展現一個帶有顏色的頻譜圖。你能夠看到被顏色渲染的輸入顯示了不一樣示例的百分比，不一樣的ASCII字符來表示不一樣的延遲圖像。能夠經過--latency-dist選項來使用：

$ redis-cli --latency-dist

這是redis-cli中另外一個很是漂亮的不經常使用的延遲工具。他不檢測redis-cli實例的延遲，它檢測的是你運行redis-cli電腦的延遲，若是你要問什麼延遲？這延遲是內核調度固有的延遲，虛擬架構實例的管理程序等。

咱們叫它固有延遲是由於他對開發者是不透明的，一般狀況下，你排除了全部的可觀察的緣由，可是你的Redis實例依舊有很高的延遲，那基本就是固有延遲引發的，在你運行Redis服務端的電腦上，運行這個特殊的模式是很是有意義的。

經過測量固有延遲，你將會知道基線在哪裏，Redis不可能超過你的系統。--intrinsic-latency <test-time>選項能夠啓動這種模式，<test-time>單位是秒：

$ ./redis-cli --intrinsic-latency 5
Max latency so far: 1 microseconds.
Max latency so far: 7 microseconds.
Max latency so far: 9 microseconds.
Max latency so far: 11 microseconds.
Max latency so far: 13 microseconds.
Max latency so far: 15 microseconds.
Max latency so far: 34 microseconds.
Max latency so far: 82 microseconds.
Max latency so far: 586 microseconds.
Max latency so far: 739 microseconds.

65433042 total runs (avg latency: 0.0764 microseconds / 764.14 nanoseconds per run).
Worst run took 9671x longer than the average latency.

重要：這個命令必須運行在你想要運行Redis服務端的電腦上，而不是其餘主機，它不會連接到Redis實例，只會測試本地。
在上面的例子中，我係統的最高延遲是739微妙，因此我能夠肯定每次執行的延遲不會高於1毫秒

0x009 遠程備份RDB文件

當Redis複製集第一次同步時，主從雙機經過RDB文件交換數據集。這個特性利用redis-cli提供一個遠程備份機制，容許從Redis傳輸RDB文件到本地。使用這個模式，可使用--rdb <dest-filename>參數：

$ redis-cli --rdb /tmp/dump.rdb
SYNC sent to master, writing 13256 bytes to '/tmp/dump.rdb'
Transfer finished with success.

這是一個保證你有從你的Redis實例作災難恢復RDB備份的簡單且行之有效的方式。當在腳本或者cron使用這個選項時候，請檢查命令的返回值適不適合0，若是不是0，說明有錯誤發生：

$ redis-cli --rdb /tmp/dump.rdb
SYNC with master failed: -ERR Can't SYNC while not connected with my master
$ echo $?
1

0x010 slave模式

Slave mode
對於Redis開發者和調試操做來講，從模式是一個高級特性。它容許查看一個master在複製流傳輸的時候給他的slave發送了什麼。可使用--slave來啓用它：

$ redis-cli --slave
SYNC with master, discarding 13256 bytes of bulk transfer...
SYNC done. Logging commands from master.
"PING"
"SELECT","0"
"set","foo","bar"
"PING"
"incr","mycounter"

這個命令一開始先拋棄了第一次同步的RDB文件，接着以CSV格式記錄每一次收到的命令。
若是你發現並非全部的命令都正確的複製到你的slave機子上，這將是一個檢查錯誤很是好的方式，對於改善bug發現也是很是有用的信息。

0x011 執行 LRU 模擬器

Redis常常被用來作LRU緩存回收。取決於key的數量和爲緩存申請的內存總量（經過maxmemory指定），緩存命中和緩存失效的總量將會改變。有時，模擬命中率是正確提供緩存很是有效的方式。

redis-cli提供了一個特俗的方式去執行一個GET和SET的模擬操做，用80%-20%的請求比例分佈。這意味着20%的key將會在80%的請求內被請求，這在緩存方案中是一個很常見的分佈。

從理論上講，給Redis的請求分發達到Redis的內存峯值，就可能在數理上算出命中率。然而Redis能夠配置不一樣的LRU設置(數量或者示例)和LRU的執行，這幾乎在Redis中，每一個版本都有很大的改變。一樣的，每一個key所佔用的空間在每個版本也可能不一樣。這就是這個工具被建立的理由：他主要的動機是爲了測試Redis`LRU`的執行質量，可是如今在測試給定版本給定配置中也頗有用，在你的開發中要記住。

爲了使用這個模式，你須要指定測試中key的數量。同時，在第一次測試中，你要正確配置maxmemory。

重要提示：配置maxmemory設置在Redis配置中是很是重要的：若是沒有設置最大內存使用量，命中率最終將達到100%，由於全部的key均可以配存儲到內存中。若是你設置了太多的key可是沒有最大內存，最終，電腦全部的RAM江北使用，一樣你要配置最大內存策略，大部分時間你要的是allkeys-lru。

接下來的例子我將內存限制爲100MB，LRU模擬器使用1千萬個key

警告：這個測試使用的管道，將會給服務器帶來壓力，不要在生產環境中的實例使用。

$ ./redis-cli --lru-test 10000000
156000 Gets/sec | Hits: 4552 (2.92%) | Misses: 151448 (97.08%)
153750 Gets/sec | Hits: 12906 (8.39%) | Misses: 140844 (91.61%)
159250 Gets/sec | Hits: 21811 (13.70%) | Misses: 137439 (86.30%)
151000 Gets/sec | Hits: 27615 (18.29%) | Misses: 123385 (81.71%)
145000 Gets/sec | Hits: 32791 (22.61%) | Misses: 112209 (77.39%)
157750 Gets/sec | Hits: 42178 (26.74%) | Misses: 115572 (73.26%)
154500 Gets/sec | Hits: 47418 (30.69%) | Misses: 107082 (69.31%)
151250 Gets/sec | Hits: 51636 (34.14%) | Misses: 99614 (65.86%)

這個程序每秒顯示一次狀態，就像你看到的，在第一秒的時候緩存開始填充。一段時間後緩存失效率漸漸穩定下來：

120750 Gets/sec | Hits: 48774 (40.39%) | Misses: 71976 (59.61%)
122500 Gets/sec | Hits: 49052 (40.04%) | Misses: 73448 (59.96%)
127000 Gets/sec | Hits: 50870 (40.06%) | Misses: 76130 (59.94%)
124250 Gets/sec | Hits: 50147 (40.36%) | Misses: 74103 (59.64%)

在咱們的使用場景中59%的緩存失效率是不被接受的。因此咱們知道100MB的內存是不夠的。讓咱們闡釋一下半個G，幾分鐘後咱們將看到以下輸出：

140000 Gets/sec | Hits: 135376 (96.70%) | Misses: 4624 (3.30%)
141250 Gets/sec | Hits: 136523 (96.65%) | Misses: 4727 (3.35%)
140250 Gets/sec | Hits: 135457 (96.58%) | Misses: 4793 (3.42%)
140500 Gets/sec | Hits: 135947 (96.76%) | Misses: 4553 (3.24%)

因此咱們知道 500MB是知足咱們1千萬個key和80-20分佈使用的。