Redis 是一個開源（BSD許可）的，記憶體中的資料結構儲存系統

1、用途

資料庫、快取和訊息中介軟體MQ。

2、資料結構

1）五大常用
字串（strings）
雜湊（hashes）
列表（lists）
集合（sets）
有序集合（sorted sets）
2） 特殊結構
範圍查詢 bitmaps
基數演算法 hyperloglogs
地理空間（geospatial）
3）其他
複製（replication）
LUA指令碼（Lua scripting）
LRU驅動事件（LRU eviction），事務（transactions）
不同級別的 磁碟持久化（persistence）
Redis哨兵（Sentinel）

3持久化

3.1 RDB

1)操作

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

2)觸發機制

1、save的規則滿足的情況下，會自動觸發rdb規則
2、執行 flushall 命令，也會觸發我們的rdb規則！
3、退出redis，也會產生 rdb 檔案！
備份就自動生成一個 dump.rdb

3）優點：

1、適合大規模的資料恢復！
2、對資料的完整性要不高！

4）缺點：

1、需要一定的時間間隔程序操作！如果redis意外宕機了，這個最後一次修改資料就沒有的了！
2、fork程序的時候，會佔用一定的內容空間！！

3.2AOF（Append Only File）

將我們的所有命令都記錄下來，history，恢復的時候就把這個檔案全部在執行一遍！

1)操作

以日誌的形式來記錄每個寫操作，將Redis執行過的所有指令記錄下來（讀操作不記錄），只許追加檔案

2)觸發機制

appendonly no   # 預設是不開啟aof模式的，預設是使用rdb方式持久化的，在大部分所有的情況下，rdb完全夠用！
appendfilename "appendonly.aof"  # 持久化的檔案的名字
# appendfsync always  # 每次修改都會 sync。消耗效能
appendfsync everysec  # 每秒執行一次 sync，可能會丟失這1s的資料！
# appendfsync no    # 不執行 sync，這個時候作業系統自己同步資料，速度最快！在這裡插入程式碼片

3）優點：

1、每一次修改都同步，檔案的完整會更加好！
2、每秒同步一次，可能會丟失一秒的資料
3、從不同步，效率最高的！

4）缺點：

1、相對於資料檔案來說，aof遠遠大於 rdb，修復的速度也比 rdb慢！
2、Aof 執行效率也要比 rdb 慢，所以我們redis預設的配置就是rdb持久化！

3.3 擴充套件：

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

4Redis釋出訂閱

Redis 釋出訂閱(pub/sub)是一種訊息通訊模式：傳送者(pub)傳送訊息，訂閱者(sub)接收訊息。微信、微博、關注系統！

5主從複製

5.1概念

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

5.2 作用主要包括：

1、資料冗餘：主從複製實現了資料的熱備份，是持久化之外的一種資料冗餘方式。
2、故障恢復：當主節點出現問題時，可以由從節點提供服務，實現快速的故障恢復；實際上是一種服務的冗餘。
3、負載均衡：在主從複製的基礎上，配合讀寫分離，可以由主節點提供寫服務，由從節點提供讀服務（即寫Redis資料時應用連線主節點，讀Redis資料時應用連線從節點），分擔伺服器負載；尤其是在寫少讀多的場景下，通過多個從節點分擔讀負載，可以大大提高Redis伺服器的併發量。
4、高可用（叢集）基石：除了上述作用以外，主從複製還是哨兵和叢集能夠實施的基礎，因此說主從複製是Redis高可用的基礎。

5.3複製原理

Slave 啟動成功連線到 master 後會傳送一個sync同步命令
Master 接到命令，啟動後臺的存檔程序，同時收集所有接收到的用於修改資料集命令，在後臺程序執行完畢之後，master將傳送整個資料檔案到slave，並完成一次完全同步。
全量複製：而slave服務在接收到資料庫檔案資料後，將其存檔並載入到記憶體中。
增量複製：Master 繼續將新的所有收集到的修改命令依次傳給slave，完成同步
但是隻要是重新連線master，一次完全同步（全量複製）將被自動執行！ 我們的資料一定可以在從機中看到！

5.4 哨兵模式

1）原因

主從切換技術的方法是：當主伺服器宕機後，需要手動把一臺從伺服器切換為主伺服器，這就需要人工干預，費事費力，還會造成一段時間內服務不可用。這不是一種推薦的方式，更多時候，我們優先考慮哨兵模式。Redis從2.8開始正式提供了Sentinel（哨兵） 架構來解決這個問題

2）實現

哨兵通過傳送命令，等待Redis伺服器響應，從而監控執行的多個Redis例項

3）作用

正常–通過傳送命令，讓Redis伺服器返回監控其執行狀態，包括主伺服器和從伺服器。
宕機–當哨兵監測到master宕機，會自動將slave切換成master，然後通過釋出訂閱模式通知其他的從伺服器，修改配置檔案，讓它們切換主機。

4）多哨兵模式

6快取穿透和雪崩

1快取穿透（查不到）

概念

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

解決方案

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

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

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

2快取擊穿（量太大，快取過期！）

1概述

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

2解決方案

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

3快取雪崩

1概念

快取雪崩，是指在某一個時間段，快取集中過期失效。Redis 宕機！

2解決方案

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

7、過期淘汰策略

最少使用（lru）
最近要過期
設定ttl的隨機
全資料隨機

8、redis佇列

1）正常佇列
lpush rpop sleep
2) 延時佇列
sortedset模式，zadd加入訊息內容，時間戳作為score(延遲時間)。
到達時間後自動消費