Redis 文檔閱讀筆記 (一)

平常使用Redis大概就是須要的時候就查一下文檔,因而決定開始完整地看一遍,並作一些筆記.須要說明的是,部分筆記我的理解可能有不對的地方,歡迎指正交流.

1. Pipelining

1. Redis是一個TCPServer,使用CS模型

2. 1次請求將命令集合發送,Redis執行命令後將結果隊列化後,再寫入返回

3. 隊列化執行結果須要使用內存,若是屢次大批量操做須要注意內存的使用

4. 使用Redis腳本可以處理更快處理批量命令.管道沒法在腳本中使用,由於使用管道時在寫入以前須要返回響應給客戶端(須要注意:這裏我的理解可能存在誤差).反之,管道可使用腳本

2. Redis Pub/Sub

1. 發佈訂閱模式: 發佈者發佈消息到Channel,訂閱者訂閱Channel接收消息

2. Redis客戶端一旦爲訂閱模式,不能接收其餘命令

3. redis-cli命令行客戶端時進入訂閱模式以後只能經過ctrl-c取消訂閱,由於此時客戶端阻塞等待接收訂閱消息

4. 發佈訂閱無關於key所在空間,db10發佈的,db1訂閱仍能接收

5. 可用模式匹配發布多個channel 和訂閱多個channel

3. Redis Lua scripting

1. EVAL,EVALSHA命令執行Lua腳本

2. Lua 腳本可使用redis.call 或redis.pcall執行redis命令

3. redis.call執行遇到錯誤時直接拋出Lua異常結果,redis.pcall則會把異常處理成Lua table返回

4. Lua調用redis命令時把數據轉成redis對應數據類型,腳本執行結果返回給客戶端時Lua的數據類型轉成redis對應數據類型

5. 使用Lua腳本時對於浮點數最好使用字符串替代

6. 若是Lua返回數組中包含nil,則數據轉換終止,最終只能返回nil以前的結果

7. redis.error_reply,redis.status_reply 在Lua腳本中是比較有用的按redis數據類型返回結果的方法

8. 執行Lua腳本時,其餘客戶端的命令和腳本將沒法執行

9. redis內部緩存機制會緩存腳本,使用EVALSHA,若是redis經過匹配SHA1文摘匹配到腳本,則執行腳本,不然返回錯誤信息通知使用EVAL代替

10. 使用SCRIPT FLUSH或重啓redis實例會刷新腳本緩存

11. 腳本自身會被從庫複製或寫入AOF文件,而不是腳本的結果命令.不過從3.2版本開始,已經可選設置複製結果命令

12. 腳本不容許設置全局變量

4. Debugging Lua scripts

1. Redis Lua debugger默認,每個新的Debug session是一個forked session,這意味着當腳本在debug中時,不會阻塞redis server執行其餘命令,同時也意味着debug結束後會回滾腳本執行的結果

2. 官網有視頻詳解https://redis.io/topics/ldb

5. Memory optimization

1. 經過修改redis.conf調整每一種數據類型的最大數量和最大空間

2. RDB和AOF文件兼容32位和64位,之間能夠互轉

3. 合理利用bit和byte操做

4. 儘量使用hash結構存儲數據

5. 每一個hash最多存儲100個field是cpu和內存之間的最佳妥協

6. redis根據配置文件maxmemory分配內存

7. 被刪除的key實際上並不會馬上釋放內存,例如在同一頁中存在其餘的key未被刪除,須要根據峯值內存使用量限定內存使用

8. redis底層內存分配器會盡量重複利用被刪除key的內存,因此也不用太擔憂被刪除key沒有及時釋放的問題

9. 若是不設置maxmemory,全部的內存將可能被吃光

10. 當超過最大內存限制時,致使寫入時out of memory error,但不會所以致使整個機器掛掉

6. Expires

1. 過時時間只針對key不針對值

2. 過時時間能夠經過persist命令清除

3. 經過rename重命名key,原key的過時時間仍然有效,若是由別的key rename覆蓋,則該key具備別的key的特性

4. 若是設置的過時時間爲過去時間,則key至關於del 而不是expired

5. 消極檢查: 當客戶端獲取該key時才檢查該key是否過時

6. 積極檢查: redis 1秒內執行10個檢查過時,每次隨機選取20個key,發現過時的則清除,若是發現超過25%過時,則繼續下一個檢查

7. 過時執行刪除的命令會傳遞給從庫和AOF文件同步執行.從庫不會檢查key過時,當切換爲主庫時纔會去檢查

7. Redis as an LRU (Less Recently Used) cache

7.1 Redis達到最大內存限制時策略

1. noeviction: 直接拋出異常

2. allkeys-lru: 將最近不經常使用的key清除騰出空間

3. volatile-lru: 將帶有過時時間的最近不經常使用的key清除騰出空間

4. allkeys-random: 隨機將key清除騰出空間

5. volatile-random: 隨機將帶有過時時間的key清除騰出空間

6. volatile-ttl: 將較小剩餘存活時間的key清除騰出空間

7. 若是不肯定使用哪一種策略,allkeys-lru是一個較好選擇

8. volatile-lru和volatile-random比較適用於只用單個實例,混用緩存和持久key

7.2 近似LRU算法

1. redis使用的並非實際的LRU算法,而是大體評估必定樣本量中選取最符合的key

2. 能夠經過設置配置樣本量參數maxmemory-samples調節精度

7.3 LFU (Least Frequently Used)

1. 4.0版本之後新增了新策略,根據命中的頻率決定清除哪些key

2. lfu-log-factor和lfu-decay-time是兩項主要調節參數

8. Redis transactions

1. 事務中的全部命令會序列化並串行化執行,在事務過程當中,其餘客戶端發起的請求不會被處理

2. 全部命令要麼所有被處理或不處理(這裏的處理並不表示必定執行成功),保證了原子性

3. 若是使用append-only file,在發生崩潰或強制關閉redis時有可能致使執行事務中部分命令.redis重啓後會檢測到直接退出.使用redis-check-aof tool修復

4. MULTI開啓事務,命令存儲到隊列,命令EXEC執行事務全部命令

5. 執行EXEC檢測到命令錯誤時,會在EXEC直接返回錯誤信息,並丟棄全部命令

6. 執行EXEC後,部分命令執行失敗,對應的命令返回錯誤信息,其餘命令執行成功

7. redis不支持回滾:由於官方認爲不須要,語法上的錯誤,在命令隊列化時就能檢測到,而編碼錯誤致使命令執行失敗redis表示不背這個鍋,redis追求更簡單,更快

8. 使用WATCH命令實現樂觀鎖,若是多個客戶端對同一個key進行操做並存儲時,被觀察的key被改變後,其餘客戶端對該key的修改的事務則會失敗,實現了對該key的原子操做

9. 須要注意的一點,當WATCH某個key以後,key過時了,那EXEC就會正常執行

10. 使用WATCH能夠實現對有序集合操做的原子性

11. 對事務的操做在腳本中也能實現,並且腳本能夠更簡單更快