作為程序員，redis是日常編碼使用最多的緩存數(shù)據(jù)庫。然而，你了解redis的架構(gòu)模式嗎？它們都有什么特點(diǎn)？今天帶著這個(gè)問題，我跟大家分享下redis架構(gòu)模式，掌握了這些知識(shí)，可以讓你應(yīng)付Redis架構(gòu)模式的面試時(shí)，游刃有余。

1.單機(jī)模式

部署簡(jiǎn)單，但是缺乏高可用，缺乏可靠性

2.主從模式

一個(gè)master節(jié)點(diǎn)，多個(gè)slave節(jié)點(diǎn)。所有節(jié)點(diǎn)都可以負(fù)責(zé)讀，但是只有master節(jié)點(diǎn)才能處理寫。

主從復(fù)制過程：

1.slave向master發(fā)送sync命令

2.master節(jié)點(diǎn)使用bgsave生成rdb文件快照，發(fā)送給slave,并記錄生成文件快照后執(zhí)行的寫命令到緩存中

3.slave接受rdb快照文件，拋棄原有數(shù)據(jù)，載入master發(fā)送的數(shù)據(jù)

4.master繼續(xù)向slave發(fā)送快照生成后的寫命令

5.slave節(jié)點(diǎn)處理master節(jié)點(diǎn)發(fā)送的寫命令

2.1一主一從

當(dāng)主節(jié)點(diǎn)的寫命令并發(fā)高，并且需要進(jìn)行持久化時(shí)。可以讓master負(fù)責(zé)負(fù)責(zé)讀寫，slave負(fù)責(zé)對(duì)master的數(shù)據(jù)進(jìn)行持久化，提高可靠性。

2.2 一主多從

針對(duì)讀操作比較頻繁的情況，可以讓master負(fù)責(zé)寫操作，將讀操作交給slave。

2.3樹狀主從

從上面的主從復(fù)制過程，我們知道m(xù)aster需要給slave節(jié)點(diǎn)發(fā)送文件快照，如果slave節(jié)點(diǎn)過多的話，就會(huì)導(dǎo)致master節(jié)點(diǎn)壓力多，所以讓master節(jié)點(diǎn)先推送到slave1,由slave1節(jié)點(diǎn)，代理去同步給slave3與slave4，減輕了slave節(jié)點(diǎn)的壓力。

Redis的主從全量復(fù)制數(shù)據(jù)只發(fā)生在master與slave建立連接的初始化階段。后續(xù)網(wǎng)絡(luò)出現(xiàn)問題，從slave節(jié)點(diǎn)再次連master時(shí)，master節(jié)點(diǎn)補(bǔ)發(fā)缺少的數(shù)據(jù)，每次數(shù)據(jù)增量同步。

缺點(diǎn)：主從復(fù)制緩解了master的讀壓力，但是沒有緩解redis的寫壓力，寫的性能局限于master所在的機(jī)器。master宕機(jī)后，需要人工手動(dòng)去修改slave上關(guān)于新master的節(jié)點(diǎn)ip

3.哨兵模式

哨兵模式（sentinel）是在主從復(fù)制的基礎(chǔ)上建立的，它有一個(gè)或者多個(gè)哨兵節(jié)點(diǎn)，哨兵節(jié)點(diǎn)不存儲(chǔ)數(shù)據(jù)。它會(huì)監(jiān)控主從節(jié)點(diǎn)，實(shí)現(xiàn)主從節(jié)點(diǎn)自動(dòng)切換，減去人工干預(yù)的緩解，但是主從切換比較耗費(fèi)時(shí)間，并且沒有解決master節(jié)點(diǎn)寫壓力的問題。

4.redis-cluster集群模式

集群key空間被分成16384個(gè)槽位，key值通過hash算法分布到不同的分片上。讀請(qǐng)求分給slave,寫請(qǐng)求分給master,數(shù)據(jù)同步從master同步到slave.可以擴(kuò)展master節(jié)點(diǎn)來分擔(dān)寫壓力，也可擴(kuò)展slave節(jié)點(diǎn)來分擔(dān)讀壓力。master節(jié)點(diǎn)宕機(jī)，slave節(jié)點(diǎn)會(huì)通過選舉產(chǎn)生新的master節(jié)點(diǎn)。

5.面試題集群的槽位為什么是16384

這個(gè)問題還真的被問到過，不知道的，可以看看下面這個(gè)回答

對(duì)于客戶端發(fā)送的key，redis會(huì)通過crc16算法進(jìn)行hash計(jì)算，映射到具體的槽位，crc16算法會(huì)產(chǎn)生16bit的hash值，2^16能產(chǎn)生65536個(gè)數(shù)值，值是分布在0~65536之間，但是作者在做取模運(yùn)算時(shí)，不是mod65536，他的公式是：HashSlot=crc16(key) mod 16384。

因?yàn)閮蓚€(gè)redis節(jié)點(diǎn)之間心跳檢測(cè)會(huì)發(fā)送ping,pong消息,消息頭里面定義了一個(gè)char數(shù)組，大小為(cluster_slot/8)。如果用65536/8/1024=8K,太大浪費(fèi)帶寬。用16384/8/1024=2K,夠用。并且集群節(jié)點(diǎn)越多，心跳檢測(cè)包越大，大于1000時(shí)，會(huì)造成網(wǎng)絡(luò)擁堵。

6.Redis持久化模式

6.1 RDB模式

RDB持久化是把當(dāng)前進(jìn)程數(shù)據(jù)生成快照（.rdb）并保存到磁盤的操作，新文件會(huì)覆蓋老文件內(nèi)容，手動(dòng)觸發(fā)可以用以下兩個(gè)命令

save命令：阻塞當(dāng)前Redis，直到RDB持久化過程完成為止，若內(nèi)存實(shí)例比較大會(huì)造成長(zhǎng)時(shí)間阻塞，線上環(huán)境不建議用它

bgsave命令：redis進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，由子線程完成持久化，不會(huì)影響主進(jìn)程執(zhí)行，阻塞時(shí)間很短（微秒級(jí)），是save的優(yōu)化,在執(zhí)行redis-cli shutdown關(guān)閉redis服務(wù)時(shí)，如果沒有開啟AOF持久化，自動(dòng)執(zhí)行bgsave;

6.2 AOF模式

RDB只能記錄某一時(shí)刻的快照，AOF像mySQL的binlog日志一樣，是記錄了所有的操作的日志文件，使用它進(jìn)行數(shù)據(jù)恢復(fù)速度會(huì)比較慢、但是AOF的啟動(dòng)優(yōu)先級(jí)要高于RDB。默認(rèn)不開啟，需要修改redis.conf文件，修改屬性appendonly為yes。

AOF有三種模式:

always:每次修改同步，性能較差，數(shù)據(jù)完整性好

everysec:每秒同步一次，每秒一次fsync,丟一秒的數(shù)據(jù)

no:從不同步

AOF日志文件的命令通過非常可讀的方式進(jìn)行記錄，這個(gè)特性非常適合做災(zāi)難性的誤刪除的緊急恢復(fù)。比如某人不小心用flushall命令清空了所有數(shù)據(jù)，只要這個(gè)時(shí)候后臺(tái)rewrite（當(dāng)AOF文件過大時(shí)，會(huì)進(jìn)行重寫，進(jìn)行壓縮文件數(shù)據(jù)）還沒有發(fā)生，那么就可以立即拷貝AOF文件，將最后一條flushall命令給刪了，然后再將該AOF文件放回去，就可以通過恢復(fù)機(jī)制，自動(dòng)恢復(fù)所有數(shù)據(jù)。