【Redis】使用總結

1. 5種數據類型

屬性	string	list	hash	set	zset
特點	存放基礎數據類型的數據,最多存512MB數據	有序可重複	鍵值對	無序不可重複	有序不可重複
內部編碼（默認）	1. Int:8個字節的長整型 2. Embstr:小於39個字節的字符串 3. Raw:大於39個字節的字符串	1. ziplist(壓縮列表)：元素個數小於512個且每個元素的值小於64字節，省內存，實現多個元素的連續存儲 2. linkedList(鏈表)：不滿足1條件	1.ziplist(壓縮列表)：元素個數小於512個且每個元素的值小於64字節，省內存，實現多個元素的連續存儲 2. hashtable(哈希表)： 不滿足1條件讀寫效率下降，複雜度爲o(1)	1.intset(整數集合)：元素都是整數且元素個數小於512個省內存 2. hashtable(哈希表）：不滿足1條件	1.ziplist(壓縮列表)：元素個數小於128個且元素值都小於64字節 skiplist(跳躍表)：不滿足1條件
典型使用場景	1.緩存 2.session共享 3.計數 4.限速（接口訪問次數）	1.消息隊列	存放的是對象	1.存標籤，得共同愛好（取交集）	1.排行榜

2. 持久化機制

  即將內存中的數據保存到磁盤，以防因進程退出而導致內存數據的丟失

2.1 RDB

2.1.1 觸發時間

1. 手動執行
2. 自動觸發：m秒內進行了n此修改，觸發bgsave
3. 從節點執行全量複製，觸發bgsave
4. 執行debug reload，觸發save
5. shutdown且沒有開啓AOF,觸發bgsave

2.1.2 觸發RDB過程

2.1.3 優點

1. RDB是一個緊湊的二進制壓縮文件，適用於全量複製，備份等
2. redis加載RDB 遠遠快於 AOF

2.1.4缺點

1. 無法實時保存

2.2 AOF

2.2.1 觸發時間

  每輸入一條命令，都會先寫入aof_buf中，然後根據配置的不同策略同步到磁盤

2.2.2 觸發AOF的過程

2.2.3 文件同步sync的3種方式

1. always： 命令寫入aof_buf後調用系統fsync操作同步到AOF文件，完成後線程返回（有阻塞）
2. ererysec： 命令寫入aof_buf後調用write，write完成線程返回。fsync有專門線程負責每秒同步一次文件（不阻塞）
3. no： 命令寫入aof_buf後調用write，write完成線程返回，不對AOF文件同步，同步由操作系統負責，通常週期最長30秒（不阻塞）

  write操作會觸發延遲寫delayed write機制（同步之前宕機，緩衝數據將丟失），fsync強制同步磁盤針對單個文件，會阻塞直到寫入磁盤完成後返回

2.2.4 重寫機制

注：fork在RDB中出現在bgsave過程，而在AOF中出現在重寫過程

2.2.5 優點

1. 實時備份

2.2.6 缺點

1. 恢復時不如RDB加載快

2.3 選擇RDB還是AOF

1. 允許某段時間內數據丟失，則選擇RDB
2. 數據的絕對安全，可以選擇RDB+AOF

3.事務處理

3.1 MULTI

  用於標記事務塊的開始。Redis會將後續的命令逐個放入隊列中，然後才能使用EXEC命令原子化地執行這個命令序列

3.2 EXEC

  在一個事務中執行所有放入隊列的命令，然後恢復正常的連接狀態.其中當使用WATCH命令時，只有當受監控的鍵沒有被修改時，EXEC命令纔會執行事務中的命令，這種方式利用了檢查再設置（CAS）樂觀鎖的機制。返回值是一個數組，其中的每個元素分別是原子化事務中的每個命令的返回值。 當使用WATCH命令時，如果事務執行中止，那麼EXEC命令就會返回一個Null值

3.3 DISCARD

  清除所有先前在一個事務中放入隊列的命令，然後恢復正常的連接狀態。若使用了WATCH命令，那麼DISCARD命令就會將當前連接監控的所有鍵取消監控

3.4 WATCH

  當某個事務需要按條件執行時，就要使用這個命令將給定的鍵設置爲受監控的

3.5 UNWATCH

  清除所有先前爲一個事務監控的鍵

3.6 什麼時候回滾，什麼時候不回滾

回滾： 調用EXEC命令之前發生的錯誤會回滾，比如 語法有錯誤
不回滾： 調用EXEC命令之後發生的錯誤會回滾，比如命令格式沒有錯誤但是內部值的類型不匹配，比如給一個string類型數據進行incr操作

3.7 redis爲什麼不支持回滾

  在事務運行期間，雖然Redis命令可能會執行失敗，但是Redis仍然會執行事務中餘下的其他命令，而不會執行回滾操作，你可能會覺得這種行爲很奇怪。然而，這種行爲也有其合理之處：只有當被調用的Redis命令有語法錯誤時，這條命令纔會執行失敗（在將這個命令放入事務隊列期間，Redis能夠發現此類問題），或者對某個鍵執行不符合其數據類型的操作：實際上，這就意味着只有程序錯誤纔會導致Redis命令執行失敗，這種錯誤很有可能在程序開發期間發現，一般很少在生產環境發現。 Redis已經在系統內部進行功能簡化，這樣可以確保更快的運行速度，因爲Redis不需要事務回滾的能力。對於Redis事務的這種行爲，有一個普遍的反對觀點，那就是程序有可能會有缺陷（bug）。但是，你應當注意到：事務回滾並不能解決任何程序錯誤。例如，如果某個查詢會將一個鍵的值遞增2，而不是1，或者遞增錯誤的鍵，那麼事務回滾機制是沒有辦法解決這些程序問題的。請注意，沒有人能解決程序員自己的錯誤，這種錯誤可能會導致Redis命令執行失敗。正因爲這些程序錯誤不大可能會進入生產環境，所以我們在開發Redis時選用更加簡單和快速的方法，沒有實現錯誤回滾的功能（來自網絡）

4. 集羣

4.1 主從複製

存在的最大問題就是不能實現高可用：當主節點出現故障時，從節點不能自動晉升爲主節點，主要手動修改

4.2 哨兵

4.2.1 redis sentinel客戶端連實現原理

1. 遍歷Sentinel節點集合獲取一個可用的Sentinel節點，後面會介紹Sentinel節點之間可以共享數據， 所以從任意一個Sentinel節點獲取主節點信息都是可以的
   
2. 通過sentinel get-master-addr-by-name master-name這個API來獲取對應主節點的相關信息
   
3. 驗證當前獲取的“主節點”是真正的主節點，這樣做的目的是爲了防止故障轉移期間主節點的變化
   
4. 保持和Sentinel節點集合的“聯繫”，時刻獲取關於主節點的相關“信息”
   
   從上面的模型可以看出，redis sentinel客戶端只有在初始化和切換主節點時需要和sentinel進行通信來獲取主節點信息，所以在設計客戶端時需要將sentinel節點集合考慮成配置（相關節點信息和變化）發現服務。

4.2.2 實現原理

1. 每隔1秒，每個sentinel節點會向主節點，從節點，其餘sentinel節點發送ping命令做一次心跳檢查機制，判斷這些節點是否可達
2. 每隔2秒，每個sentinel會向頻道發送當前sentinel節點和對主節點的判斷，同時其餘sentinel會訂閱該頻道，瞭解其他sentinel節點（是否有新sentinel節點加入）和它們對主節點的判斷（sentinel節點之間交換主節點數據，作爲後面客觀下線以及領導者選舉的依據）
3. 每隔10秒，每隔sentinel節點會向從節點和主節點發送info命令獲取最新拓撲結構
   1. 通過info命令，獲取從節點信息，這也是爲什麼sentinel節點不需要顯示配置監控節點
   2. 當有從節點加入時能立刻感知出來
   3. 節點不可達或故障轉以後，可以通過info命令實時更新節點拓撲信息

5. 應用場景

1. 數據緩存（商品數據、新聞、熱點數據）
2. 單點登錄
3. 秒殺、搶購
4. 網站訪問排名