Redis是一個TCPServer,使用CS模型

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

隊列化執行結果需要使用內存,如果多次大批量操作需要注意內存的使用

使用Redis腳本能夠處理更快處理批量命令.管道無法在腳本中使用,因為使用管道時在寫入之前需要返回響應給客戶端(需要注意:這里個人理解可能存在偏差).反之,管道可以使用腳本

發布訂閱模式: 發布者發布消息到Channel,訂閱者訂閱Channel接收消息

Redis客戶端一旦為訂閱模式,不能接收其他命令

redis-cli命令行客戶端時進入訂閱模式之后只能通過ctrl-c取消訂閱,因為此時客戶端阻塞等待接收訂閱消息

發布訂閱無關于key所在空間,db10發布的,db1訂閱仍能接收

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

EVAL,EVALSHA命令執行Lua腳本

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

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

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

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

如果Lua返回數組中包含nil,則數據轉換終止,最終只能返回nil之前的結果

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

執行Lua腳本時,其他客戶端的命令和腳本將無法執行

redis內部緩存機制會緩存腳本,使用EVALSHA,如果redis通過匹配SHA1文摘匹配到腳本,則執行腳本,否則返回錯誤信息通知使用EVAL代替

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

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

腳本不允許設置全局變量

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

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

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

RDB和AOF文件兼容32位和64位,之間可以互轉

合理利用bit和byte操作

盡可能使用hash結構存儲數據

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

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

被刪除的key實際上并不會立刻釋放內存,例如在同一頁中存在其他的key未被刪除,需要根據峰值內存使用量限定內存使用

redis底層內存分配器會盡可能重復利用被刪除key的內存,所以也不用太擔心被刪除key沒有及時釋放的問題

如果不設置maxmemory,所有的內存將可能被吃光

當超過最大內存限制時,導致寫入時out of memory error,但不會因此導致整個機器掛掉

過期時間只針對key不針對值

過期時間可以通過persist命令清除

通過rename重命名key,原key的過期時間仍然有效,如果由別的key rename覆蓋,則該key具有別的key的特性

如果設置的過期時間為過去時間,則key相當于del 而不是expired

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

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

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

noeviction: 直接拋出異常

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

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

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

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

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

如果不確定使用哪種策略,allkeys-lru是一個較好選擇

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

redis使用的并不是實際的LRU算法,而是大致評估一定樣本量中選取最符合的key

可以通過設置配置樣本量參數maxmemory-samples調節精度

4.0版本以后新增了新策略,根據命中的頻率決定清除哪些key

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

事務中的所有命令會序列化并串行化執行,在事務過程中,其他客戶端發起的請求不會被處理

所有命令要么全部被處理或不處理(這里的處理并不表示一定執行成功),保證了原子性

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

MULTI開啟事務,命令存儲到隊列,命令EXEC執行事務所有命令

執行EXEC檢測到命令錯誤時,會在EXEC直接返回錯誤信息,并丟棄所有命令

執行EXEC后,部分命令執行失敗,對應的命令返回錯誤信息,其他命令執行成功

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

使用WATCH命令實現樂觀鎖,如果多個客戶端對同一個key進行操作并存儲時,被觀察的key被改變后,其他客戶端對該key的修改的事務則會失敗,實現了對該key的原子操作

需要注意的一點,當WATCH某個key之后,key過期了,那EXEC就會正常執行

使用WATCH可以實現對有序集合操作的原子性

對事務的操作在腳本中也能實現,而且腳本可以更簡單更快