MySQL

RDB

在指定的時間間隔內將記憶體中的資料集快照寫入磁碟，也就是行話講的Snapshot快照，它恢復時是將快照檔案直接讀到記憶體裡。Redis會單獨建立( fork)一個子程序來進行持久化，會先將資料寫入到一個臨時檔案中，待持久化過程都結束了，再用這個臨時檔案替換，上次持久化好的檔案。整個過程中,主程序是不進行任何I0操作的。這就確保了極高的效能。如果需要進行大規模資料的恢復，且對於資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的資料可能丟失。我們預設的就是RDB ，一般情況下不需要修改這個配置。

rdb儲存的檔案是dump.rdb

1、save的規則滿足的情況下,會自動觸發rdb規則
2、執行flushall命令,也會觸發我們的rdb規則! 
3、退出redis ,也會產生rdb檔案!

恢復RDB

只需要將rdb檔案放在我們redis啟動目錄就可以, redis啟動的時候會自動檢查dump.rdb恢復其中的資料；
檢視需要存在的位置
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" //如果在這個目錄下存在dump.rdb 檔案，啟動就會自動恢復其中的資料

RDB自己預設的配置就夠用了，但是我們還是需要去學習

AOF（Append Only File）

以日誌的形式來記錄每個寫操作，將Redis執行過的所有指令記錄下來(讀操作不記錄)。只許追加檔案但不可以改寫檔案， redis啟動之初會讀取該檔案重新構建資料，換言之，redis重啟的話就根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的恢復工作。

AOF儲存的是appendonly.aof檔案

預設是不開啟的，我們需要手動進行配置!我們只需要將appendonly改為yes就開啟了AOF
重啟redis就可以生效了!
如果這個AOF檔案有錯位,這時候redis是啟動不起來的嗎,我們需要修復這個AOF檔案
redis給我們提供了一個工具redis-check-aof --fix
 

優點：
每一次修改都同步,檔案的完整會更加好；
每秒同步一次,可能會丟失一秒的資料；
從不同步,效率最高的。
缺點：
相對於資料檔案來說，AOF遠遠大於RDB，修復的速度也比RDB慢；
AOF執行效率也要比RDB慢,所以我們redis預設的配置就是RDB持久化。

擴充套件:

1. RDB持久化方式能夠在指定的時間間隔內對你的資料進行快照儲存；
2. AOF持久化方式記錄每次對伺服器寫的操作，當伺服器重啟的時候會重新執行這些命令來恢復原始的資料,，AOF命令以Redis協議追加儲存每次寫的操作到檔案末尾，Redis還能對AOF檔案進行後臺重寫，使得AOF檔案的體積不至於過大；
3. 只做快取，如果你只希望你的資料在伺服器執行的時候存在，你也可以不使用任何持久化； 同時開啟兩種持久化方式：
   （i）在這種情況下，當redis重啟的時候會優先載入AOF檔案來恢復原始的資料,因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整。
   （ii）RDB的資料不實時，同時使用兩者時伺服器重啟也只會找AOF檔案,那要不要只使用AOF呢？作者建議不要，因為RDB更適合用於備份資料庫( AOF在不斷變化不好備份) ，快速重啟，而且不會有AOF可能潛在的Bug，留著作為一個萬一的手段；
4. 效能建議
   （i） 因為RDB檔案只用作後備用途，建議只在Slave上持久化RDB檔案，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。
   （ii） 如果Enable AOF，好處是在最惡劣情況下也只會丟失不超過兩秒資料，啟動指令碼較簡單隻load自己的AOF檔案就可以了，代價一是帶來了持續的I0，二是AOF rewrite的最後將rewrite過程中產生的新資料寫到新檔案造成的阻塞幾乎是不可避免的。只要硬碟許可,應該儘量減少AOF rewrite的頻率， AOF重寫的基礎大小預設值64M太小了，可以設到5G以上,預設超過原大小100%大小重寫可以改到適當的數值。
   （iii）如果不Enable AOF，僅靠Master-Slave Repllcation實現高可用性也可以,能省掉一 大筆IO ，也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的資料,啟動指令碼也要比較兩個Master/Slave中的RDB檔案，載入較新的那個，微博就是這種架構。

redis釋出訂閱

Redis釋出訂閱(pub/sub)是一種訊息通訊模式:傳送者(pub)傳送訊息，訂閱者(sub)接收訊息。Redis客戶端可以訂閱任意數量的頻道。
訂閱/釋出訊息圖:

命令（這些命令被廣泛用於構建即時通訊應用，比如聊天室和廣播）

訂閱端：

127.0.0.1:6379> SUBSCRIBE kuangshenshuo  # 訂閱一個頻道kuangshenshuo
Reading messages... (press ctrl-C to quit)
1) "subscribe"
2) "kuangshenshuo"
3) (integer) 1
#等待讀取推送的資訊
1) "message" # 訊息
2) "kuangshenshuo" # 那個頻道的訊息
3) "hello, kuangshen" #訊息的具體內容
1) "message"
2) "kuangshenshuo"
3) "hello, redis"

傳送端:

127.0.0.1:6379> PUBLISH kuangshenshuo "hello, kuangshen" # 釋出者釋出訊息到頻道!
(integer) 1
127.0.0.1:6379> PUBLISH kuangshenshuo "hello,redis" # 釋出者釋出訊息到頻道!
(integer) 1

原理：

1. Redis是使用C實現的，通過分析Redis原始碼裡的pubsub.c檔案，瞭解釋出和訂閱機制的底層實現，籍此加深對Redis的理解。
2. Redis通過PUBLISH、SUBSCRIBE 和PSUBSCRIBE等命令實現釋出和訂閱功能。
3. 通過SUBSCRIBE命令訂閱某頻道後，redis-server裡維護了一個字典，字典的鍵就是一個個channel，而字典的值則是一個連結串列，連結串列中儲存了所有訂閱這個channel的客戶端。SUBSCRIBE 命令的關鍵，就是將客戶端新增到給定channel的訂閱連結串列中。
4. 通過PUBLISH命令向訂閱者傳送訊息，redis-server會使用給定的頻道作為鍵，在它所維護的channel字典中查詢記錄了訂閱這個頻道的所有客戶端的連結串列，遍歷這個連結串列，將訊息釋出給所有訂閱者。
5. Pub/Sub從字面上理解就是釋出( Publish )與訂閱( Subscribe)，在Redis中,你可以設定對某一個key值進行訊息釋出及訊息訂閱，當一個key值上進行了訊息釋出後，所有訂閱它的客戶端都會收到相應的訊息。這一功能最明顯的用法就是用作實時訊息系統，比如普通的即時聊天，群聊等功能。

主從複製—哨兵模式

概念

1. 主從複製，是指將一臺Redis伺服器的資料，複製到其他的Redis伺服器。前者稱為主節點(master/leader)，後者稱為從節點(slave/follower)；資料的複製是單向的，只能由主節點到從節點。Master以寫為主，Slave以讀為主。
2. 預設情況下，每臺Redis伺服器都是主節點;且一個主節點可以有多個從節點(或沒有從節點)，但一個從節點只能有一個主節點。

主從複製的作用主要包括:

1. 資料冗餘：主從複製實現了資料的熱備份，是持久化之外的一種資料冗餘方式。
2. 故障恢復：當主節點出現問題時，可以由從節點提供服務,實現快速的故障恢復；實際上是一種服務的冗餘。
3. 負載均衡：在主從複製的基礎上，配合讀寫分離，可以由主節點提供寫服務，由從節點提供讀服務(即寫Redis資料時應用連線主節點，讀Redis資料時應用連線從節點)，分擔伺服器負載；尤其是在寫少讀多的場景下，通過多個從節點分擔讀負載，可以大大提高Redis伺服器的併發量。
4. 高可用基石：除了上述作用以外,主從複製還是哨兵和叢集能夠實施的基礎，因此說主從複製是Redis高可用的基礎。
   一般來說，要將Redis運用於工程專案中,只使用一臺Redis是萬萬不能的，原因如下:
   從結構上，單個Redis伺服器會發生單點故障，並且一臺伺服器需要處理所有的請求負載，壓力較大；
   從容量上，單個Redis伺服器記憶體容量有限，就算一臺Redis伺服器記憶體容量為256G，也不能將所有記憶體用作Redis儲存記憶體，一般來說，單臺Redis最大使用記憶體不應該超過20G。電商網站上的商品，一般都是一次上傳，無數次瀏覽的，說專業點也就是"多讀少寫"。

對於這種場景，我們使用以下這種架構：
（主從複製，讀寫分離， 80% 的情況下都是在進行讀操作；減緩伺服器的壓力）

環境配置（Linux系統）

127.0.0.1:6379> info replication   //檢視當前庫的資訊
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

1. 複製3個配置檔案,然後修改對應的資訊;
   a. 埠；b. pid名字；c. log檔名字；d. dump.rdb 名字
2. 修改完畢之後,啟動我們的3個redis伺服器,可以通過程序資訊檢視!
   

一主二從

預設情況下每臺Redis伺服器都是主節點；我們一般情況下只用配置從機就好了。

 1. 0.0.1:6380> SLAVEOF 127.0.0.1 6379  //SLAVEOF host 6379 找誰當自己的主機
127.0.0.1:6380> info replication   //檢視配置後的資訊

細節

1. 主機可以寫，從機不能寫只能讀；主機中的所有資訊和資料，都會自動被從機儲存。
2. 主機斷開連線，從機依舊連線到主機的，但是沒有寫操作，這個時候,主機如果回來了，從機依舊可以直接獲取到主機寫的資訊。

複製原理

1. Slave啟動成功連線到master後會傳送一個sync同步命令；
2. Master接到命令，啟動後臺的存檔程序，同時收集所有接收到的用於修改資料集命令,在後臺程序執行完畢之後，master將傳送整個資料檔案到slave ,並完成一次完全同步；
3. 全量複製：而slave服務在接收到資料庫檔案資料後，將其存檔並載入到記憶體中；
4. 增量複製：Master繼續將新的所有收集到的修改命令依次傳給slave ，完成同步；
5. 但是隻要是重新連線master，一次完全同步(全量複製)將被自動執行。

擴充套件：（層層鏈路）

哨兵模式（自動選舉主節點）

1. 主從切換技術的方法是：當主伺服器宕機後,需要手動把一臺從伺服器切換為主伺服器,這就需要人工干預，費事費力，還會造成一段時間內服務不可用。這不是一種推薦的方式，更多時候，我們優先考慮哨兵模式。Redis從2.8開始正式提供了Sentinel (哨兵)架構來解決這個問題。
2. 自動版：能夠後臺監控主機是否故障，如果故障了根據投票數自動將從庫轉換為主庫，故障後的主機如果回來了會自動歸併到新的主機下變成從機；
3. 哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的程序，作為程序，它會獨立執行。其原理是哨兵通過傳送命令，等待Redis伺服器響應，從而監控執行的多個Redis例項。
   
   這裡的哨兵有兩個作用：
   1、通過傳送命令，讓Redis伺服器返回監控其執行狀態，包括主伺服器和從伺服器；
   2、當哨兵監測到master宕機，會自動將slave切換成master，然後通過釋出訂閱模式通知其他的從伺服器，修改配置檔案，讓它們切換主機。
   然而一個哨兵程序對Redis伺服器進行監控，可能會出現問題，為此，我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。
   

假設主伺服器宕機，哨兵1先檢測到這個結果，系統並不會馬上進行failover過程，僅僅是哨兵1主觀的認為主伺服器不可用，這個現象成為主觀下線。當後面的哨兵也檢測到主伺服器不可用，並且數量達到一定值時，那麼哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover[故障轉移]操作。 切換成功後，就會通過釋出訂閱模式，讓各個哨兵把自己監控的從伺服器實現切換主機，這個過程稱為客觀下線。

測試
// 我們目前的狀態是一主二從!
// 配置哨兵配置檔案sentinel.conf
monitor被監控的名稱host port 1
sentine1 monitor myredis 127.0.0.1 6379 1
//後面的這個數字1，代表主機掛了
//slave投票看讓誰接替成為主機,票數最多的,就會成為主機

哨兵模式總結

優點：

1. 哨兵叢集，基於主從複製模式，所有的主從配置優點，它全有；
2. 主從可以切換，故障可以轉移，系統的可用性就會更好；
3. 哨兵模式就是主從模式的升級，手動到自動，更加健壯。

缺點：

1. Redis不好線上擴容的，叢集容量一旦到達上限，線上擴容就十分麻煩；
2. 實現哨兵模式的配置其實是很麻煩的，裡面有很多選擇。

配置：

port 26379
dir /tmp     #哨兵sentine1的工作目錄

#哨兵sentinel監控的redis主節點的ip port


# master-name 可以自己命名的主節點名字 只能由字母A-Z、數字0-9、這三個字元".-_"組成。
# quorum 配置多少個sentinel哨兵統一認為master主節點失聯,那麼這時客觀上認為主節點失聯了
# sentine1 monitor <master-name> <ip> <redis-port> <quorum>
sentine1 monitor mymaster 127.0.0.1 6379 2

#當在Redis例項中開啟了requirepass foobared 授權密碼 這樣所有連線Redis例項的客戶端都要提供密碼
#設定哨兵sentinel 連線主從的密碼 注意必須為主從設定一樣的驗證密碼
# sentineL auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd

#指定多少毫秒之後主節點沒有應答哨兵sentine]此時哨兵主觀上認為主節點下線預設30秒
# sentinel down-after-milliseconds <maste r-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000

#這個配置項指定了在發生failover主備切換時最多可以有多少個slave同時對新的master進行同步，
這個數字越小，完成failover所需的時間就越長，
但是如果這個數字越大，就意味著越多的slave因為replication而不可用。
可以通過將這個值設為1來保證每次只有一一個slave處於不能處理命令請求的狀態。
# sentinel paralle1-syncs <master-name> <nums1aves>
sentinel parallel-syncs mymaster 1

#故障轉移的超時時間failover-timeout可以用在以下這些方面:
#1.同一個sentinel對同一個master兩次failover之間的間隔時間。
#2.當一個slave從一個錯誤的master那裡同步資料開始計算時間,直到slave被糾正為向正確的master那裡同步資料時。
#3.當想要取消一個正在進行的failover所需要的時間。
#4.當進行failover時，配置所有slaves指向新的master所需的最大時間。不過，即使過了這個超時，slaves 依然會被正確配置為指向
master,但是就不按parallel-syncs所配置的規則來了
#預設三分鐘
# sentinel failover-ti meout <master-name> <milliseconds>
sentinel fai lover-ti meout mymaster 180000

# SCRIPTS EXECUTION

#配置當某一事件發生時所需要執行的指令碼，可以通過指令碼來通知管理員，例如當系統執行不正常時發郵件通知相關人員。
#對於指令碼的執行結果有以下規則:
#若指令碼執行後返回1，那麼該指令碼稍後將會被再次執行，重複次數目前預設為10
#若指令碼執行後返回2，或者比2更高的一個返回值，指令碼將不會重複執行。
#如果指令碼在執行過程中由於收到系統中斷訊號被終止了，則同返回值為1時的行為相同。
#一個指令碼的最大執行時間為60s，如果超過這個時間，指令碼將會被一個SIGKILL訊號終止，之後重新執行。
#通知型指令碼:當sentinel有任何警告級別的事件發生時(比如說redis例項的主觀失效和客觀失效等等)，將會去呼叫這個指令碼，這時這個
指令碼應該通過郵件，SMS等方式去通知系統管理員關於系統不正常執行的資訊。呼叫該指令碼時，將傳給指令碼兩個引數，一個是事件的型別，一
個是事件的描述。如果sentinel.conf配置檔案中配置了這個指令碼路徑，那麼必須保證這個指令碼存在於這個路徑，並且是可執行的，否則
sentinel無法正常啟動成功。
#通知指令碼
# sentine1 notificati on-script <master-name> <script-path>
sentine1 notificati on-script mymaster /var/redis/notify.sh

#客戶端重新配置主節點引數指令碼
#當一個master由於failover而發生改變時，這個指令碼將會被呼叫，通知相關的客戶端關於master地址已經發生改變的資訊。
#以下引數將會在呼叫指令碼時傳給指令碼:
# <master-name> <ro1e> <state> <from-ip> <from-port> <to-ip> <to-port>
#目前<state> 總是"failover",
# <role>是"eader"或者"observer"中的一個。
#引數from-ip，from-port, to-ip, to-port 是用來和舊的master和新的master (即舊的slave)通訊的
#這個指令碼應該是通用的，能被多次呼叫，不是針對性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/ redis/reconfig.sh 

問題

快取穿透（查不到）

概念

快取穿透的概念很簡單，使用者想要查詢一個數據，發現redis記憶體資料庫沒有，也就是快取沒有命中，於是向持久層資料庫查詢。發現也沒有，於是本次查詢失敗。當用戶很多的時候，快取都沒有命中，於是都去請求了持久層資料庫。這會給持久層資料庫造成很大的壓力，這時候就相當於出現了快取穿透。

解決方案

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

快取空物件：當儲存層不命中後，即使返回的空物件也將其快取起來，同時會設定一個過期時間，之後再訪問這個資料將會從快取中獲取，保護了後端資料來源；
但是這種方法會存在兩個問題:

1. 如果空值能夠被快取起來，這就意味著快取需要更多的空間儲存更多的鍵，因為這當中可能會有很多的空值的鍵；
2. 即使對空值設定了過期時間，還是會存在快取層和儲存層的資料會有一段時間視窗的不一 致，這對於需要保持一致性的業務會有影響。

快取擊穿（查得到，量太大了）

概念

1. 這裡需要注意和快取擊穿的區別，快取擊穿是指一個key非常熱點在不停的扛著大併發，大併發集中對這一個點進行訪問，當這個key在失效的瞬間，持續的大併發就穿破快取，直接請求資料庫，就像在一個屏障上鑿開了一個洞。
2. 當某個key在過期的瞬間，有大量的請求併發訪問，這類資料一般是熱點資料,由於快取過期，會同時訪問資料庫來查詢最新資料，並且回寫快取，會導使資料庫瞬間壓力過大。

解決方案

1. 設定熱點資料永不過期：從快取層面來看，沒有設定過期時間，所以不會出現熱點key過期後產生的問題。
2. 加互斥鎖：分散式鎖–使用分散式鎖，保證對於每個key同時只有一個執行緒去查詢後端服務，其他執行緒沒有獲得分散式鎖的許可權，因此只需要等待即可。這種方式將高併發的壓力轉移到了分散式鎖，因此對分散式鎖的考驗很大。

快取雪崩

概念

1. 快取雪崩,是指在某一個時間段,快取集中過期失效。Redis 宕機。
2. 產生雪崩的原因之一，比如在寫本文的時候，馬上就要到雙十二零點，很快就會迎來一波搶購，這波商品時間比較集中的放入了快取，假設快取一個小時。
   那麼到了凌晨一點鐘的時候，這批商品的快取就都過期了。而對這批商品的訪問查詢，都落到了資料庫上，對於資料庫而言，就會產生週期性的壓力波峰。於是所有的請求都會達到儲存層，儲存層的呼叫量會暴增，造成儲存層也會掛掉的情況。
   

其實集中過期，倒不是非常致命，比較致命的快取雪崩，是快取伺服器某個節點宕機或斷網。因為自然形成的快取雪崩，一定是在某個時間段集中建立快取，這個時候，資料庫也是可以頂住壓力的。無非就是對資料庫產生週期性的壓力而已。而快取服務節點的
宕機，對資料庫伺服器造成的壓力是不可預知的，很有可能瞬間就把資料庫壓垮。

解決方案

1.redis高可用：這個思想的含義是，既然redis有可能掛掉，那我多增設幾臺redis，這樣一臺掛掉之後其他的還可以繼續工作，其實就是搭建的叢集；
2. 限流降級（SpringCloud）：這個解決方案的思想是在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許一個執行緒查詢資料和寫快取，其他執行緒等待。
3. 資料預熱：資料加熱的含義就是在正式部署之前，我先把可能的資料先預先訪問一遍，這樣部分可能大量訪問的資料就會載入到快取中。在即將發生大併發訪問前手動觸發載入快取不同的key，設定不同的過期時間，讓快取失效的時間點儘量均勻。

文章目錄