redis複習總結
本文主要記錄在換工作期間對redis的複習和總結
參考資料
- Redis在公司專案實踐
- 《Redis實踐》
基礎概念
1.redis的資料結構
String list hash set zset
2.redis為什麼快
單執行緒IO多路複用模型 純記憶體互動，免去執行緒切換，非阻塞模型
redis用什麼命令進行排序
sort 理解為SQL中的orderBy
redis事務
redis持久化方式？ 優缺點
- redis的資料結構
- redis為什麼這麼快
- redis用什麼命令進行排序
- redis事務模型
- redis持久化方式 優缺點 [AFO可以設定的選項有那些]
- redis預設持久化方式是什麼
- redis如何實現分散式鎖？
- redis如何實現訊息佇列 有何缺點
- redis的釋出訂閱模型
- 簡單講下redis主從複製啟動過程
- redis如何清除過期key[redis過期策略和記憶體淘汰機制]
- redis單機和叢集模式下的差異
- 簡單講下redis的批處理
專案實踐
- 專案中redis如何部署的
- redis設定的持久化方式
- 如何保障資料庫和快取的一致性
- 專案中會用到批處理嗎
- 說下你們redis的架構有什麼優缺點
- 你知道哪幾種redis專案架構
- 你們用到了多資料庫機制嗎
答案
基礎概念
1.redis的資料結構:
string list hash set zset
2.redis為什麼這麼快:
單執行緒多路IO複用模型 純記憶體互動無執行緒切換開銷
3.redis用什麼命令進行排序
sort 可以理解為SQL order by
4.redis事務模型
使用命令watch & multi & execRedis 參考了 CAS（Compare And Swap）樂觀鎖. 可以在 multi 命令之前使用 watch 命令監控某些鍵值對，然後使用 multi 命令開啟事務,資料操作命令就會進入佇列。redis收到exec 會檢測watch監控的是鍵值對，無變化，執行，提交事務；如果發生變化，那麼它不會執行任何事務中的命令，事務回滾。無論事務是否回滾，Redis 都會去取消執行事務前的 watch 命令. redis 在接受到multi 只是收到事務訊號，不會開始執行命令，當收到exec時候才會一次性執行被multi和exec包裹的命令。
5.redis持久化方式 優缺點 [AFO可以設定的選項有那些]
持久化方式有RDB & AFO
- RDB的提供2種持久化命令
BGSAVE和SAVE都會呼叫rdbSave.
SAVE會阻塞主程序，在快照儲存完成前無法處理客戶端的任何請求
BGSAVE 會fork出來一個子程序來呼叫rdbSave，不會干擾主程序。缺點是子程序處理較慢，隨著redis的記憶體佔升高，建立子程序耗時會增加可能會導致redis的長時間不可用。
解決辦法： 關閉自動儲存，在合適的時間自己呼叫SAVE速率較高，但是會有小段時間的資料丟失。
- AOF append only fileaof持久化會把被執行寫命令寫道aof檔案的末尾可以記錄所有資料變化。恢復資料時候只需要執行一次aof檔案即可。
可以設定的引數： always[每條同步一次]/everysec/[每秒一次]/no[系統決定何時寫入 類似Java write]
缺點是aof檔案可能會過大，需要設定定期重寫BG write AOF[距離上次重寫增大的% 或者距離上次重寫的時間]
7.redis如何實現分散式鎖？
使用SETNX命令[set if not exsit 不存在就設定] ，同時使用expire來設定超時時間。為了防止在設定超時時間時候客戶端崩潰導致設定失敗，每個客戶端在獲取鎖時候，需要檢測下鎖是否設定了過期時間，給未設定過期時間的鎖設定時間，避免無法釋放鎖。
9.redis如何實現訊息佇列 有何缺點
11.簡單講下redis主從複製啟動過程
[配置主從使用配置 SLAVE of host port]
1.從伺服器連線主伺服器傳送SYNC命令
2.主伺服器開始執行BGSAVE命令，並使用緩衝區記錄快照生成期間的命令
3.BGSAVE執行完成主伺服器通過SCP向從伺服器傳送快照檔案
4.從伺服器丟棄老資料，開始執行快照的寫入
5.從伺服器完成對快照的解釋，開始接受新得請求，同時接收主伺服器緩衝區發來的寫命令。
6.主服務緩衝區命令同步完成開始正常執行接受寫命令，沒接收一次給從伺服器同步一次。
12.redis如何清除過期key[過期策略和記憶體淘汰策略]
redis預設過期策略 惰性刪除 + 定期刪除
redis支援的過期策略有
- 定時刪除[給每個設定了過期時間的都配置上定時器]
記憶體淘汰策略配置如下
- maxmemory-policy volatile-lru
redis 記憶體淘汰機制（記憶體淘汰策略）有以下幾個：
- noeviction: 當記憶體不足以容納新寫入資料時，新寫入操作會報錯，這個一般沒人用吧，實在是太噁心了。
- allkeys-lru：當記憶體不足以容納新寫入資料時，在鍵空間中，移除最近最少使用的 key（這個是最常用的）。
- allkeys-random：當記憶體不足以容納新寫入資料時，在鍵空間中，隨機移除某個 key，這個一般沒人用吧，為啥要隨機，肯定是把最近最少使用的 key 給幹掉啊。
- volatile-lru：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，移除最近最少使用的 key（這個一般不太合適）。
- volatile-random：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，隨機移除某個 key。
- volatile-ttl：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，有更早過期時間的 key 優先移除。
如果redis中不存在設定了過期時間的key 那麼配置volatile-lru-random-ttl 等效於noeviction 。新加入的資料會報錯。
簡單講下redis的批處理
mset和mget 因為我們的專案使用的 Redis Cluster的叢集，不同的key會被
CRC16(key) Mod 16384 到不同的slot上去，直接使mset和mget是不太好的，所以我們一般不使用批處理。
你知道那些redis的高可用方案 你們專案中用的哪一種
-
redis哨兵模式
Replication+Sentinel使用sentinel 對主從進行監控，和自動故障轉移，並且提供一個vip給client進行訪問，當出現故障的時候，自動踢掉Mster節點，並在slave中選擇新。Sentinel的作用有三個:
監控:Sentinel 會不斷的檢查主伺服器和從伺服器是否正常執行。
通知:當被監控的某個redis伺服器出現問題，Sentinel通過API指令碼向管理員或者其他的應用程式傳送通知。
自動故障轉移:當主節點不能正常工作時，Sentinel會開始一次自動的故障轉移操作，它會將與失效主節點是主從關係 的其中一個從節點升級為新的主節點，並且將其他的從節點指向新的主節點。缺點： 主從切換會有部分資料丟失且 不支援擴容，單機記憶體限制叢集上線。
-
redis哨兵模式+proxy
單純哨兵模式的升級版 在vip後加入了proxy層 均衡到後端多個master節點。可以支援水平擴容，但運維困難。
-
redis Cluster 當前我們專案就使用的這種 關鍵演算法 crc16(Key) mod 16384
專案的持久化方式
master節點關閉持久化
slave開啟 AOF 也可以開啟AOF&RDB