淺入淺出redis----II

事務

和mysql一樣，redis的事務就是一組命令的集合，在事務執行程序中，會按照順序執行；不一樣的是，redis的單條命令是保證原子性的，但是redis的事務不保證原子性，redis事務也沒有隔離級別的概念；

• 開啟事務 – multi

• 命令入隊 – …

• 執行命令 – exec
  

• 放棄事務 – discard
  

  放棄事務后，之前的操作都不會生效

而事務的例外又分兩種：編譯時例外和運行時例外

• 編譯時例外

  當執行事務時，輸入的陳述句存在是個錯誤命令時（例如陳述句引數不正確），整個事務的陳述句都不會執行

• 運行時例外

  當執行事務時，輸入的陳述句存在語法錯誤時，除了該命令其他命令都正常執行（這一點就和mysql有很大區別）

持久化

redis是基于記憶體的資料庫，沒有I/O操作，因此redis資料的讀寫是單執行緒的，但是redis本身為了防止服務器例外退出，也支持兩種持久化方式，但是此持久本質上是為了下次啟動時資料的一個恢復，若是真的想持久的存盤資料，mysql還是占優勢的，

RDB

原理：redis會單獨fork一個子行程在指定的時間間隔內將記憶體中的資料

? 快照寫入磁盤，恢復時將快照檔案讀入記憶體；

持久化資料時會先將資料寫入到一個臨時的edb檔案中，因為將資料寫入磁盤需要時間，而在這時間內得保證資料得完整性，（寫入磁盤是由子行程進行的，主行程不涉及IO操作，主行程就可以繼續處理一些請求，保證了一個高性能）將資料完整的寫入臨時檔案中，再用這個臨時檔案去替換上一次持久化好的檔案

因此它的缺點也很明顯，RDB最后一次持久化的資料就可能丟失了（既然是最后一次持久化，就說明資料還沒寫完主機就宕機了），redis最短時間是60s一次持久化操作，因此它最多丟失前59s處理的資料，

rdb的持久化資料在dump.rdb里邊保存著

而rdb持久化觸發的條件有三個

• save規則滿足的情況下，會自動觸發rdb操作

• 執行flushall命令時，會有引數提示觸發rdb操作

• 退出redis時，也會有引數提示觸發rdb操作

  • 優點：適合大規模資料恢復

  • 缺點：

    ? 1.需要一定的時間間隔進行持久化操作，如果redis意外宕機，那最后一次持久化的資料就丟失了，

    ? 2.fork子行程，需要占用一定的記憶體空間，

AOF

原理：將所有寫操作（history）的命令都記錄下來，恢復時將所有命令執行一遍，(與RDB不同之處：一個保存的是命令，一個是快照檔案（資料）)

AOF保存檔案是appendonly.aof

redis默認的是RDB持久化方式，AOF需要手動開啟，兩者不沖突，因為存的東西不一樣，而AOF默認持久化方式是每秒執行一次，也有每次操作執行一次持久化的，

• 優點：每一次修改都可以恢復，完整性較高

• 缺點：

  ? 1.每秒執行一次的話，最多丟失1s的資料；

  ? 2.存盤的資料檔案大小：aof遠遠大于rdb

  ? 3.aof運行效率慢于rdb

發布訂閱

發布訂閱是一種訊息通信模式，訂閱者提前訂閱訊息，發布者發布訊息后，redis推送給訂閱者

注意：訂閱者訂閱后會原地阻塞，等待著發布者發布對應的訊息，

主從復制

主從復制就是將一個redis服務器的資料，復制到其他redis服務器，前者和后者分別對應的是主節點和從節點，資料的復制是單向的！

默認情況，所有的redis服務器都是主節點，一個節點可以有多個從節點，從節點需要指出其跟隨的主節點

主要作用：

• 資料冗余：主從復制實作了資料的熱備份，每寫一次資料，都會復制到其從節點上，
• 故障恢復：主節點意外宕機時，從節點可以提供服務，實作快速的故障恢復，
• 負載均衡：主節點和從節點的讀寫分離，分擔了服務器的負載，特別是在寫少讀多的情況下保證了一個高并發，
• 高可用的基石：主從復制是哨兵模式和集群能夠實作的基礎，

復制原理：

• **全量復制：**從節點在收到資料庫檔案后，將其存盤并加載到記憶體中
• **增量復制：**直接點將新的所有收集到的修改命令一次傳給從節點

哨兵模式

自動選取主節點的模式，一般不是哨兵模式時，在主節點服務器例外退出時，從節點還能讀到對應的資料只是對應的主節點（老大）狀態是offline，當主節點再次上線時，還是之前從節點的主節點，

但是！哨兵模式下！哨兵是一個單獨的行程，通過一定的心跳機制（通過發送命令，等待服務器回應）檢測著幾個服務器，一旦主節點宕機，便隨機挑選一個從節點作為主節點，并通過發布訂閱機制通知其他節點服務器使其更改組態檔，

一個哨兵行程往往存在隱患，假如這個哨兵也例外退出了，就會出現問題，朝中不可一日無主！

便有了多哨兵模式，就是多個哨兵行程，哨兵之間互相監測，每個哨兵都對每個節點進行檢測；

一旦一個哨兵發現主節點宕機后，便會出現主觀下線現象，因為一個哨兵并不能拿捏，若其他哨兵也發現了，而且當發現的哨兵數量達到一定的值時，便會進行一次投票來決定新的主節點，這個程序稱為客觀下線，

• 優點：

  ? -基于主從復制模式，主從復制所有的優點它都有

  ? -主從的主可以切換，故障可以轉移，高可用性！

  ? -哨兵模式就是主從模式的升級，選主節點由手動便自動，更方便！

• 缺點：

  ? -哨兵模式的配置很麻煩，選項多，

redis快取穿透、擊穿和雪崩

快取穿透

快取穿透是指 用戶要查詢的資料快取和資料庫都沒有，快取一直不命中，多次去持久層資料庫查詢，給資料庫造成很大壓力，

解決辦法

1.布隆過濾器

? 布隆過濾器是一種資料結構，對所有可能查詢的引數以hash形式存盤，在控制層先進行校驗，不符合的則丟棄，從而避免對持久層資料庫的查詢壓力，

2.快取空物件

? 當持久層不命中后，及時快取回傳的空物件，同時設定一個過期時間，當再次訪問該值時將從快取中獲取，保護了持久層資料，

不足：

? -會消耗更多的空間存盤更多的key來快取空值

? -對需要保持一直性的業務有影響，可能在過期時間內，該key對應的值被存在資料庫永久層里，會導致快取層和資料層的不一致

快取擊穿

快取擊穿主要針對一些熱點key，扛著大量并發，在這個key失效的瞬間，資料層瞬間壓力過大甚至崩潰

解決辦法

1.熱點資料永不過期

? 根據字面意思很容易知道，在快取層，熱點資料不設定過期時間，所以不存在熱點資料過期的問題，

2.加互斥鎖

? 分布式鎖：保證每個key同時只有一個執行緒去查詢，其他執行緒沒有獲得鎖只能等待，對分布式鎖的考驗大

快取雪崩

快取雪崩是在快取擊穿的基礎上，大面積快取資料失效，或者redis宕機，導致大量訪問查詢都落在資料層，直接崩潰！

解決辦法

1.redis高可用

搭建快取服務器集群，這樣一臺服務器宕機還可以繼續作業

2.資料預熱

在正式部署之前，先把可能的資料先訪問一遍，這樣大量訪問的資料就會加載到快取中，在即將發生大并發訪問前手動觸發加載快取不同的key，設定不同的過期時間，讓快取失效的時間點盡量均勻，（這方面阿里老懂哥了！）