Redis 常見數據類型
一、基本全局命令詳解與實操
1. KEYS 命令
功能：按模式匹配返回所有符合條件的鍵（生產環境慎用，可能導致阻塞）。
語法：
KEYS pattern
模式規則：
h?llo：匹配hello,hallo（?表示單個字符）。h*llo：匹配hllo,heeeello（*表示任意字符）。h[ae]llo：匹配hello,hallo（[]內為可選字符）。h[^e]llo：排除h后第二個字符為e的鍵（如hxllo）。
示例：
127.0.0.1:6379> MSET user:1:name Alice user:2:name Bob
OK
127.0.0.1:6379> KEYS user:*:name
1) "user:1:name"
2) "user:2:name"
警告：
- 在數據量大的數據庫中執行
KEYS *可能導致服務卡頓，建議用SCAN代替。
2. EXISTS 命令
功能：檢查一個或多個鍵是否存在。
語法：
EXISTS key [key ...]
返回值：存在的鍵數量（0~N）。
示例：
127.0.0.1:6379> SET key1 "value"
OK
127.0.0.1:6379> EXISTS key1 key2
(integer) 1 # 只有 key1 存在
3. DEL 命令
功能：刪除一個或多個鍵（無視數據類型）。
語法：
DEL key [key ...]
返回值：成功刪除的鍵數。
示例：
127.0.0.1:6379> SET key1 "v1"
OK
127.0.0.1:6379> DEL key1 key2
(integer) 1 # key2 不存在，僅刪除 key1
4. EXPIRE / TTL 命令
功能：設置鍵的過期時間（秒） / 查看剩余存活時間。
語法：
EXPIRE key seconds # 設置過期時間
TTL key # 查看剩余時間
返回值：
EXPIRE：1（成功），0（鍵不存在或設置失敗）。TTL：剩余秒數，-1（無過期時間），-2（鍵不存在）。
示例：
127.0.0.1:6379> SET session:123 "data"
OK
127.0.0.1:6379> EXPIRE session:123 300 # 5分鐘后過期
(integer) 1
127.0.0.1:6379> TTL session:123
(integer) 297 # 剩余297秒
擴展操作：
PEXPIRE：以毫秒為單位設置過期時間。PERSIST：移除鍵的過期時間，使其永久有效。
5. TYPE 命令
功能：返回鍵對應的數據類型。
語法：
TYPE key
返回值：string, hash, list, set, zset, stream, none（鍵不存在）。
示例：
127.0.0.1:6379> LPUSH mylist "a" "b"
(integer) 2
127.0.0.1:6379> TYPE mylist
list
二、數據結構與內部編碼深度解析
1. 查看內部編碼
命令：OBJECT ENCODING key
示例：
127.0.0.1:6379> SET num 100
OK
127.0.0.1:6379> OBJECT ENCODING num
"int" # 存儲為整數 127.0.0.1:6379> SET long_str "A very long string..."
OK
127.0.0.1:6379> OBJECT ENCODING long_str
"raw" # 存儲為普通字符串
2. 各數據結構的內部編碼規則
| 數據結構 | 默認編碼 | 觸發條件（可配置） |
|---|---|---|
| string | int (整數) | 值可表示為64位有符號整數。 |
embstr (短字符串) | 字符串長度 ≤ 39字節（Redis 5.0+）。 | |
raw (長字符串) | 字符串長度 > 39字節。 | |
| hash | ziplist | 字段數 ≤ hash-max-ziplist-entries（默認512），且字段值長度 ≤ hash-max-ziplist-value（默認64字節）。 |
hashtable | 超出上述閾值時自動轉換。 | |
| list | ziplist | 元素數 ≤ list-max-ziplist-entries（默認512），且元素值長度 ≤ list-max-ziplist-value（默認64字節）。 |
linkedlist | 超出閾值時轉換。 |
配置調整示例（修改 redis.conf）：
hash-max-ziplist-entries 1024 # 哈希字段數超過1024時轉hashtable
list-max-ziplist-size -2 # 列表元素大小動態調整（默認值）
三、單線程架構原理與優化
1. 單線程模型核心機制
- 純內存操作：數據全在內存中，無需磁盤I/O。
- I/O多路復用：
- 使用
epoll（Linux）監聽多個客戶端連接。 - 事件驅動模型，將連接、讀寫事件轉換為隊列任務。
- 使用
- 無鎖設計：所有命令串行執行，避免競態條件。
2. 性能瓶頸與規避方法
- 長耗時命令：
- 避免使用
KEYS *、FLUSHALL、復雜 Lua 腳本。 - 使用
SCAN代替KEYS，分批次遍歷鍵。
- 避免使用
- 大Key問題：
- 拆分大哈希/列表（如將
user:1000:friends拆分為多個鍵）。 - 使用
UNLINK（異步刪除）代替DEL。
- 拆分大哈希/列表（如將
3. 監控與調優命令
- 查看命令執行時間：
SLOWLOG GET 5 # 獲取最近5條慢查詢日志 - 內存分析：
MEMORY USAGE key # 查看鍵的內存占用（單位字節）
四、操作驗證實驗
實驗1：觀察字符串編碼變化
- 設置不同長度的字符串：
127.0.0.1:6379> SET small "abc" OK 127.0.0.1:6379> OBJECT ENCODING small "embstr" 127.0.0.1:6379> SET large "This is a very long string..." # 長度超過39字節 OK 127.0.0.1:6379> OBJECT ENCODING large "raw"
實驗2：哈希編碼轉換測試
- 創建小哈希：
127.0.0.1:6379> HMSET user:1000 name "Alice" age 30 OK 127.0.0.1:6379> OBJECT ENCODING user:1000 "ziplist" - 添加大字段觸發轉換：
127.0.0.1:6379> HSET user:1000 bio "A very long biography..." # 字段值超過64字節 (integer) 1 127.0.0.1:6379> OBJECT ENCODING user:1000 "hashtable"
總結
- 全局命令：需注意
KEYS的性能風險，優先使用SCAN。 - 內部編碼：通過
OBJECT ENCODING和配置文件優化內存與性能。 - 單線程優化：避免長耗時操作，合理設計數據結構和命令。
