本套技術專欄是作者（秦凱新）平時工作的總結和昇華，並深度整理大量網上資源和專業書籍。通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。QQ郵箱地址：1120746959@qq.com，如有任何學術交流，可隨時聯絡。
1 Redis 工作模型
redis實際上是個單執行緒工作模型，其擁有較多的資料結構，並支援豐富的資料操作，redis目前是原生支援cluster模式。如果需要快取能夠支援更復雜的結構和操作，基於以上原因，選擇線上使用Redis會是不錯的選擇。
1.1 Redis 高效的原因：
-
Redis高效的原因：
1）純記憶體操作
2）核心是基於非阻塞的IO多路複用機制
3）單執行緒反而避免了多執行緒的頻繁上下文切換問題
-
mysql單機支撐到2000qps就會出現效能問題了，所以要是你有個系統，高峰期一秒鐘過來的請求有1萬，那一個mysql單機絕對會死掉。因為 redis單機支撐的併發量輕鬆一秒幾萬十幾萬，支撐高併發so easy。單機承載併發量是mysql單機的幾十倍。
-
使用Redis可能會遇到的問題：
- 快取與資料庫雙寫不一致
- 快取雪崩
- 快取穿透
- 快取併發競爭
1.2 檔案事件處理流程
-
(1) redis基於reactor模式開發了網路事件處理器，這個處理器叫做檔案事件處理器，file event handler。這個檔案事件處理器，是單執行緒的，redis才叫做單執行緒的模型，採用IO多路複用機制同時監聽多個socket，根據socket上的事件來選擇對應的事件處理器來處理這個事件。
-
(2) 檔案事件處理器的結構包含4個部分：多個socket，IO多路複用程式，檔案事件分派器，事件處理器（命令請求處理器、命令回覆處理器、連線應答處理器，等等）。
-
(3) 多個socket可能併發的產生不同的操作，每個操作對應不同的檔案事件，但是IO多路複用程式會監聽多個socket，但是會將socket放入一個佇列中排隊，每次從佇列中取出一個socket給事件分派器，事件分派器把socket給對應的事件處理器。
-
(4) 一個socket的事件處理完之後，IO多路複用程式才會將佇列中的下一個socket給事件分派器。檔案事件分派器會根據每個socket當前產生的事件，來選擇對應的事件處理器來處理。
1.3 檔案事件
-
如果一個客戶端跟redis發起連線，此時會產生一個AE_READABLE事件，然後由連線應答處理器來處理跟客戶端建立連線，建立客戶端對應的socket，同時將這個socket的AE_READABLE事件跟命令請求處理器關聯起來。
-
如果是客戶端要連線redis，那麼會為socket關聯連線應答處理器。
-
如果是客戶端要寫資料到redis，那麼會為socket關聯命令請求處理器。
-
如果是客戶端要從redis讀資料，那麼會為socket關聯命令回覆處理器。
1.4 客戶端與redis通訊流程
-
建立客戶端對應的socket
在redis啟動初始化的時候，redis會將連線應答處理器跟AE_READABLE事件關聯起來，接著如果一個客戶端跟redis發起連線，此時會產生一個AE_READABLE事件，然後由連線應答處理器來處理跟客戶端建立連線，建立客戶端對應的socket，同時將這個socket的AE_READABLE事件跟命令請求處理器關聯起來。
-
請求處理，socket產生一個AE_READABLE事件
當客戶端向redis發起請求的時候（不管是讀請求還是寫請求，都一樣），首先就會在socket產生一個AE_READABLE事件，然後由對應的命令請求處理器來處理。這個命令請求處理器就會從socket中讀取請求相關資料，然後進行執行和處理。
-
客戶端這讀取響應資料
接著redis這邊準備好了給客戶端的響應資料之後，就會將socket的AE_WRITABLE事件跟命令回覆處理器關聯起來，當客戶端這邊準備好讀取響應資料時，就會在socket上產生一個AE_WRITABLE事件，會由對應的命令回覆處理器來處理，就是將準備好的響應資料寫入socket，供客戶端來讀取。
-
命令回覆處理器寫完之後，就會刪除這個socket的AE_WRITABLE事件和命令回覆處理器的關聯關係。
2 redis 過期策略及記憶體淘汰機制
-
用記憶體當快取。記憶體是無限的嗎？記憶體是很寶貴而且是有限的，磁碟是廉價而且是大量的。可能一臺機器就幾十個G的記憶體，但是可以有幾個T的硬碟空間。redis主要是基於記憶體來進行高效能、高併發的讀寫操作的。
set key value 過期時間（1小時） set進去的key，1小時之後就沒了，就失效了，但是資料明明都過期了，怎麼還佔用著記憶體呢？ 複製程式碼 -
定期刪除+惰性刪除
所謂定期刪除，指的是redis預設是每隔100ms就隨機抽取一些設定了過期時間的key，檢查其是否過期，如果過期就刪除。假設redis裡放了10萬個key，都設定了過期時間，你每隔幾百毫秒，就檢查10萬個key，那redis基本上就死了，cpu負載會很高的，消耗在你的檢查過期key上了。注意，這裡可不是每隔100ms就遍歷所有的設定過期時間的key，那樣就是一場效能上的災難。實際上redis是每隔100ms隨機抽取一些key來檢查和刪除的。
所謂惰性刪除了，指的是在你獲取某個key的時候，redis會檢查一下 ，這個key如果設定了過期時間那麼是否過期了？如果過期了此時就會刪除，不會給你返回任何東西。
如果定期刪除漏掉了很多過期key，然後你也沒及時去查，也就沒走惰性刪除，此時會怎麼樣？如果大量過期key堆積在記憶體裡，導致redis記憶體塊耗盡了，也會出現嚴重的線上事故。
-
記憶體淘汰
如果redis的記憶體佔用過多的時候，此時會進行記憶體淘汰，有如下一些策略：
redis 10個key，現在已經滿了，redis需要刪除掉5個key 1個key，最近1分鐘被查詢了100次 1個key，最近10分鐘被查詢了50次 1個key，最近1個小時倍查詢了1次 複製程式碼1）noeviction：當記憶體不足以容納新寫入資料時，新寫入操作會報錯。
2）allkeys-lru：當記憶體不足以容納新寫入資料時，在鍵空間中，移除最近最少使用的key（這個是最常用的）
3）allkeys-random：當記憶體不足以容納新寫入資料時，在鍵空間中，隨機移除某個key，這個一般沒人用吧，為啥要隨機，肯定是把最近最少使用的key給幹掉啊。
4）volatile-lru：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，移除最近最少使用的key（這個一般不太合適）
5）volatile-random：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，隨機移除某個key
6）volatile-ttl：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，有更早過期時間的key優先移除
3 redis 高併發和高可用企業級實踐
-
redis高併發：主從架構，一主多從，一般來說，很多專案其實就足夠了，單主用來寫入資料，單機幾萬QPS，多從用來查詢資料，多個從例項可以提供每秒10萬的QPS。
redis高併發的同時，還需要容納大量的資料：一主多從，每個例項都容納了完整的資料，比如redis主就10G的記憶體量，其實你就最對只能容納10g的資料量。如果你的快取要容納的資料量很大，達到了幾十g，甚至幾百g，或者是幾t，那你就需要redis叢集，而且用redis叢集之後，可以提供可能每秒幾十萬的讀寫併發。
-
redis高可用：如果你做主從架構部署，其實就是加上哨兵就可以了，就可以實現，任何一個例項當機，自動會進行主備切換。
4 redis replication基本原理
-
redis採用非同步方式複製資料到slave節點，不過redis 2.8開始， slave node會週期性地確認自己每次複製的資料量
-
一個master node是可以配置多個slave node的
-
slave node也可以連線其他的slave node
-
slave node做複製的時候，是不會阻塞master node正常工作的
-
slave node在做複製的時候，也不會block對自己的查詢操作，它會用舊的資料集來提供服務; 但是複製完成的時候，需要刪除舊資料集，載入新資料集，這個時候就會暫停對外服務了
-
slave node主要用來進行橫向擴容，做讀寫分離，擴容的slave node可以提高讀的吞吐量。
5 Redis資料永續性重要性
5.1 資料丟失風險
-
如果採用了主從架構，那麼建議必須開啟master node的持久化，不建議用slave node作為master node的資料熱備，因為那樣的話，如果你關掉master的持久化，可能在master當機重啟的時候資料是空的，然後可能一經過複製，salve node資料也丟了。
master -> RDB和AOF都關閉了 -> 全部在記憶體中
master當機，重啟，是沒有本地資料可以恢復的，然後就會直接認為自己IDE資料是空的
master就會將空的資料集同步到slave上去，所有slave的資料全部清空。
100%的資料丟失，因此master節點，必須要使用持久化機制。
-
採用高可用機制也是有風險的，slave node可以自動接管master node，但是也可能sentinal還沒有檢測到master failure，master node就自動重啟了，還是可能導致上面的所有slave node資料清空故障。
5.2 主從架構和斷點續傳原理
-
當啟動一個slave node的時候，它會傳送一個PSYNC命令給master node。如果這是slave node重新連線master node，那麼master node僅僅會複製給slave部分缺少的資料; 否則如果是slave node第一次連線master node，那麼會觸發一次full resynchronization
開始full resynchronization的時候，master會啟動一個後臺執行緒，開始生成一份RDB快照檔案，同時還會將從客戶端收到的所有寫命令快取在記憶體中。RDB檔案生成完畢之後，master會將這個RDB 傳送給slave，slave會先寫入本地磁碟，然後再從本地磁碟載入到記憶體中。然後master會將記憶體中快取的寫命令傳送給slave，slave也會同步這些資料。
slave node如果跟master node有網路故障，斷開了連線，會自動重連。master如果發現有多個slave node都來重新連線，僅僅會啟動一個rdb save操作，用一份資料服務所有slave node。
-
從redis 2.8開始，就支援主從複製的斷點續傳，如果主從複製過程中，網路連線斷掉了，那麼可以接著上次複製的地方，繼續複製下去，而不是從頭開始複製一份
master node會在記憶體中常見一個backlog，master和slave都會儲存一個replica offset還有一個master id，offset就是儲存在backlog中的。如果master和slave網路連線斷掉了，slave會讓master從上次的replica offset開始繼續複製
但是如果沒有找到對應的offset，那麼就會執行一次resynchronization
-
無磁碟化複製，master在記憶體中直接建立rdb，然後傳送給slave，不會在自己本地落地磁碟了，
repl-diskless-sync repl-diskless-sync-delay，等待一定時長再開始複製，因為要等更多slave重新連線過來 複製程式碼 -
過期key處理
slave不會過期key，只會等待master過期key。如果master過期了一個key，或者通過LRU淘汰了一個key，那麼會模擬一條del命令傳送給slave。
5 Redis主從複製原理深入剖析
5.1 完整流程
- slave node啟動，僅僅儲存master node的資訊，包括master node的host和ip，但是複製流程沒開始時， master host和ip是從哪兒來的，是在redis.conf裡面的slaveof配置的。
- slave node內部有個定時任務，每秒檢查是否有新的master node要連線和複製，如果發現，就跟master node建立socket網路連線
- slave node傳送ping命令給master node
- 口令認證，如果master設定了requirepass，那麼salve node必須傳送masterauth的口令過去進行認證
- master node第一次執行全量複製，將所有資料發給slave node
- master node後續持續將寫命令，非同步複製給slave node
5.2 資料同步
-
master和slave都會維護一個offset
master會在自身不斷累加offset，slave也會在自身不斷累加offset slave每秒都會上報自己的offset給master，同時master也會儲存每個slave的offset
這個倒不是說特定就用在全量複製的，主要是master和slave都要知道各自的資料的offset，才能知道互相之間的資料不一致的情況。
-
backlog
master node有一個backlog，預設是1MB大小
master node給slave node複製資料時，也會將資料在backlog中同步寫一份
backlog主要是用來做全量複製中斷後增量複製的
-
master run id
info server，可以看到master run id，如果根據host+ip定位master node，是不靠譜的，如果master node重啟或者資料出現了變化，那麼slave node應該根據不同的run id區分，run id不同就做全量複製 如果需要不更改run id重啟redis，可以使用redis-cli debug reload命令
-
psync
從節點使用psync從master node進行復制，psync runid offset
master node會根據自身的情況返回響應資訊，也可能是FULLRESYNC runid offset觸發全量複製，可能是CONTINUE觸發增量複製。
5.3 全量複製
- master執行bgsave，在本地生成一份rdb快照檔案
- master node將rdb快照檔案傳送給salve node，如果rdb複製時間超過60秒（repl-timeout），那麼slave node就會認為複製失敗，可以適當調節大這個引數
- 對於千兆網路卡的機器，一般每秒傳輸100MB，6G檔案，很可能超過60s
- master node在生成rdb時，會將所有新的寫命令快取在記憶體中，在salve node儲存了rdb之後，再將新的寫命令複製給salve node
- client-output-buffer-limit slave 256MB 64MB 60，如果在複製期間，記憶體緩衝區持續消耗超過64MB，或者一次性超過256MB，那麼停止複製，複製失敗
- slave node接收到rdb之後，清空自己的舊資料，然後重新載入rdb到自己的記憶體中，同時基於舊的資料版本對外提供服務
- 如果slave node開啟了AOF，那麼會立即執行BGREWRITEAOF，重寫AOF
- rdb生成、rdb通過網路拷貝、slave舊資料的清理、slave of rewrite，很耗費時間，如果複製的資料量在4G~6G之間，那麼很可能全量複製時間消耗到1分半到2分鐘。
5.4 增量複製
- 如果全量複製過程中，master-slave網路連線斷掉，那麼salve重新連線master時，會觸發增量複製
- master直接從自己的backlog中獲取部分丟失的資料，傳送給slave node，預設backlog就是1MB
- msater就是根據slave傳送的psync中的offset來從backlog中獲取資料的。
5.5 heartbeat
- 主從節點互相都會傳送heartbeat資訊，master預設每隔10秒傳送一次heartbeat，salve node每隔1秒傳送一個heartbeat。
5.6 非同步複製
master每次接收到寫命令之後，先在內部寫入資料，然後非同步傳送給slave node
6 總結
在此感謝石杉的講義，結合大資料在我們工業大資料平臺的實踐，總結成一篇實踐指南，方便以後查閱反思，後續我會根據本篇部落格進行程式碼技術實踐實現。
凱新雲技術社群