Redis 的一些筆記

角色

---

當用做 主存 和 緩存 時，redis 的配置和用法有明顯區別。最好在配置時建立兩套實例，應用不一樣的配置並在程序中作明顯的區分使用。

用做主存的 redis，可靠性應該和其餘數據庫同樣高，能夠獨立存儲數據。這樣的實例掛掉後會致使數據訪問不可用。另外除非業務須要，通常不設置超時。

而用做緩存的 redis，不會獨立存儲數據，且都應默認配置爲：取不到數據時，自動去找原數據，並在找到後嘗試再次緩存。這樣的 redis 掛掉後，會拖慢數據層的性能，但功能是完整的。由於緩存實例的可靠性、優先級都不高，這些 key 通常都設置超時，而且只使用 string 類型和 get/set 方法。刷新靠 del key 實現。

本文一些論斷都是基於以上約束得出的。

---

爲何緩存只使用 string 類型

由於對於 key 存在與否的判斷不可靠。

本文通用的一個例子是：

假設我要緩存一個 set，主要邏輯是判斷一個 value 是否爲其元素。

redis 的一個特性是，在使用 sismember(key, value) 時，即便 key 不存在，也會正常返回一個 False。

另外一個特性是，redis 不會保存一個空的 set。（這個特性在 hash 上也成立）這會致使一個結果就是，假設我須要緩存的 set 原本就是 空的，那麼每次我嘗試緩存它時，都會獲得一個調用異常——sadd 的參數不足，致使調用失敗。或者 srem 掉了最後一個元素，這個 key 就被 redis 自動釋放了，下次又會觸發緩存流程。

---

和其餘使用 hash index 的數據庫的區別

當用做主存時，不可避免的要使用持久化配置。那麼問題即是，這時的 redis，和使用了 hash index 的 MySQL 或者 MongoDB 有何區別呢？在功能相對弱勢的狀況下，還有什麼性能上的優點嗎？

• 全內存支持

這依然是最重要的。

• 單線程鏈接

redis 使用單線程的異步鏈接服務器，而不是像 MySQL 同樣每一個鏈接一個線程。所以在鏈接數極大，或頻繁新建、斷開鏈接的情景下性能不會明顯降低。MySQL 企業版或其餘第三方分支（如 AliSQL）能夠提供線程池來處理這個問題。或者一個反向代理也能夠處理這種問題。

糖

---

replace

3.0 之前，直接替換一個 set 的方法是使用事務，先刪後加。3.0 後則有了 restore + replace 參數的替代方法。其中序列化值須要經過第三方模塊來生成。這種方式避免了事務的使用，以 sadd(key, list(range(10))) 爲例速度能夠快一倍（沒算生成序列化值的時間）。

---

內建方法

Python 的 RestictRedis 對象支持一些字典的內建方法：

__delitem__
__getitem__
__setitem__

這使得其能夠像字典同樣被使用。但需注意，僅支持 String 類型或不存在的 key，由於它實際是調用的 GET、SET 等方法。

PipeLine 對象則支持如下方法：

__enter__
__exit__
__len__

能夠用於使用 with 語句和檢查已經進入管道的命令的數量。