狂神說redis筆記（四）
十二、Redis主從複製
概念
主從複製，是指將一臺Redis伺服器的資料，複製到其他的Redis伺服器。前者稱為主節點（Master/Leader）,後者稱為從節點（Slave/Follower）， 資料的複製是單向的！只能由主節點複製到從節點（主節點以寫為主、從節點以讀為主）。
預設情況下，每臺Redis伺服器都是主節點，一個主節點可以有0個或者多個從節點，但每個從節點只能由一個主節點。
作用
- 資料冗餘：主從複製實現了資料的熱備份，是持久化之外的一種資料冗餘的方式。
- 故障恢復：當主節點故障時，從節點可以暫時替代主節點提供服務，是一種服務冗餘的方式
- 負載均衡：在主從複製的基礎上，配合讀寫分離，由主節點進行寫操作，從節點進行讀操作，分擔伺服器的負載；尤其是在多讀少寫的場景下，通過多個從節點分擔負載，提高併發量。
- 高可用基石：主從複製還是哨兵和叢集能夠實施的基礎。
為什麼使用叢集
一般來說，要將Redis運用於工程專案中，只使用一臺Redis是萬萬不能的（宕機），原因如下：
1、從結構上，單個Redis伺服器會發生單點故障，並且一臺伺服器需要處理所有的請求負載，壓力較大；
2、從容量上，單個Redis伺服器記憶體容量有限，就算一臺Redis伺服器記憶體容量為256G，也不能將所有記憶體用作Redis儲存記憶體，一般來說，單臺Redis最大使用記憶體不應該超過20G。
電商網站上的商品，一般都是一次上傳，無數次瀏覽的，說專業點也就是"多讀少寫"。
對於這種場景，我們可以使如下這種架構：
主從複製，讀寫分離！ 80% 的情況下都是在進行讀操作！減緩伺服器的壓力！架構中經常使用！ 一主二從！
只要在公司中，主從複製就是必須要使用的，因為在真實的專案中不可能單機使用Redis！
總結
- 單臺伺服器難以負載大量的請求
- 單臺伺服器故障率高，系統崩壞概率大
- 單臺伺服器記憶體容量有限。
環境配置
只配置從庫，不用配置主庫！
127.0.0.1:6379> info replication # Replication role:master # 角色 connected_slaves:0 # 從機數量 master_replid:3b54deef5b7b7b7f7dd8acefa23be48879b4fcff master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0
複製3個配置檔案，然後修改對應的資訊
- 埠
- pid名字
- log檔名
- dump.rdb名字
啟動單機多服務叢集：
一主二從配置
預設情況下，每臺Redis伺服器都是主節點；我們一般情況下只用配置從機就好了！
認老大！一主（79）二從（80，81）
使用SLAVEOF host port就可以為從機配置主機了。
說明
SLAVEOF host 6379找誰當自己的老大！role:slave# 當前角色是從機master_host:127.0.0.1# 可以的看到主機的資訊
然後主機上也能看到從機的狀態：
說明
connected_slaves:1# 多了從機的配置slave0:ip=127.0.0.1,port=6380,state=online,offset=42,lag=1# 多了從機的配置
真實的從主配置應該在配置檔案中配置，這樣的話是永久的，我們這裡使用的是命令，暫時的！
使用規則
1.從機只能讀，不能寫，主機可讀可寫但是多用於寫。
127.0.0.1:6381> set name sakura # 從機6381寫入失敗 (error) READONLY You can't write against a read only replica.127.0.0.1:6380> set name sakura # 從機6380寫入失敗
(error) READONLY You can't write against a read only replica.
127.0.0.1:6379> set name sakura
OK
127.0.0.1:6379> get name
"sakura"
2.當主機斷電宕機後，預設情況下從機的角色不會發生變化 ，叢集中只是失去了寫操作，當主機恢復以後，又會連線上從機恢復原狀。
3.當從機斷電宕機後，若不是使用配置檔案配置的從機，再次啟動後作為主機是無法獲取之前主機的資料的，若此時重新配置稱為從機，又可以獲取到主機的所有資料。這裡就要提到一個同步原理。
4.第二條中提到，預設情況下，主機故障後，不會出現新的主機，有兩種方式可以產生新的主機：
- 從機手動執行命令slaveof no one,這樣執行以後從機會獨立出來成為一個主機
- 使用哨兵模式（自動選舉）
如果沒有老大了，這個時候能不能選擇出來一個老大呢？手動！
如果主機斷開了連線，我們可以使用SLAVEOF no one讓自己變成主機！其他的節點就可以手動連線到最新的主節點（手動）！如果這個時候老大修復了，那麼就重新連線！
複製原理
Slave 啟動成功連線到 master 後會傳送一個sync同步命令
Master 接到命令，啟動後臺的存檔程序，同時收集所有接收到的用於修改資料集命令，在後臺程序執行完畢之後，master將傳送整個資料檔案到slave，並完成一次完全同步。
全量複製：而slave服務在接收到資料庫檔案資料後，將其存檔並載入到記憶體中。
增量複製：Master 繼續將新的所有收集到的修改命令依次傳給slave，完成同步
但是隻要是重新連線master，一次完全同步（全量複製）將被自動執行！ 我們的資料一定可以在從機中看到！
十三、哨兵模式
（自動選舉老大的模式）
概述
主從切換技術的方法是：當主伺服器宕機後，需要手動把一臺從伺服器切換為主伺服器，這就需要人工干預，費事費力，還會造成一段時間內服務不可用。這不是一種推薦的方式，更多時候，我們優先考慮哨兵模式。Redis從2.8開始正式提供了Sentinel（哨兵） 架構來解決這個問題。能夠後臺監控主機是否故障，如果故障了根據投票數自動將從庫轉換為主庫。
哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的程序，作為程序，它會獨立執行。其原理是哨兵通過傳送命令，等待Redis伺服器響應，從而監控執行的多個Redis例項。
哨兵的作用：
- 通過傳送命令，讓Redis伺服器返回監控其執行狀態，包括主伺服器和從伺服器。
- 當哨兵監測到master宕機，會自動將slave切換成master，然後通過釋出訂閱模式通知其他的從伺服器，修改配置檔案，讓它們切換主機。
然而一個哨兵程序對Redis伺服器進行監控，可能會出現問題，為此，我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。
假設主伺服器宕機，哨兵1先檢測到這個結果，系統並不會馬上進行failover過程，僅僅是哨兵1主觀的認為主伺服器不可用，這個現象成為主觀下線。當後面的哨兵也檢測到主伺服器不可用，並且數量達到一定值時，那麼哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover[故障轉移]操作。切換成功後，就會通過釋出訂閱模式，讓各個哨兵把自己監控的從伺服器實現切換主機，這個過程稱為客觀下線。
測試
1、配置哨兵配置檔案 sentinel.conf
# sentinel monitor 被監控的名稱 host port 1
sentinel monitor myredis 127.0.0.1 6379 1
後面的這個數字1，代表主機掛了，slave投票看讓誰接替成為主機，票數最多的，就會成為主機！
2、啟動哨兵！
3、此時哨兵監視著我們的主機6379，當我們斷開主機後：
哨兵模式優缺點
優點：
- 哨兵叢集，基於主從複製模式，所有主從複製的優點，它都有
- 主從可以切換，故障可以轉移，系統的可用性更好
-
哨兵模式是主從模式的升級，手動到自動，更加健壯 缺點：
-
Redis不好線上擴容，叢集容量一旦達到上限，線上擴容就十分麻煩
- 實現哨兵模式的配置其實是很麻煩的，裡面有很多配置項
哨兵模式的全部配置
完整的哨兵模式配置檔案 sentinel.conf
# Example sentinel.conf哨兵sentinel例項執行的埠 預設26379
port 26379
哨兵sentinel的工作目錄
dir /tmp
哨兵sentinel監控的redis主節點的 ip port
master-name 可以自己命名的主節點名字 只能由字母A-z、數字0-9 、這三個字元".-_"組成。
quorum 當這些quorum個數sentinel哨兵認為master主節點失聯 那麼這時 客觀上認為主節點失聯了
sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 1
當在Redis例項中開啟了requirepass foobared 授權密碼 這樣所有連線Redis例項的客戶端都要提供密碼
設定哨兵sentinel 連線主從的密碼 注意必須為主從設定一樣的驗證密碼
sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
指定多少毫秒之後 主節點沒有應答哨兵sentinel 此時 哨兵主觀上認為主節點下線 預設30秒
sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
這個配置項指定了在發生failover主備切換時最多可以有多少個slave同時對新的master進行 同步，
這個數字越小，完成failover所需的時間就越長，
但是如果這個數字越大，就意味著越 多的slave因為replication而不可用。
可以通過將這個值設為 1 來保證每次只有一個slave 處於不能處理命令請求的狀態。sentinel parallel-syncs <master-name> <numslaves>
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-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
SCRIPTS EXECUTION
配置當某一事件發生時所需要執行的指令碼，可以通過指令碼來通知管理員，例如當系統執行不正常時發郵件通知相關人員。
對於指令碼的執行結果有以下規則：
若指令碼執行後返回1，那麼該指令碼稍後將會被再次執行，重複次數目前預設為10
若指令碼執行後返回2，或者比2更高的一個返回值，指令碼將不會重複執行。
如果指令碼在執行過程中由於收到系統中斷訊號被終止了，則同返回值為1時的行為相同。
一個指令碼的最大執行時間為60s，如果超過這個時間，指令碼將會被一個SIGKILL訊號終止，之後重新執行。
通知型指令碼:當sentinel有任何警告級別的事件發生時（比如說redis例項的主觀失效和客觀失效等等），將會去呼叫這個指令碼，
這時這個指令碼應該通過郵件，SMS等方式去通知系統管理員關於系統不正常執行的資訊。呼叫該指令碼時，將傳給指令碼兩個引數，
一個是事件的型別，
一個是事件的描述。
如果sentinel.conf配置檔案中配置了這個指令碼路徑，那麼必須保證這個指令碼存在於這個路徑，並且是可執行的，否則sentinel無法正常啟動成功。
通知指令碼
sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh
客戶端重新配置主節點引數指令碼
當一個master由於failover而發生改變時，這個指令碼將會被呼叫，通知相關的客戶端關於master地址已經發生改變的資訊。
以下引數將會在呼叫指令碼時傳給指令碼:
<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
目前<state>總是“failover”,
<role>是“leader”或者“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的形式儲存，以便快速確定是否存在這個值，在控制層先進行攔截校驗，校驗不通過直接打回，減輕了儲存系統的壓力。
快取空物件
一次請求若在快取和資料庫中都沒找到，就在快取中方一個空物件用於處理後續這個請求。
這樣做有一個缺陷：儲存空物件也需要空間，大量的空物件會耗費一定的空間，儲存效率並不高。解決這個缺陷的方式就是設定較短過期時間
即使對空值設定了過期時間，還是會存在快取層和儲存層的資料會有一段時間視窗的不一致，這對於需要保持一致性的業務會有影響。
快取擊穿（即量太大，快取過期）
概念
相較於快取穿透，快取擊穿的目的性更強，一個存在的key，在快取過期的一刻，同時有大量的請求，這些請求都會擊穿到DB，造成瞬時DB請求量大、壓力驟增。這就是快取被擊穿，只是針對其中某個key的快取不可用而導致擊穿，但是其他的key依然可以使用快取響應。
比如熱搜排行上，一個熱點新聞被同時大量訪問就可能導致快取擊穿。
解決方案
1.設定熱點資料永不過期
這樣就不會出現熱點資料過期的情況，但是當Redis記憶體空間滿的時候也會清理部分資料，而且此種方案會佔用空間，一旦熱點資料多了起來，就會佔用部分空間。
2.加互斥鎖(分散式鎖)
在訪問key之前，採用SETNX（set if not exists）來設定另一個短期key來鎖住當前key的訪問，訪問結束再刪除該短期key。保證同時刻只有一個執行緒訪問。這樣對鎖的要求就十分高。
快取雪崩
概念
大量的key設定了相同的過期時間，導致在快取在同一時刻全部失效，造成瞬時DB請求量大、壓力驟增，引起雪崩。
快取雪崩，是指在某一個時間段，快取集中過期失效。Redis 宕機！
產生雪崩的原因之一，比如在寫本文的時候，馬上就要到雙十二零點，很快就會迎來一波搶購，這波商品時間比較集中的放入了快取，假設快取一個小時。那麼到了凌晨一點鐘的時候，這批商品的快取就都過期了。而對這批商品的訪問查詢，都落到了資料庫上，對於資料庫而言，就會產生週期性的壓力波峰。於是所有的請求都會達到儲存層，儲存層的呼叫量會暴增，造成儲存層也會掛掉的情況。
其實集中過期，倒不是非常致命，比較致命的快取雪崩，是快取伺服器某個節點宕機或斷網。因為自然形成的快取雪崩，一定是在某個時間段集中建立快取，這個時候，資料庫也是可以頂住壓力的。無非就是對資料庫產生週期性的壓力而已。而快取服務節點的宕機，對資料庫伺服器造成的壓力是不可預知的，很有可能瞬間就把資料庫壓垮。
解決方案
redis高可用
這個思想的含義是，既然redis有可能掛掉，那我多增設幾臺redis，這樣一臺掛掉之後其他的還可以繼續工作，其實就是搭建的叢集
限流降級
這個解決方案的思想是，在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許一個執行緒查詢資料和寫快取，其他執行緒等待。
資料預熱
資料加熱的含義就是在正式部署之前，我先把可能的資料先預先訪問一遍，這樣部分可能大量訪問的資料就會載入到快取中。在即將發生大併發訪問前手動觸發載入快取不同的key，設定不同的過期時間，讓快取失效的時間點儘量均勻。