文章目錄
- 0. redis與mysql區別
- 1. redis是單線程架構還是多線程架構
- 2. redis單線程為什么這么快
- 3. redis過期key刪除策略
- 4. redis主從復制架構原理
- 5. redis哨兵模式架構原理
- 6. redis高可用集群架構原理
- 7. redis持久化之RDB
- 8. redis持久化之AOF
- 9. redis持久化之混合持久化
0. redis與mysql區別
1.數據庫類型MySQL是關系型數據庫Redis是緩存數據庫（非關系型數據庫）
2.數據存放位置MySQL：數據存放在磁盤中Redis：數據存放在內存中
3.支持數據類型MySQL：數值、日期/時間、字符串Redis：String、Hash、List、Set、Zset
1. redis是單線程架構還是多線程架構
redis6.0版本之前是單線程，這里的單線程指的是網絡IO和鍵值對讀寫命令是由一個線程完成的
redis6.0版本之前之后是多線程，這里的多線程指的是在網絡IO請求過程中采用了多線程，但是鍵值對讀寫命令仍然是單線程的，并且持久化、集群數據同步、異步刪除都是由額外的線程完成的。所以redis仍然是線程安全的
2. redis單線程為什么這么快
命令執行基于內存操作，單條命令操作時間是幾十納秒
命令執行是單線程操作，避免了多線程上下文切換開銷
高效的數據結構，包括全局Hash表、簡單動態字符串、雙向鏈表、跳躍表、整數數組
基于IO多路復用技術，能夠保證大量并發下的效率，提高系統的吞吐量
3. redis過期key刪除策略
1.惰性刪除: key達到過期時間，不會被立即刪除，只有當讀寫到這個已經過期的key時，才會觸發惰性刪除策略刪除該key2.定時刪除: 由于惰性刪除策略無法保證冷數據被及時刪掉，所以Redis會定期(默認每100ms)主動淘汰一批已過期的key,這里的一批只是部分過期key,所以可能會出現部分key已經過期但仍然還沒有被清理掉的情況3.主動刪除: 當redis已用內存超過maxmemory限定時，觸發主動清理策略，共8種內存淘汰策略
a)針對設置了過期時間的key1. volatile-ttl: 在設置了過期時間的鍵值對，根據過期時間的先后進行刪除，越早過期的越先被刪除。2. volatile-random: 在設置了過期時間的鍵值對，進行隨機刪除。3. volatile-lru: 會使用LRU算法篩選設置了過期時間的鍵值對刪除。4. volatile-lfu: 會使用LFU算法篩選設置了過期時間的鍵值對刪除。b)針對所有的key5. allkeys-random: 從所有鍵值對中隨機選擇并刪除數據。6. allkeys-lru: 使用LRU算法在所有數據中進行篩選刪除。7. allkys-lfu: 使用LFU算法在所有數據中進行篩選刪除。c)不處理8. noeviction:不會剔除任何數據，拒絕所有寫入操作并返回客戶端錯誤信息，此時Redis只響應讀操作。LRU算法(Least Recently Used,最近最久未使用): 淘汰很久沒被訪問過的數據，以最近-次訪問時間作為參考
LFU算法(Least Frequently Used,最不經常使用): 淘汰最近一段時間被訪問次數最少的數據，以次數作為參考
絕大多數情況我們都可以用LRU策略，當存在大量的熱點緩存數據時，LFU可能更好點
4. redis主從復制架構原理
常見的主從復制架構：總體來說，主數據庫Master以寫為主，從數據庫Slave以讀為主，整體負責讀寫分離、容災恢復。
case1：一主二仆【中心化架構】 slaveof 新主庫IP 新主庫端口
case2：薪火相傳【去中心化架構】 slaveof 新主庫IP 新主庫端口
case3：反客為主 slaveof no one
// 主從數據庫數據同步過程
1.全量復制：【當主從服務器剛建立連接的時候，進行全量數據同步】a、首先從服務器連接到主服務器，發送psync命令進行數據全量同步（Redis2.8之前是sync命令）b、主服務器收到psync命令之后，執行bgsave命令生成RDB快照文件發送給從服務器c、從服務器收到RDB快照文件后，清空內存舊數據，將接收到的數據寫入磁盤2、增量復制：【全量復制結束后，進行增量復制】a、主服務器每執行一個寫命令就會向從服務器發送相同的寫命令b、從服務器接收并執行收到的寫命令。優點：（1）數據熱備份：主從復制實現了數據的熱備份，是持久化之外的一種數據冗余方式。（2）故障恢復： 如果master宕掉了，哨兵模式可以提升一個新的master，實現故障轉移，達到高可用。（3）負載均衡： 可以輕易實現橫向擴展，實現讀寫分離，一個master用于寫，多個slave 用于分攤讀的壓力缺點：（1）網絡延遲：由于所有的寫操作都是先在Master上操作，然后同步更新到Slave上，所以從Master同步到Slave服務器有一定的延遲（2）如果master宕掉了，普通主從模式無法自動切換master，必須使用哨兵模式
5. redis哨兵模式架構原理
優點：可以動態切換主從庫，中心型公司首選
缺點：
- 單個master主節點提供寫服務，redis存儲的數據有限(<10G)，并發量不足(<3w)
- 自動切換主從庫會產生訪問瞬斷的情況，切換沒有那么快
工作原理：
哨兵是一個分布式系統，可以在一個架構中運行多個哨兵進程，這些進程使用流言協議(gossip protocols)來傳播Master是否下線的信息，并使用投票協議(agreement protocols)來決定是否執行自動故障遷移以及選擇哪個Slave作為新的Master。哨兵模式的簡單工作原理如下：
（1）監控：哨兵會不斷地檢查你的Master和Slave是否運作正常。
（2）提醒：當被監控的某個Redis節點出現問題時，哨兵可以通過 API 向管理員或者其他應用程序發送通知。
（3）自動故障遷移：當Master不能正常工作時，哨兵會進行自動故障遷移操作，將其中一個Slave升級為新的Master
6. redis高可用集群架構原理
redis集群是一個由多個主從節點群組成的分布式服務器群，它具有復制、高可用和分片存儲特性
redis集群將每個節點設置成集群模式，這種集群模式沒有中心節點，可水平擴展，可線性擴展到上萬個節點(官方推薦不超過1000個節點)
redis集群的性能和高可用性均優于之前版本的哨兵模式，且集群配置非常簡單。
大型公司首選
7. redis持久化之RDB
RDB（Redis DataBase）在指定的時間間隔內將內存中的數據集快照寫入磁盤，也就是行話講的Snapshot快照，它恢復時將快照文件 (dump.rdb) 移動到redis安裝目錄并啟動服務即可。
save 3600 1 # 15分鐘變動1次
save 300 100 # 5分鐘變動100次
save 60 10000 # 1分鐘變動1w次save save時只管保存，其它不管，全部阻塞。
bgsave Redis會在后臺異步進行快照操作， 快照同時還可以響應客戶端請求。
RDB優點：1、持久化速度快：RDB在保存RDB文件時父進程唯一需要做的就是fork出一個子進程，接下來的工作全部由子進程來做，父進程不需要再做其他I0操作，所以RDB持久化方式可以最大化redis的性能。[適合大規模的數據持久化]2、恢復速度快：與AOF相比，RDB是一個非常緊湊的文件，RDB數據恢復會更快一些RDB缺點：1、內存膨脹：Fork的作用是復制一個與當前進程一樣的進程，新進程的所有數據（變量、環境變量、程序計數器等）數值都和原進程一致，大致2倍的膨脹性需要考慮。2、數據丟失：在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最后一次快照后的所有修改
8. redis持久化之AOF
AOF（Append Only File）是以日志的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構建數據，換言之，redis 重啟的話就根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作。
AOF配置【APPEND ONLY MODE】
appendonly no # 默認no
appendfilename "appendonly.aof" # 文件名
appendfsync [always/everysec/no]always 同步持久化，redis每次發生數據改變都會被立即記錄到磁盤，性能較差但數據完整性最好everysec 默認推薦，異步操作，每秒記錄一次，最多損失1s的數據no 不進行持久化
no-appendfsync-on-rewrite no # 重寫時是否運用appendfsync，默認no即可，保證數據安全性
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
AOF優點：每修改同步：appendfsync always 同步持久化 每次發生數據變更會被立即記錄到磁盤，性能較差但數據完整性比較好每秒同步：appendfsync everysec 異步操作，每秒記錄 如果一秒內宕機，有數據丟失不同步：appendfsync no 從不同步AOF缺點：1、文件大、恢復慢：相同數據集的數據而言aof文件要遠大于rdb文件，恢復速度慢于rdb2、Aof運行效率要慢于rdb,每秒同步策略效率較好，不同步效率和rdb相同
redis默認使用AOF恢復數據，因為aof保存的數據更全面
9. redis持久化之混合持久化
背景：
- 重啟Redis時，我們很少只使用RDB來恢復內存數據，因為這會丟失大量數據
- 通常使用AOF日志重放來恢復數據，但是重放AOF日志性能相對RDB來說要慢很多,當Redis數據很大，啟動需要花費很長的時間
Redis 4.0為了解決這個問題，帶來了一個新的持久化選項一混合持久化
實現步驟：
步驟一：通過如下配置可以開啟混合持久化(必須先開啟aof):aof-use-rdb-preamble yes步驟二：此時AOF在重寫時，不再是單純將內存數據轉換為RESP命令寫入AOF文件，而是將重寫這一刻之前的內存做RDB
快照處理，并且將RDB快照內容和增量的AOF修改內存數據的命令存在一起，都寫入新的AOF文件步驟三：新的文件一開始不叫appendonly.aof,等到重寫完新的AOF文件才會進行改名,覆蓋原有的AOF文件,完成新舊兩個AOF文件的替換。步驟四：redis重啟的時候，可以先加載RDB的內容,然后再重放增量AOF日志就可以完全替代之前的AOF全量文件重放,因此重啟效率大幅得到提升。
