多級快取跳過
鍵值設計#
優雅的 key 結構#
Redis 的 Key 雖然可以自定義，但最好遵循下面的幾個最佳實踐約定：
- 遵循基本格式：［業務名稱］：［數據名］：［id］
- 長度不超過 44 字節
- 不包含特殊字符
例如：我們的登錄業務，保存用戶信息，其 key 是這樣的： login:user:10
優點：
- 可讀性強
- 避免 key 衝突
- 方便管理
- 更節省內存：key 是 string 類型，底層編碼包含 int、embstr 和 raw 三種。embstr 在小於 44 字節使用，採用連續內存空間，內存佔用更小
set num 123 如果 type num 得到 string 但是 object encoding num 得到底層是 int
set name Jack 如果 type name 得到 string 但是 object encoding name 得到底層是 embstr
BigKey#
什麼是 bigkey
- Key 本身數據量大
- 成員數量過多
- 成員數據量大
推薦值
- 單個 key 的 value 小於 10KB
- 對於集合類型的 key，建議元素數量小於 1000
危害：
- 網絡阻塞
- 數據傾斜，分片不均衡
- Redis 阻塞
- 序列化與反序列化 CPU 壓力大
恰當的數據結構#
對於一個 User 對象存儲
- String 類型的字符串整體存儲 user:1
- 打散字段，String 類型分別存儲 user:1 user:1
- Hash 結構
Hash 結構不超過 1000 Entry，可以拆分
批處理#
大數據導入#
1 個命令響應 = 1 次網絡往返 + 1 次執行
所以一次傳遞而非多次傳遞同等數據量更好，注意不要太多，不然會阻塞網絡
pipeline 放入命令到管道，支持原生的各種命令，只是一次發送這些全部的命令到 Redis，而非原生的 MSET 的原子性大量操作
持久化配置#
Redis 的持久化雖然可以保證數據安全，但也會帶來很多額外的開銷，因此持久化請遵循下列建議：
- 用來做快取的 Redis 實例儘量不要開啟持久化功能
- 建議關閉 RDB 持久化功能，使用 AOF 持久化
- 利用腳本定期在 slave 節點做 RDB，實現數據備份
- 設置合理的 rewrite 閾值，避免頻繁的 bgrewrite
- 配置 no-appendfsync-on-rewrite = yes，禁止在 rewrite 期間做 AOF，避免因 AOF 引起的阻塞
部署有關建議：
- Redis 實例的物理機要預留足夠內存，應對 fork 和 rewrite
- 單個 Redis 實例內存上限不要太大，例如 4G 或 8G。可以加快 fork 的速度、減少主從同步、數據遷移壓力
- 不要與 CPU 密集型應用部署在一起
- 不要與高硬盤負載應用一起部署。例如：數據庫、消息隊列
慢查詢#
在 Redis 中執行耗時超過某個閾值的命令，稱為慢查詢（不止查詢），Redis 單線程所以慢查詢會阻塞
慢查詢的閾值可以通過配置指定：
- slowlog-log-slower-than: 慢查詢閾值，單位是微秒。默認是 10000，建議 1000
慢查詢會被放入慢查詢日誌中，日誌的長度有上限，可以通過配置指定：
- slowlog-max-len: 慢查詢日誌（本質是一個隊列）的長度。默認是 128，建議 1000
查看慢查詢日誌列表：
- slowlog len: 查詢慢查詢日誌長度
- slowlog get [n]: 讀取 [n]/ 全部 條慢查詢日誌
- slowlog reset: 清空慢查詢列表
此文由 Mix Space 同步更新至 xLog 原始鏈接為 https://blog.0xling.cyou/posts/redis/redis-2