Redis 版本：3.2.100
Redis 命令
Redis 命令用於在 redis 服務上執行操作。
要在 redis 服務上執行命令需要一個 redis 客戶端。
一.客戶端連接服務器
基本語法： redis-cli [-h host -p port -a password]
不帶參數，則默認連接本地，帶上三個參數，則連接遠程服務器。
舉例： 如何連接到主機為 127.0.0.1，端口為 6379 ，密碼為 mypass 的 redis 服務上。
redis-cli -h 127.0.0.1 -p 6379 -a "mypass"
然后可以 執行 PING 命令，該命令用於檢測 redis 服務是否啟動，成功返回 pong .
二.redis 鍵(key)
redis鍵命令用於管理redis的鍵。
語法：command key_name
舉例： set myName justin 設置
get myName 獲取
del myName 刪除
Redis keys 命令 以下為redis鍵相關的命令
1. del
用於刪除已存在的key，不存在的key會被忽略，返回被刪除key的數量
語法： del key_name
版本：>=1.0.0
返回：被刪除key的數量
2. dump
序列化給定 key ，並返回被序列化的值，使用 RESTORE 命令可以將這個值反序列化為 Redis 鍵。
序列化生成的值有以下幾個特點：
它帶有 64 位的校驗和，用於檢測錯誤，RESTORE 在進行反序列化之前會先檢查校驗和。
值的編碼格式和 RDB 文件保持一致。
RDB 版本會被編碼在序列化值當中，如果因為 Redis 的版本不同造成 RDB 格式不兼容，那么 Redis 會拒絕對這個值進行反序列化操作。
序列化的值不包括任何生存時間信息。
語法：dump key_name
版本：>=2.6.0
返回：如果key不存在，則返回 nil , 否則返回序列化之后的值。
3. exists
用於檢測給定的key是否存在
語法：exists key_name
版本：>=1.0.0
返回：若key存在返回1，否則返回0。
注意：從redis 3.0.3 開始，exists命令可以指定多個key而不是單個key，此時它的返回值為存在的key的總數。
對於單個key返回1或0就只是一種特殊情況了，所以exists命令向后兼容。
另外，如果相同的key在參數中多次出現，則會多次計數。所以，如果somekey存在，那么 exists somekey somekey 將返回 2 。
4. expire
用於設置key的過期時間，以秒計，key過期后不再可用，將被自動刪除。
語法：expire key_name time_in_seconds
版本：>=1.0.0
返回：設置成功返回1。當key不存在或者不能為key設置過期時間時（比如在低於 2.1.3 版本的 Redis 中你嘗試更新 key 的過期時間），返回0.
5. expireat
用於以unix 時間戳(unix timestamp)格式設置key的過期時間。key過期后將不再可用，自動刪除。
語法：expireat key_name time_in_unix_timestamp
版本：>=1.2.0
返回：設置成功返回1。當key不存在或者不能為key設置過期時間時（比如在低於 2.1.3 版本的 Redis 中你嘗試更新 key 的過期時間），返回0.
6. pexpire
用於以設置key的過期時間，以毫秒計，key過期后將不再可用，自動刪除 。（與expire類似，除了過期時間以毫秒計）
語法：pexpire key_name time_in_milliseconds
版本 :>=2.6.0
返回 ：設置成功返回1,當key不存在或者不能為key設置過期時間時（比如在低於 2.1.3 版本的 Redis 中你嘗試更新 key 的過期時間），返回0.
7. pexpireat
用於以unix時間戳（unix timestamp）以毫秒計設置key的過期 時間，key過期將不再 可用，自動刪除。（與expireat類似，除了時間以毫秒計）
語法：pexpireat key_name time_in_milliseconds_in_unix_timestamp
版本 :>=2.6.0
返回 ：設置成功返回1,當key不存在或者不能為key設置過期時間時（比如在低於 2.1.3 版本的 Redis 中你嘗試更新 key 的過期時間），返回0.
8. keys
用於查找所有符合給定模式 pattern（正則表達式）的key。pattern中使用星號*模糊匹配或者直接使用*查找所有key
語法：keys pattern
版本：>=1.0.0
返回：符合給定模式的key列表（Array）。
9. move
用於將當前數據庫的key移動到給定的數據庫db當中
語法：move key_name destination_database
版本：>=1.0.0
返回：移動成功返回1，失敗則返回0.
注意：當且僅當 key在當前數據庫存在，而在給定的數據庫db中不存在時，才能移動成功，否則均失敗。
10. persist
用於移除給定key的過期時間，使得key永不過期（持久化）。
語法：persist key_name
版本：>=2.2.0
返回：當過期時間移除成功時，返回1，如果key不存在或者key沒有設置過期時間，返回0.
11. ttl
用於以秒為單位返回key的剩余過期時間。
語法：ttl key_name
版本：>1.0.0
返回：當key不存在時，返回-2；當key存在但沒有設置剩余生存時間，返回-1；否則，以秒為單位返回key的剩余生存時間。
注意：在 redis 2.8 以前，當key不存在，或者key存在但沒有設置剩余生存時間時，命令都返回-1.
12. pttl
用於以毫秒為單位返回key的剩余過期時間。（與ttl類似，除了時間單位不一樣）
語法；pttl key_name
版本：>=2.6.0
返回：當key不存在時，返回-2；當key存在但沒有設置剩余生存時間，返回-1；否則，以秒為單位返回key的剩余生存時間。
注意：在 redis 2.8 以前，當key不存在，或者key存在但沒有設置剩余生存時間時，命令都返回-1.
13. randomkey
用於從當前數據庫中隨機返回一個key。（redis 默認使用數據庫 0）
語法：randomkey
版本：>=1.0.0
返回：當數據庫為空時，返回 nil ，否則返回一個隨機的key。
14. rename
用於修改key的名稱
語法：rename old_key_name new_key_name
版本：>=1.0.0
返回：改名成功，提示OK；失敗則返回一個錯誤。
當old_key_name不存在時，返回一個錯誤；
當new_key_name已經存在時，new_key_name的值將被覆蓋，此時會執行隱士的 del 操作，因此如果刪除的key包含非常大的值，
即使rename 命令是一個常時操作，也可能導致高延遲。
注意：在redis 3.2.0 以前，當old_key_name和new_key_name相同時，返回一個錯誤。
15. renamenx
用於當new_key_name不存在時，修改key的名稱。
語法：renamenx old_key_name new_key_name
版本：>=1.0.0
返回：修改成功，返回1；如果new_key_name已存在，返回0；如果old_key_name不存在，返回一個錯誤。
注意：在redis 3.2.0 以前，當old_key_name和new_key_name相同時，返回一個錯誤。
16. type
用於返回key所存儲的值的數據類型。
語法：type key_name
版本：>=1.0.0
返回：返回key的數據類型：none(key不存在)、string（字符串）、list（列表）、set（集合）、zset（有序集）、hash（哈希）。
17. migrate
MIGRATE host port key|"" destination-db timeout [COPY] [REPLACE] [KEYS key [key ...]]
將 key 原子性地從當前實例傳送到目標實例的指定數據庫上，一旦傳送成功， key 保證會出現在目標實例上，而當前實例上的 key 會被刪除。
這個命令是一個原子操作，它在執行的時候會阻塞進行遷移的兩個實例，直到以下任意結果發生：遷移成功，遷移失敗，等待超時。
命令的內部實現是這樣的：它在當前實例對給定 key 執行 DUMP 命令 ，將它序列化，然后傳送到目標實例，目標實例再使用 RESTORE 對數據進行反序列化，並將反序列化所得的數據添加到數據庫中；當前實例就像目標實例的客戶端那樣，只要看到 RESTORE 命令返回 OK ，它就會調用 DEL 刪除自己數據庫上的 key 。
timeout 參數以毫秒為格式，指定當前實例和目標實例進行溝通的最大間隔時間。這說明操作並不一定要在 timeout 毫秒內完成，只是說數據傳送的時間不能超過這個 timeout 數。
MIGRATE 命令需要在給定的時間規定內完成 IO 操作。如果在傳送數據時發生 IO 錯誤，或者達到了超時時間，那么命令會停止執行，並返回一個特殊的錯誤： IOERR 。
當 IOERR 出現時，有以下兩種可能：
key 可能存在於兩個實例
key 可能只存在於當前實例
唯一不可能發生的情況就是丟失 key ，因此，如果一個客戶端執行 MIGRATE 命令，並且不幸遇上 IOERR 錯誤，那么這個客戶端唯一要做的就是檢查自己數據庫上的 key 是否已經被正確地刪除。
如果有其他錯誤發生，那么 MIGRATE 保證 key 只會出現在當前實例中。（當然，目標實例的給定數據庫上可能有和 key 同名的鍵，不過這和 MIGRATE 命令沒有關系）。
可選項：
COPY ：不移除源實例上的 key 。
REPLACE ：替換目標實例上已存在的 key 。
可用版本：
2.6.0及以上
返回值：
遷移成功時返回 OK ，否則返回相應的錯誤。
示例
先啟動兩個 Redis 實例，一個使用默認的 6379 端口，一個使用 7777 端口。
$ ./redis-server &
[1] 3557
…
$ ./redis-server –port 7777 &
[2] 3560
…
然后用客戶端連上 6379 端口的實例，設置一個鍵，然后將它遷移到 7777 端口的實例上：
$ ./redis-cli
redis 127.0.0.1:6379> flushdb
OK
redis 127.0.0.1:6379> SET greeting “Hello from 6379 instance”
OK
redis 127.0.0.1:6379> MIGRATE 127.0.0.1 7777 greeting 0 1000
OK
redis 127.0.0.1:6379> EXISTS greeting # 遷移成功后 key 被刪除
(integer) 0
使用另一個客戶端，查看 7777 端口上的實例：
$ ./redis-cli -p 7777
redis 127.0.0.1:7777> GET greeting
“Hello from 6379 instance”
18. object
OBJECT 命令可以在內部調試(debugging)給出keys的內部對象，它用於檢查或者了解你的keys是否用到了特殊編碼 的數據類型來存儲空間z。 當redis作為緩存使用的時候，你的應用也可能用到這些由OBJECT命令提供的信息來決定應用層的key的驅逐策略(eviction policies)
OBJECT 支持多個子命令:
- OBJECT REFCOUNT 該命令主要用於調試(debugging)，它能夠返回指定key所對應value被引用的次數.
- OBJECT ENCODING 該命令返回指定key對應value所使用的內部表示(representation)(譯者注：也可以理解為數據的壓縮方式).
- OBJECT IDLETIME 該命令返回指定key對應的value自被存儲之后空閑的時間，以秒為單位(沒有讀寫操作的請求) ，這個值返回以10秒為單位的秒級別時間，這一點可能在以后的實現中改善
對象可以用多種方式編碼:
- 字符串可以被編碼為 raw (常規字符串) 或者int (用字符串表示64位無符號整數這種編碼方式是為了節省空間).
- 列表類型可以被編碼為ziplist 或者 linkedlist. ziplist 是為了節省較小的列表空間而設計一種特殊編碼方式.
- 集合被編碼為 intset 或者 hashtable. intset 是為了存儲數字的較小集合而設計的一種特殊編碼方式.
- 哈希表可以被編碼為 zipmap 或者hashtable. zipmap 是專為了較小的哈希表而設計的一種特殊編碼方式
- 有序集合被編碼為ziplist 或者 skiplist 格式. ziplist可以表示較小的有序集合, skiplist 表示任意大小多的有序集合.
一旦你做了一個操作讓redis無法再使用那些節省空間的編碼方式，它將自動將那些特殊的編碼類型轉換為普通的編碼類型.
返回值
不同的子命令會對應不同的返回值.
- refcount 和 idletime 返回整數.
- encoding 返回編碼類型.
如果你嘗試檢查的參數缺失，將會返回為空
例子
redis> lpush mylist "Hello World"
(integer) 4
redis> object refcount mylist
(integer) 1
redis> object encoding mylist
"ziplist"
redis> object idletime mylist
(integer) 10
接下來的例子你可以看到redis一旦不能夠實用節省空間的編碼類型時編碼方式的改變.
redis> set foo 1000
OK
redis> object encoding foo
"int"
redis> append foo bar
(integer) 7
redis> get foo
"1000bar"
redis> object encoding foo
"raw"
19. restore
反序列化給定的序列化值，並將它和給定的 key 關聯。
參數 ttl 以毫秒為單位為 key 設置生存時間；如果 ttl 為 0 ，那么不設置生存時間。
RESTORE 在執行反序列化之前會先對序列化值的 RDB 版本和數據校驗和進行檢查，如果 RDB 版本不相同或者數據不完整的話，那么 RESTORE 會拒絕進行反序列化，並返回一個錯誤。
返回值
如果反序列化成功那么返回 OK ，否則返回一個錯誤。
例子
redis> DEL mykey 0 redis> RESTORE mykey 0 "\n\x17\x17\x00\x00\x00\x12\x00\x00\x00\x03\x00\ x00\xc0\x01\x00\x04\xc0\x02\x00\x04\xc0\x03\x00\ xff\x04\x00u#<\xc0;.\xe9\xdd" OK redis> TYPE mykey list redis> LRANGE mykey 0 -1 1) "1" 2) "2" 3) "3"
20. scan
語法：scan cursor [match pattern] [count count]
版本: >=2.8.0
SCAN 命令及其相關的 SSCAN, HSCAN 和 ZSCAN 命令都用於增量迭代一個集合元素。
- SCAN 命令用於迭代當前數據庫中的key集合。 scan cursor [match pattern] [count count]
- SSCAN 命令用於迭代SET集合中的元素。 sscan key cursor [match pattern] [count count]
- HSCAN 命令用於迭代Hash類型中的鍵值對。 hscan key cursor [match pattern] [count count]
- ZSCAN 命令用於迭代SortSet集合中的元素和元素對應的分值 zscan key cursor [match pattern] [count count]
以上列出的四個命令都支持增量式迭代，它們每次執行都只會返回少量元素，所以這些命令可以用於生產環境，而不會出現像 KEYS 或者 SMEMBERS 命令帶來的可能會阻塞服務器的問題。
不過，SMEMBERS 命令可以返回集合鍵當前包含的所有元素， 但是對於SCAN這類增量式迭代命令來說，有可能在增量迭代過程中，集合元素被修改，對返回值無法提供完全准確的保證。
因為 SCAN, SSCAN, HSCAN 和 ZSCAN 四個命令的工作方式都非常相似， 所以這個文檔會一並介紹這四個命令，需要注意的是SSCAN, HSCAN ,ZSCAN命令的第一個參數總是一個key； SCAN 命令則不需要在第一個參數提供任何key，因為它迭代的是當前數據庫中的所有key。
SCAN命令的基本用法
SCAN命令是一個基於游標的迭代器。這意味着命令每次被調用都需要使用上一次這個調用返回的游標作為該次調用的游標參數，以此來延續之前的迭代過程
當SCAN命令的游標參數被設置為 0 時， 服務器將開始一次新的迭代， 而當服務器向用戶返回值為 0 的游標時， 表示迭代已結束。
以下是一個 SCAN 命令的迭代過程示例 :
redis 127.0.0.1:6379> scan 0
1) "17"
2) 1) "key:12"
2) "key:8"
3) "key:4"
4) "key:14"
5) "key:16"
6) "key:17"
7) "key:15"
8) "key:10"
9) "key:3"
10) "key:7"
11) "key:1"
redis 127.0.0.1:6379> scan 17
1) "0"
2) 1) "key:5"
2) "key:18"
3) "key:0"
4) "key:2"
5) "key:19"
6) "key:13"
7) "key:6"
8) "key:9"
9) "key:11"
在上面這個例子中， 第一次迭代使用 0 作為游標， 表示開始一次新的迭代。第二次迭代使用的是第一次迭代時返回的游標 17 ，作為新的迭代參數 。
顯而易見，SCAN命令的返回值 是一個包含兩個元素的數組， 第一個數組元素是用於進行下一次迭代的新游標， 而第二個數組元素則是一個數組， 這個數組中包含了所有被迭代的元素。
在第二次調用 SCAN 命令時， 命令返回了游標 0 ， 這表示迭代已經結束， 整個數據集已經被完整遍歷過了。
full iteration ：以 0 作為游標開始一次新的迭代， 一直調用 SCAN 命令， 直到命令返回游標 0 ， 我們稱這個過程為一次完整遍歷。
Scan命令的保證
SCAN命令以及其他增量式迭代命令， 在進行完整遍歷的情況下可以為用戶帶來以下保證 ：
- 從完整遍歷開始直到完整遍歷結束期間， 一直存在於數據集內的所有元素都會被完整遍歷返回； 這意味着， 如果有一個元素， 它從遍歷開始直到遍歷結束期間都存在於被遍歷的數據集當中， 那么 SCAN 命令總會在某次迭代中將這個元素返回給用戶。
- 同樣，如果一個元素在開始遍歷之前被移出集合，並且在遍歷開始直到遍歷結束期間都沒有再加入，那么在遍歷返回的元素集中就不會出現該元素。
然而因為增量式命令僅僅使用游標來記錄迭代狀態， 所以這些命令帶有以下缺點：
- 同一個元素可能會被返回多次。 處理重復元素的工作交由應用程序負責， 比如說， 可以考慮將迭代返回的元素僅僅用於可以安全地重復執行多次的操作上。
- 如果一個元素是在迭代過程中被添加到數據集的， 又或者是在迭代過程中從數據集中被刪除的， 那么這個元素可能會被返回， 也可能不會。
SCAN命令每次執行返回的元素數量
SCAN增量式迭代命令並不保證每次執行都返回某個給定數量的元素,甚至可能會返回零個元素， 但只要命令返回的游標不是 0 ， 應用程序就不應該將迭代視作結束。
不過命令返回的元素數量總是符合一定規則的， 對於一個大數據集來說， 增量式迭代命令每次最多可能會返回數十個元素；而對於一個足夠小的數據集來說， 如果這個數據集的底層表示為編碼數據結構（小的sets, hashes and sorted sets）， 那么增量迭代命令將在一次調用中返回數據集中的所有元素。
如果需要的話，用戶可以通過增量式迭代命令提供的COUNT選項來指定每次迭代返回元素的最大值。
COUNT選項
對於增量式迭代命令不保證每次迭代所返回的元素數量，我們可以使用COUNT選項， 對命令的行為進行一定程度上的調整。COUNT 選項的作用就是讓用戶告知迭代命令， 在每次迭代中應該從數據集里返回多少元素。使用COUNT 選項對於對增量式迭代命令相當於一種提示， 大多數情況下這種提示都比較有效的控制了返回值的數量。
- COUNT 參數的默認值為 10 。
- 數據集比較大時，如果沒有使用MATCH 選項, 那么命令返回的元素數量通常和 COUNT 選項指定的一樣， 或者比 COUNT 選項指定的數量稍多一些。
- 在迭代一個編碼為整數集合（intset，一個只由整數值構成的小集合）、 或者編碼為壓縮列表（ziplist，由不同值構成的一個小哈希或者一個小有序集合）時， 增量式迭代命令通常會無視 COUNT 選項指定的值， 在第一次迭代就將數據集包含的所有元素都返回給用戶。
注意: **並非每次迭代都要使用相同的 COUNT 值 **，用戶可以在每次迭代中按自己的需要隨意改變 COUNT 值， 只要記得將上次迭代返回的游標用到下次迭代里面就可以了。
MATCH 選項
類似於KEYS 命令，增量式迭代命令通過給定 MATCH 參數的方式實現了通過提供一個 glob 風格的模式參數， 讓命令只返回和給定模式相匹配的元素。
以下是一個使用 MATCH 選項進行迭代的示例:
redis 127.0.0.1:6379> sadd myset 1 2 3 foo foobar feelsgood
(integer) 6
redis 127.0.0.1:6379> sscan myset 0 match f*
1) "0"
2) 1) "foo"
2) "feelsgood"
3) "foobar"
redis 127.0.0.1:6379>
MATCH功能對元素的模式匹配工作是在命令從數據集中取出元素后和向客戶端返回元素前的這段時間內進行的， 所以如果被迭代的數據集中只有少量元素和模式相匹配， 那么迭代命令或許會在多次執行中都不返回任何元素。
以下是這種情況的一個例子:
redis 127.0.0.1:6379> scan 0 MATCH *11*
1) "288"
2) 1) "key:911"
redis 127.0.0.1:6379> scan 288 MATCH *11*
1) "224"
2) (empty list or set)
redis 127.0.0.1:6379> scan 224 MATCH *11*
1) "80"
2) (empty list or set)
redis 127.0.0.1:6379> scan 80 MATCH *11*
1) "176"
2) (empty list or set)
redis 127.0.0.1:6379> scan 176 MATCH *11* COUNT 1000
1) "0"
2) 1) "key:611"
2) "key:711"
3) "key:118"
4) "key:117"
5) "key:311"
6) "key:112"
7) "key:111"
8) "key:110"
9) "key:113"
10) "key:211"
11) "key:411"
12) "key:115"
13) "key:116"
14) "key:114"
15) "key:119"
16) "key:811"
17) "key:511"
18) "key:11"
redis 127.0.0.1:6379>
可以看出，以上的大部分迭代都不返回任何元素。在最后一次迭代， 我們通過將 COUNT 選項的參數設置為 1000 ， 強制命令為本次迭代掃描更多元素， 從而使得命令返回的元素也變多了。
並發執行多個迭代
在同一時間， 可以有任意多個客戶端對同一數據集進行迭代， 客戶端每次執行迭代都需要傳入一個游標， 並在迭代執行之后獲得一個新的游標， 而這個游標就包含了迭代的所有狀態， 因此， 服務器無須為迭代記錄任何狀態。
中止迭代
因為迭代的所有狀態都保存在游標里面， 而服務器無須為迭代保存任何狀態， 所以客戶端可以在中途停止一個迭代， 而無須對服務器進行任何通知。即使有任意數量的迭代在中途停止， 也不會產生任何問題。
使用錯誤的游標
使用SCAN 命令傳入間斷的（broken）、負數、超出范圍或者其他非正常的游標來執行增量式迭代並不會造成服務器崩潰， 但可能會讓命令產生未定義的行為。未定義行為指的是， 增量式命令對返回值所做的保證可能會不再為真。 只有兩種游標是合法的:
- 在開始一個新的迭代時， 游標必須為 0 。
- 增量式迭代命令在執行之后返回的， 用於延續迭代過程的游標。
迭代能終止的前提
增量式迭代命令所使用的算法只保證在數據集的大小有界的情況下， 迭代才會停止， 換句話說， 如果被迭代數據集的大小不斷地增長的話， 增量式迭代命令可能永遠也無法完成一次完整迭代。
從直覺上可以看出， 當一個數據集不斷地變大時， 想要訪問這個數據集中的所有元素就需要做越來越多的工作， 能否結束一個迭代取決於用戶執行迭代的速度是否比數據集增長的速度更快。
返回值
SCAN, SSCAN, HSCAN 和 ZSCAN 命令都返回一個包含兩個元素的 multi-bulk 回復： 回復的第一個元素是字符串表示的無符號 64 位整數（游標）， 回復的第二個元素是另一個 multi-bulk 回復， 包含了本次被迭代的元素。
- SCAN 命令返回的每個元素都是一個key。
- SSCAN 命令返回的每個元素都是一個集合成員。
- HSCAN 命令返回的每個元素都是一個鍵值對，一個鍵值對由一個鍵和一個值組成。
- ZSCAN命令返回的每個元素都是一個有序集合元素，一個有序集合元素由一個成員（member）和一個分值（score）組成。
另外的例子
迭代hash中的鍵值對：
redis 127.0.0.1:6379> hmset hash name Jack age 33
OK
redis 127.0.0.1:6379> hscan hash 0
1) "0"
2) 1) "name"
2) "Jack"
3) "age"
4) "33"
21. sort
版本:>=1.0.0
語法：SORT key [BY pattern] [LIMIT offset count] [GET pattern] [ASC|DESC] [ALPHA] destination
返回或存儲key的list、 set 或sorted set 中的元素。默認是按照數值類型排序的，並且按照兩個元素的雙精度浮點數類型值進行比較。下面是SORT的最簡形式：
SORT mylist
假設mylist是一個數字列表，這條命令將返回一個元素從小到大排序的相同大小列表。如果想從大到小排序，可以使用 !DESC 修飾符。
SORT mylist DESC
當 mylist 包含的是字符串值並且需要按照字典順序排序，可以使用 ALPHA 修飾符：
SORT mylist ALPHA
假設正確地設置了環境變量 !LC_COLLATE ，Redis可以感知UTF-8編碼。
返回元素的數量可以通過 LIMIT 修飾符限制。此修飾符有一個 offset 參數，指定了跳過的元素數量；還帶有一個 count 參數，指定了從 offset 開始返回的元素數量。下面的例子將會返回排序后的列表 mylist 從第0個元素（offset 是從0開始的）開始的10個元素：
SORT mylist LIMIT 0 10
幾乎所有的修飾符可以一起使用。下述例子將返回按字典順序降序排序后的前5個元素：
SORT mylist LIMIT 0 5 ALPHA DESC
通過外部key排序
有時我們需要使用外部的key作為權重來排序，而不是使用列表、集合或有序集合中實際的元素值。假設列表 mylist包含元素1、 2 和 3，分別代表了存儲在object_1、object_2 和 object_3中的對象的唯一ID。當這些對象關聯到存儲在weight_1、 weight_2 和 weight_3 中的權重后， SORT 命令就能使用這些權重按照下述語句來對 mylist 排序：
SORT mylist BY weight_*
BY 選項帶有一個模式（此例中的 weight_* ），用於生成用於排序的 Key 。這些key的名稱指向首次與列表(本例中的1、 2 和 3)中元素的實際值出現 *
跳過排序的元素
BY 選項可以是一個並不存在的key，這會導致 SORT 命令跳過排序操作。這在我們獲取未經排序的外部key(參考下文的 GET 選項)時非常有用。
SORT mylist BY nosort
獲取外部key
前面的例子僅僅是返回排序后的ID。在某些情況下，獲取實際的對象而不是他們的ID更加重要(object_1、object_2 和 object_3)。獲取存儲在一個列表、集合或者有序集合中的key可以使用以下命令：
SORT mylist BY weight_* GET object_*
GET 選項可多次使用，以便獲取每一個原始列表、集合或有序集合中元素的key。
還可以通過使用特殊 # 模式獲取 GET 元素本身：
SORT mylist BY weight_* GET object_* GET #
保存排序操作的結果
默認的，SORT 命令返回排序后的元素給客戶端。使用 STORE 選項，可以將結果存儲於一個特定的列表中，以代替返回到客戶端。
SORT mylist BY weight_* STORE resultkey
SORT ... STORE的一種有趣應用模式，是聯合 EXPIRE 超時命令返回key，以便在應用中可以緩存SORT操作的返回結果。 其他客戶端將會使用已緩存的列表，代替每個請求的 SORT 調用。當key即將過期時，一個更新版本的緩存將會通過 SORT ... STORE 再次創建。
注意，為了正確實現這種模式，很重要的一點是防止多個客戶端同時重建緩存。 此時需要使用一些鎖（具體的使用 SETNX）。
在 BY 和 GET中使用hash
可以在hash的屬性上按下述語法使用 BY 和 GET 選項：
SORT mylist BY weight_*->fieldname GET object_*->fieldname
字符串 -> 用於區分key名稱和哈希屬性的名稱。key被替換為上面所記錄的，結果key中存儲的hash用於獲取特定hash的屬性。
返回值
array-reply: 返回排序后的元素列表
22. touch
用於更改key的最后訪問時間，如果key不存在則忽略。
語法：touch key [key...]
版本：>=3.2.1
返回：被touch的key的數量
23. wait
語法：wait numslaves timeout
版本：>=3.0.0
此命令將阻止當前客戶端，直到所有以前的寫入命令成功傳輸並至少由指定數量的從站確認。如果達到了以毫秒為單位指定的超時，即使尚未達到指定數量的從站，命令也將返回。
在達到指定數量的從站的情況下，或達到超時時，該命令將始終返回確認在WAIT命令之前發送的寫入命令的從站數。
幾句話：
- 當WAIT返回時，在當前連接的上下文中發送的所有以前的寫入命令都保證由WAIT返回的從站數接收。
- 如果命令是作為MULTI事務的一部分發送的，則該命令不會阻塞，而只是返回ASAP確認先前寫入命令的從站數。
- 超時為0意味着永遠阻止。
- 由於WAIT返回在故障和成功的情況下達到的從站數，客戶端應檢查返回值是否等於或大於所要求的復制級別。
一致性和等待
請注意，WAIT不會使Redis成為強烈一致的存儲：同步復制是復制狀態機的一部分，但它不是唯一需要的。然而，在Sentinel或Redis Cluster故障切換的情況下，WAIT可以改善現實世界的數據安全性。
具體來說，如果一個給定的寫入被傳送到一個或多個從站，則更有可能（但不能保證）如果主站出現故障，我們將能夠在故障切換期間提升接收到寫入的從站：Sentinel和Redis集群將盡力嘗試在一系列可用的從站中推廣最佳的從站。
然而，這只是一個盡力而為的努力，所以有可能仍然失去同時復制到多個從站的寫入。
實施細節
由於引入與從站的部分重新同步（PSYNC功能）Redis從站異步地將其主機與已在復制流中處理的偏移量進行ping。這用於多種方式：
- 檢測超時奴隸。
- 斷開后執行部分重新同步。
- 實施WAIT。
在實施WAIT的具體情況下，當給定的客戶端的上下文中執行給定的寫入命令時，Redis會為每個客戶端記住生成的復制流的復制偏移量。當調用WAIT時，Redis會檢查指定數量的從站是否已經確認此偏移量或更大的從站。
返回值
整數回復：該命令返回在當前連接的上下文中執行的所有寫入所達到的從站數。
例子
> SET foo bar
OK
> WAIT 1 0
(integer) 1
> WAIT 2 1000
(integer) 1
在下面的例子中，WAIT的第一次調用不會使用超時，並要求寫入到1個從站。它成功返回。在第二次嘗試中，我們放置一個超時，並要求復制到兩個從站。由於存在單個從站可用，在等待一秒后解除阻塞並返回1，所達到的從站數。
24. unlink
版本：>=4.0.0
語法：unlink key [key...]
此命令非常類似於DEL：它刪除指定的鍵。就像DEL一樣，如果鍵不存在，則忽略它。然而，該命令在不同的線程中執行實際的內存回收，所以它不阻塞，而DEL是。這是命令名稱來自哪里：命令只是將鍵從鍵空間中取消鏈接。實際的刪除將在以后異步發生。
返回值
Integer reply：取消關聯的鍵數。