1.Redis概覽

Redis和memcache的區(qū)別，Redis支持的數(shù)據(jù)類型應(yīng)用場景

redis支持的數(shù)據(jù)結(jié)構(gòu)更豐富（string,hash,list,set,zset）omemcache只支

持key-value的存儲；

redis原生支持集群，mcmcachc沒有原生的集群模式。

2.Redis單線程模型

redis單線程處理請求流程

redis采用IO多路復(fù)用機(jī)制來處理請求，采用reactorlO模型，處理流程如下:

首先接收到客戶端的sockel請求，多路復(fù)用器將socket轉(zhuǎn)給連接應(yīng)答處理

器；

連接應(yīng)答處理器將AE_READABLE事件與命令請求處理器關(guān)聯(lián)（這里是把

socket事件放入一個隊列）；

命令請求處理器從socket中讀到指令,再內(nèi)存中執(zhí)行，并將AE_WRITEABLE

事件與命令回復(fù)處理器關(guān)聯(lián)；

命令回復(fù)處理器將結(jié)果返回給socket,并解除關(guān)聯(lián)。

redis單線程效率高的原因

非阻塞10復(fù)用（上圖流程），I/O多路復(fù)用分派事件，事件處理器處理事件（這

個可以理解為注冊的一段函數(shù)，定義了事件發(fā)生的時候應(yīng)該執(zhí)行的動作），這里

分派事件和處理事件其實(shí)都是同一個線程；

純內(nèi)存操作效率高；

單線程反而避免了多線程切換。

3.Redis過期策略

對key設(shè)置有效期，redis的刪除策略:定期刪除+惰性刪除。

定期刪除指的是redis默認(rèn)每100ms就隨機(jī)抽取一些設(shè)置了過期事件的key,

檢查是否過期，如果過期就刪除。如果redis設(shè)置了10萬個key都設(shè)置了過期時

間，每隔幾百毫秒就要檢查10萬個key那CPU負(fù)載就很高了，所以redis并不

會每隔100ms就檢查所有的key,而是隨機(jī)抽取一些key來檢查。

但這樣會導(dǎo)致有些key過期「并沒有被刪除，所以采取「惰性刪除。意思是

在獲取某個key的時候發(fā)現(xiàn)過期了，如果key過期了就刪除掉不會返回。

這兩個策略結(jié)合起來保證過期的key一定會被刪除。

最大內(nèi)存淘汰（maxmemory-policy）

如果redis內(nèi)存占用太多，就會進(jìn)行內(nèi)存淘汰。有如下策略：

noeviction:如果內(nèi)存不足以寫入數(shù)據(jù)，新寫入操作直接報錯；

allkeys-lru:內(nèi)存不足以寫入數(shù)據(jù)，移除最近最少使用的key（最常用的策略）；

allkeys-random:內(nèi)存不足隨機(jī)移除幾個key；

volalile-lru:在設(shè)置了過期時間的key中，移除最近最少使用；

volatile-random:設(shè)置了過期的時間的key中，隨機(jī)移除幾個。

4.Redis主從模式保證高并發(fā)和高可用（哨兵模式）

讀寫分離

單機(jī)的Redis的QPS大概就在上萬到幾萬不等，無法承受更高的并發(fā)。

讀寫分離保證高并發(fā)（10W+QPS）：對于緩存來說一般都是支撐高并發(fā)讀，寫

請求都是比較少的。采用讀寫分離的架構(gòu)（一主多從），master負(fù)責(zé)接收寫請求，

數(shù)據(jù)同步到slave上提供讀服務(wù)，如果遇到瓶頸只需要增加slave機(jī)器就可以水

平擴(kuò)容。

主從復(fù)制機(jī)制

redisreplication機(jī)制：

redis菜取異步復(fù)制到slave節(jié)點(diǎn)；

slave節(jié)點(diǎn)做復(fù)制操作的時候是不會block自己的，它會使用舊的數(shù)據(jù)集來提

供服務(wù)，復(fù)制。完成后，刪除舊的數(shù)據(jù)集，加載新的數(shù)據(jù)集，這個時候會暫停服

務(wù)（時間很短暫）;

如果采用了主從架構(gòu)，master需要開啟持久億。如果master沒有開啟持久化

（rdb和aof都關(guān)閉了）。master宕機(jī)重啟后數(shù)據(jù)是空的，然后經(jīng)過復(fù)制就把所有

slave的數(shù)據(jù)也弄丟了。

即使采用高可用的的哨兵機(jī)制,可能sentinal還沒有檢測到masterfailurc,

master就自動重啟了，還是會導(dǎo)致slave清空故障。

主從同步流程

當(dāng)slave啟動時會發(fā)送一個psync命令給master；

如果是重新連接master,則masternode會復(fù)制給slave缺少的那部分?jǐn)?shù)據(jù)；

如果是slave第一次連接master,則會觸發(fā)一次全量復(fù)制

（fullresynchronization）o開始fullresynchronization的時候，master會生成一份rdb

快照，同時將客戶端命令緩存在內(nèi)存，rdb生成完后，就發(fā)送給slave,slave先

寫入磁盤在加載到內(nèi)存。然后master將緩存的命令發(fā)送給slave。

aWT

0*協(xié)

哨兵（sentinal）模式介紹

哨兵是redis集群架構(gòu)的一個重要組件，主要提供如下功能:

集群監(jiān)控：負(fù)責(zé)監(jiān)控master和slave是否正常工作；

消息通知：如果某個redis實(shí)例有故障，哨兵負(fù)責(zé)發(fā)消息通知管理員；

故障轉(zhuǎn)移:如果masternode發(fā)生故障，會自動切換到slave：

配置中心：如果故障轉(zhuǎn)移發(fā)生了，通知客戶端新的master地址。

哨兵的核心知識：

哨兵至少三個，保證自己的高可用；

哨兵+主從的部署架構(gòu)是用來保證redis集群高可用的，并非保證數(shù)據(jù)不丟

失；

哨兵(Senlinel)需要通過不斷的測試和觀察才能保證高可用。

為什么哨兵只有兩個節(jié)點(diǎn)無法正常工作

假設(shè)哨兵集群只部署了2個哨兵實(shí)例，quorum=lo

master宕機(jī)的時候，si和s2只要有一個哨兵認(rèn)為master宕機(jī)j就可以進(jìn)行

切換，并且會從si和s2中選取一個來進(jìn)行故障轉(zhuǎn)移。這個時候是需要滿足

majority,也就是人多數(shù)哨兵是運(yùn)行的，2個哨兵的majoriiy是2,如果2個哨兵

都運(yùn)行著就允許執(zhí)行故障轉(zhuǎn)移。如果Ml所在的機(jī)器宕機(jī)了，那么si哨兵也就

掛了，只剩s2一個，沒有majority］來允許執(zhí)行故障轉(zhuǎn)移，雖然集群還有一臺機(jī)

器R1,但是故障轉(zhuǎn)移也不會執(zhí)行。

如果是經(jīng)典的三哨兵集群，如下：

+------+

此時majority也是2,就算Ml所在的機(jī)器宕機(jī)了，哨兵還是剩下兩個$2和

S3,它們滿足majority就可以允許故障轉(zhuǎn)移執(zhí)行。

哨兵核心底層原理

sdown和odown兩種失敗狀態(tài)；

sdown是主觀宕機(jī)，就是一個哨兵覺得master宕機(jī)了，達(dá)成條件是如果一個

哨兵pingmaster超過了is-master-down-after-milliseconds指定的毫秒數(shù)后就認(rèn)為

主觀宕機(jī)；

odown是客觀宕機(jī)，如果一個哨兵在指定時間內(nèi)收到了majority（大多數(shù)）數(shù)

量的哨兵也認(rèn)為那個master宕機(jī)了，就是客觀宕機(jī)。

哨兵之間的互相發(fā)現(xiàn)：哨兵是通過redis的pub/sub實(shí)現(xiàn)的。

5.Rcdis數(shù)據(jù)的恢復(fù)（Redis的持久化）

RDB

RDB原理

RDB（RedisDataBase）是將某一個時刻的內(nèi)存快照（Snapshot）,以二進(jìn)制

的方式寫入磁盤的過程。

RDB有兩種方式save和bgsave:

save:執(zhí)行就會觸發(fā)Redis的持久化，但同時也是使Redis處于阻塞狀態(tài)，直

到RDB持久化完成，才會響應(yīng)其他客戶端發(fā)來的命令；

bgsave:bgsave會fork。一個子進(jìn)程來執(zhí)行持久化，整個過程中只有在fork（）

子進(jìn)程時有短暫的阻塞，當(dāng)子進(jìn)程被創(chuàng)建之后，Redis的主進(jìn)程就可以響應(yīng)其他

客戶端的請求

RDB配置

除了使用save和bgsave命令觸發(fā)之外，RDB支持自動觸發(fā)。

自動觸發(fā)策略可配置Redis在指定的時間內(nèi)，數(shù)據(jù)發(fā)生了多少次變化時，會

自動執(zhí)行bgsave命令。在redis配置文件中配置：

在時間m秒內(nèi)，如果Redis數(shù)據(jù)至少發(fā)生了n次變化，那么就自動執(zhí)行

BGSAVE命令。

savemn

RDB優(yōu)缺點(diǎn)

RDB的優(yōu)點(diǎn)

RDB會定時生成多個數(shù)據(jù)文件，每個數(shù)據(jù)文件都代表了某個時刻的redis全

量數(shù)據(jù)，適合做冷備，可以將這個文件上傳到一個遠(yuǎn)程的安全存儲中，以預(yù)定好

的策略來定期備份redis中的數(shù)據(jù)；

RDB對rcdis對外提供讀寫服務(wù)的影響非常小，redis是通過fork主進(jìn)程的

一個子進(jìn)程操作磁盤10來進(jìn)行持久化的；

相對于A0F,直接基于RDB來恢復(fù)reids數(shù)據(jù)更快。

RDB的缺點(diǎn)：

如果使用RDB來恢復(fù)數(shù)據(jù)，會丟失一部分?jǐn)?shù)據(jù)，因為RDB是定時生成的

快照文件；

‘RDB,每次來fork出子進(jìn)程的時候，如果數(shù)據(jù)文件特別大，可能會影響對外

提供服務(wù)，暫停數(shù)秒（主進(jìn)程需要拷貝自己的內(nèi)存表給子進(jìn)程，實(shí)例很大的時候

這個拷貝過程會很長）。latest_fork_usec代表fork導(dǎo)致的延時；Redis上執(zhí)行NFO

命令查看latest_fork_usec；當(dāng)RDB比較大的時候，應(yīng)該在slave節(jié)點(diǎn)執(zhí)行備份，

并在低峰期執(zhí)行。

A0F

AOF原理

redis對每條寫入俗令進(jìn)行日志記錄，以append-only的方式寫入一個日志文

件，rcdis重啟的時候通過重放日志文件來恢復(fù)數(shù)據(jù)集。（由于運(yùn)行久了A0F文件

會越來越大，redis提供一種rewrite機(jī)制，基于當(dāng)前內(nèi)存中的數(shù)據(jù)集，來構(gòu)建一

個更小的A0F文件，將舊的龐大的A0F文件刪除）。rewrite即把日志文件壓縮,

通過bgrewriteaof觸發(fā)重寫。AOFrewrite后臺執(zhí)行的方式和RDB有類似的地方，

fork一個子進(jìn)程，主進(jìn)程仍進(jìn)行服務(wù)，子進(jìn)程執(zhí)行A0F持久化，數(shù)據(jù)被dump

到磁盤上。與RDB不同的是，后臺子進(jìn)程持久化過程中，主進(jìn)程會記錄期訶的

所有數(shù)據(jù)變更（主進(jìn)程還在服務(wù)），并存儲在server.aof_rewrite_buf_blocks中；

后臺子進(jìn)程結(jié)束后，Redis更新緩存追加到AOF文件中，是RDB百久化所不具

備的。

A0F的工作流程如下：

Redis執(zhí)行寫命令后，把這個命令寫入到AOF文件內(nèi)存中（write系統(tǒng)調(diào)用）;

Redis根據(jù)配置的A0F刷盤策略，把A0F內(nèi)存數(shù)據(jù)刷到磁盤上（fsync系統(tǒng)

調(diào)用）；

根據(jù)rewrite相關(guān)的配置觸發(fā)rewrite流程。

AOF配置

appendonly:是否啟用AOF（yes|no）；

appcndfsync:刷盤的機(jī)制：

always：主線程每次執(zhí)行寫操作后立即刷盤，此方案會占用比較大的磁盤IO

資源，但數(shù)據(jù)安全性最高；

everysec：主線程每次寫操作只寫內(nèi)存就返回，然后由后臺線程每隔1秒執(zhí)

行一次刷盤操作（觸發(fā)fsync系統(tǒng)調(diào)用），此方案對性能影響相對較小，但當(dāng)Redis

宕機(jī)時會丟失1秒的數(shù)據(jù)；

no：主線程每次寫操作只寫內(nèi)存就返回，內(nèi)存數(shù)據(jù)什么時候刷到磁盤，交由

操作系統(tǒng)決定，此方案對性能影響最小，但數(shù)據(jù)安全性也最低，Rcdis宕機(jī)時丟

失的數(shù)據(jù)取決于操作系統(tǒng)刷盤時機(jī)。

auto-aof-rewrite-percenlage:當(dāng)aof文件相較于上一版本的aof文件大小的百分

比達(dá)到多少時觸發(fā)AOF重寫。舉個例子，auto-aof-rewrite-percentage選項配置為

100,上一版本的aof文件大小為I00M,那么當(dāng)我們的aof文件達(dá)到200M的時

候，觸發(fā)AOF重寫；

auto-aof-rewite-min-size：最小能容忍aof文件大小，超過這個大小必須進(jìn)行

AOF重寫；

no-appendfsync-on-rewrite:設(shè)置為yes表示rewrite期間對新寫操作不fsync,

暫時存在內(nèi)存中，等rewrite完成后再寫入，默認(rèn)為no。

AOF優(yōu)缺點(diǎn)

AOF的優(yōu)點(diǎn)：

可以更好的保證數(shù)據(jù)不丟失，一般AOF每隔1s通過一個后臺線程來執(zhí)行

fsync（強(qiáng)制刷新磁盤頁緩存），最多丟失1s的數(shù)據(jù)；

AOF以appcnd-only的方式寫入（順序追加），沒有磁盤尋址開銷，性能很高;

AOF即使文件很天，觸發(fā)后臺rewrite的操作的時候一般也不會影響客戶端

的讀寫，（rewrite的時候會對其中指令進(jìn)行壓縮，創(chuàng)建出一份恢復(fù)需要的最小日

志出來）

"在創(chuàng)建新的日志文件的時候，老的文件還是照常寫入，當(dāng)新的文件創(chuàng)建完成

后再交換新老日志。但是還是有可能會影響到主線程的寫入，如：

當(dāng)磁盤的IO負(fù)載很高，那這個后臺線程在執(zhí)行AOFfsync刷盤操作（fsync

系統(tǒng)調(diào)用）時就會被阻塞住，，緊接著，主線程又需要把數(shù)據(jù)寫到文件內(nèi)存中（write

系統(tǒng)調(diào)用），但此時的后臺子線程由于磁盤負(fù)載過高，導(dǎo)致fsync發(fā)生阻塞，遲

遲不能返回，那主線桂在執(zhí)行write系統(tǒng)調(diào)用時，也會被阻塞住，直到后臺線程

fsync執(zhí)行完成后，主線程執(zhí)行wrile才能成功返回。這時候主線程就無法響應(yīng)客

戶端的請求，可能會導(dǎo)致客戶端請求redis超時。

AOF日志文件通過非常可讀的方式進(jìn)行記錄，這個特性適合做災(zāi)難性的誤

操作的緊急恢復(fù)，比如不小心使用flushall清空了所有數(shù)據(jù)，只要rewrite沒有發(fā)

生，就可以立即拷貝AOF,將最后一條flushall命令刪除，再回放AOF恢復(fù)數(shù)

據(jù)。

AOF的缺點(diǎn)：

同一份數(shù)據(jù)?，因為AOF記錄的命令會比RDB快照文件更大;

AOF開啟后，支持寫的QPS會比RDB支持寫的QPS要低，畢竟AOF有寫

磁盤的操作。

總結(jié)

總結(jié)AOF和RDB該如何選擇：兩者綜合使用，將AOF配置成每秒fsync

一次。RDB作為冷備，AOF用來保證數(shù)據(jù)不丟失的恢復(fù)第一選擇，當(dāng)AOF文件

損壞或不可用的時候還可以使用RDB來快速恢復(fù)。

6.Redis集群模式（rediscluster）

在主從部署模式上，雖然實(shí)現(xiàn)了一定程度的高并發(fā)，并保證了高可用，但是

有如下限制：

master數(shù)據(jù)和slave數(shù)據(jù)一模樣，master的數(shù)據(jù)量就是集群的限制瓶頸；

redis集群的寫能力也受到了master節(jié)點(diǎn)的單機(jī)限制。

在高版本的Rcdis已經(jīng)原生支持集群（cluster）模式，可以多master多slave部

署,橫向擴(kuò)展Redis集群的能力。RedisCIuster支持N個masternode,每個

masternode可以掛載多個slavenode。

rediscluster介紹

自動將數(shù)據(jù)切片，每個master上放一部分?jǐn)?shù)據(jù)；

提供內(nèi)置的高可用支持，部分master不可用時還是能夠工作；

rediscluster模式下，每個redis要開放兩個端口：6379和10000+以后的端口

（如16379）o16379是用來節(jié)點(diǎn)之間通信的，使用的是clustcrbus集群總線。

clusterbus用來做故障檢測，配置更新，故障轉(zhuǎn)移授權(quán)。

rediscluster負(fù)載均衡

rediscluster采用一致性hash+虛擬節(jié)點(diǎn)來負(fù)載均衡。rediscluster有固定的

16384個slol（2八14）,對每個key做CRC16值計算，然后對16384mod?？梢垣@取

每個key的slotorediscluster每個master都會持有部分slot,比如三個master那

么每個master就會持有5000多個slotohashsloti±node的添加和刪除變得很簡

單，增加一個master,就將其他master的slot移動部分過去，減少一個就分給其

他master,這樣讓集群擴(kuò)容的成本變得很低。

cluster基礎(chǔ)通信原理（gossip協(xié)議）

與集中式不同（如使用zooke叩er進(jìn)行分布式協(xié)調(diào)注冊），rediscluster使用的

是gossip協(xié)議進(jìn)行通信。并不是將集群元數(shù)據(jù)存儲在某個節(jié)點(diǎn)上，而是不斷的互

相通信，保持整個集群的元數(shù)據(jù)是完整的。gossip協(xié)議所有節(jié)點(diǎn)都持有一份元數(shù)

據(jù)，不同節(jié)點(diǎn)的元數(shù)據(jù)發(fā)生了變更，就不斷的將元數(shù)據(jù)發(fā)送給其他節(jié)點(diǎn)，讓其他

節(jié)點(diǎn)也進(jìn)行元數(shù)據(jù)的變更。

集中式的好處：元數(shù)據(jù)的讀取和更新時效性很好，一旦元數(shù)據(jù)變化就更新到

集中式存儲，缺點(diǎn)就是元數(shù)據(jù)都在一個地方，可能導(dǎo)致元數(shù)據(jù)的存儲壓力。

對于gossip來說：元數(shù)據(jù)的更新會有延時，會降低元數(shù)據(jù)的壓力，缺點(diǎn)是操

作是元數(shù)據(jù)更新可能會導(dǎo)致集群的操作有一些滯后。

rediscluster主備切換與高可用

判斷節(jié)點(diǎn)宕機(jī)：如果有一個節(jié)點(diǎn)認(rèn)為另外一個節(jié)點(diǎn)宕機(jī)，那就是pfaiL主觀

宕機(jī)。如果多個節(jié)點(diǎn)認(rèn)為一個節(jié)點(diǎn)宕機(jī)，那就是fail,客觀宕機(jī)。跟哨兵的原理

一樣；

對宕機(jī)的master,從其所有的slave中選取一個切換成masternode,再次之

前會進(jìn)行一次過濾，檢查每個slave與master的斷開時間，如果超過了

cluster-node-timeout*clusler-slave-validity-factor就沒有資格切換成master；

從節(jié)點(diǎn)選?。好總€從節(jié)點(diǎn)都會根據(jù)從master復(fù)制數(shù)據(jù)的offset,來設(shè)置一個

選舉時間，offset越大的從節(jié)點(diǎn)，選舉時間越靠前，maslemode開始給slave選舉

投票，如果大部分mast?r（n/2+l）都投給了某個slave,那么選舉通過（與zk有點(diǎn)像，

選舉時間類似于epochid）；

整個流程與哨兵類似，可以說redisclustcr集成了哨兵的功能，更加的強(qiáng)大；

Redis集群部署相關(guān)問題redis機(jī)器的配置，多少臺機(jī)器，能達(dá)到多少qps?

機(jī)器標(biāo)準(zhǔn):8核+32G

集群:5主+5從（每個master都掛一個slave）

效果:每臺機(jī)器最高峰每秒大概5W,5臺機(jī)器最多就是25W,每個master

都有一個從節(jié)點(diǎn)，任何一個節(jié)點(diǎn)掛了都有備份可切換成主節(jié)點(diǎn)進(jìn)行故障轉(zhuǎn)移

腦裂問題哨兵模式下：

master卜'掛載了3個slave,如果master由于網(wǎng)絡(luò)抖動被哨兵認(rèn)為宕機(jī)了，

執(zhí)行了故障轉(zhuǎn)移，從slave里面選取了一個作為新的master,這個時候老的master

又恢復(fù)了，剛好又有clienl連的還是老的masler,就會產(chǎn)生腦裂，數(shù)據(jù)也會不一

致，比如incr全局id也會重復(fù)。

redis對此的解決方案是：min-slaves-to-write1至少有一個slave連接

min-slaves-max-lag1Oslave與master主從復(fù)制延遲時間如果連接到master的slave

數(shù)小于最少slave的數(shù)量，并且主從復(fù)制延遲時間超過配置時間，master就拒絕

寫入12oclient連接redis多tep連接的考量首先redisserver雖然是單線程來處理

請求，但是他是多路復(fù)用的，單tep連接肯定是沒有多tep連接性能好，多路復(fù)

用一個i。周期得到的就緒i。事件越多，處理的就越多。這也不是絕對的，如果

使用pipeline的方式傳輸，單連接會比多連接性能好，因為每一個pipeline的單

次請求過多也會導(dǎo)致單周期到的命令太多，性能下降多少個連接比較合適這個問

題，rediscluser控制在每個節(jié)點(diǎn)100個連接以內(nèi)。

本文包括：30個Redis基礎(chǔ)知識；10個Redis架構(gòu)和運(yùn)維必懂的知識；Redis

調(diào)優(yōu)、監(jiān)控知識和10個具體應(yīng)用難點(diǎn)。

30個Redis基礎(chǔ)知識

1、Redis支持哪幾種數(shù)據(jù)類型？

StringList>Set、SortedSet、hashes

2、Redis主要消耗什么物理資源？

Redis是一種基于內(nèi)存高性能的數(shù)據(jù)庫一主要依賴于內(nèi)存

3、Redis哪幾種數(shù)據(jù)淘汰策略？

nocviction：返回錯誤當(dāng)內(nèi)存限制達(dá)到并且客戶端嘗試執(zhí)行會讓更多內(nèi)存被

使用的命令（大部分的寫入指令，但DEL和幾個例外）

allkeys-lru：嘗試回收最少使用的鍵（LRU）,使得新添加的數(shù)據(jù)有空間存放。

volatile-lru：嘗試回收最少使用的鍵（LRU）,但僅限于在過期集合的鍵，使

得新添加的數(shù)據(jù)有空間存放。

allkeys-random：回收隨機(jī)的鍵使得新添加的數(shù)據(jù)有空間存放。

volatile-random：回收隨機(jī)的鍵使得新添加的數(shù)據(jù)有空間存放，但僅限于在

過期集合的鍵。

volatile-tt：回收在過期集合的鍵，并且優(yōu)先回收存活時間（TTL）較短的鍵,

使得新添加的數(shù)據(jù)有空間存放。

4、為什么Redis需要把所有數(shù)據(jù)放到內(nèi)存中？

Redis為了達(dá)到最快的讀寫速度將數(shù)據(jù)都讀到內(nèi)存中，并通過異步的方式將

數(shù)據(jù)寫入磁盤。所以redis具有快速和數(shù)據(jù)持久化的特征。如果不將數(shù)據(jù)放在內(nèi)

存中，磁盤I/O速度為嚴(yán)重影響redis的性能。在內(nèi)存越來越便宜的今天，redis

將會越來越受歡迎。如果設(shè)置了最大使用的內(nèi)存，則數(shù)據(jù)已有記錄數(shù)達(dá)到內(nèi)存限

值后不能繼續(xù)插入新值。

5、Rcdis集群方案應(yīng)該怎么做？都有哪些方案？

l.twemproxy,大概概念是，它類似于一個代理方式，使用方法和普通redis

無任何區(qū)別，設(shè)置好它下屬的多個redis實(shí)例后，使用時在本需要連接redis的地

方改為連接twemproxy,它會以一個代理的身份接收請求并使用一致性hash算

法，將請求轉(zhuǎn)接到具休redis,將結(jié)果再返回twemproxy。使用方式簡便（相對redis

只需修改連接端口），對舊項目擴(kuò)展的首選。問題：twemproxy自身單端口實(shí)例

的壓力，使用一致性hash后，對redis節(jié)點(diǎn)數(shù)量改變時候的計算值的改變，數(shù)據(jù)

無法自動移動到新的節(jié)點(diǎn)。

2.codis,目前用的最多的集群方案，基本和twemproxy一致的效果，但它支

持在節(jié)點(diǎn)數(shù)量改變情況下，舊節(jié)點(diǎn)數(shù)據(jù)可恢復(fù)到新hash節(jié)點(diǎn)。

3.rediscluster3.O自帶的集群，特點(diǎn)在于他的分布式算法不是一致性hash,而

是hash槽的概念，以及自身支持節(jié)點(diǎn)設(shè)置從節(jié)點(diǎn)。具體看官方文檔介紹。

4.在業(yè)務(wù)代碼層實(shí)現(xiàn)，起幾個亳無關(guān)聯(lián)的redis實(shí)例，在代碼層，對key進(jìn)

行hash計算，然后去對應(yīng)的redis實(shí)例操作數(shù)據(jù)。這種方式對hash層代碼要求

比較高，考慮部分包括，節(jié)點(diǎn)失效后的替代算法方案，數(shù)據(jù)震蕩后的自動腳本恢

復(fù)，實(shí)例的監(jiān)控，等等。

6、Redis集群方案什么情況下會導(dǎo)致整個集群不可用？

有A,B,C三個節(jié)點(diǎn)的集群，在沒有復(fù)制模型的情況下，如果節(jié)點(diǎn)B失敗了，

那么整個集群就會以為缺少5501-11000這個范圍的槽而不可用。

7、Redis如何設(shè)置密碼及驗證密碼？

設(shè)置密碼：

授權(quán)密碼：

8、說說Redis哈希槽的概念？

Redis集群沒有使用一致性hash,而是引入了哈希槽的概念，Redis集群有

16384個哈希槽，每個key通過CRC16校驗后對16384取模來決定放置哪個槽,

集群的每個節(jié)點(diǎn)負(fù)責(zé)一部分hash槽。

9、Redis集群的主從復(fù)制模型是怎樣的？

為了使在部分節(jié)點(diǎn)失敗或者大部分節(jié)點(diǎn)無法通信的情況下集群仍然可用，所

以集群使用了主從復(fù)制模型，每個節(jié)點(diǎn)都會有N-1個復(fù)制品.

10、Redis集群會有寫操作丟失嗎？為什么？

Rcdis并不能保證數(shù)據(jù)的強(qiáng)一致性，這意味著在實(shí)際中集群在特定的條件下

可能會丟失與操作。

11、Redis集群之間是如何復(fù)制的？

異步復(fù)制

12、怎么理解Redis事務(wù)？

事務(wù)是一個單獨(dú)的隔離操作：事務(wù)中的所有命令都會序列化、按順序地執(zhí)行。

事務(wù)在執(zhí)行的過程中，不會被其他客戶端發(fā)送來的命令請求所打斷。

事務(wù)是一個原子操作：事務(wù)中的命令要么全部被執(zhí)行，要么全部都不執(zhí)行。

13、Redis事務(wù)相關(guān)的命令有哪幾個?

MULTkEXEC、DISCARD、WATCH

14、Rediskey的過期時間和永久有效分別怎么設(shè)置？

EXPIRE和PERSIST命令。

15、Rcdis如何做內(nèi)存優(yōu)化？

盡可能使用散列表（hashes）,散列表（是說散列表里面存儲的數(shù)少）使用

的內(nèi)存非常小，所以你應(yīng)該盡可能的將你的數(shù)據(jù)模型抽象到一個散列表里面。比

如你的web系統(tǒng)中有一個用戶對象，不要為這個用戶的名稱，姓氏，郵箱，密

碼設(shè)置單獨(dú)的key,而是應(yīng)該把這個用戶的所有信息存儲到一張散列表里面。

16、Redis回收進(jìn)程如何工作的？

一個客戶端運(yùn)行了新的命令，添加了新的數(shù)據(jù)。

Redi檢查內(nèi)存使用情況，如果大于maxmemory的限制，則根據(jù)設(shè)定好的策略

進(jìn)行回收。

一個新的命令被執(zhí)行，等等。

所以我們不斷地穿越內(nèi)存限制的邊界，通過不斷達(dá)到邊界然后不斷地回收回

到邊界以下。

如果一個命令的結(jié)果導(dǎo)致大量內(nèi)存被使用（例如很大的集合的交集保存到一

個新的鍵），不用多久內(nèi)存限制就會被這個內(nèi)存使用量超越。

17、Redis回收使用的是什么算法？

LRU算法

18、Rcdis如何做大量數(shù)據(jù)插入？

Redis2.6開始redis-cli支持一種新的被稱之為pipemode的新模式用于執(zhí)行大

量數(shù)據(jù)插入工作。

19、為什么要做Redis分區(qū)？

分區(qū)可以讓Redis管理更大的內(nèi)存，Redis將可以使用所有機(jī)器的內(nèi)存。如

果沒有分區(qū)，你最多只能使用一臺機(jī)器的內(nèi)存。分區(qū)使Redis的計算能力通過簡

單地增加計算機(jī)得到成倍提升,Redis的網(wǎng)絡(luò)帶寬也會隨著計算機(jī)和網(wǎng)卡的增加

而成倍增長。

20、Redis持久化數(shù)據(jù)和緩存怎么做擴(kuò)容？

如果Rcdis被當(dāng)做緩存使用，使用一致性哈希實(shí)現(xiàn)動態(tài)擴(kuò)容縮容。

如果Redis被當(dāng)做一個持久化存儲使用，必須使用固定的keys-to-nodes映射

關(guān)系，節(jié)點(diǎn)的數(shù)量一旦確定不能變化。否則的話（即Redis節(jié)點(diǎn)需要動態(tài)變化的

情況），必須使用可以在運(yùn)行時進(jìn)行數(shù)據(jù)再平衡的一套系統(tǒng)，而當(dāng)前只有Redis

集群可以做到這樣。

21、分布式Rcdis是前期做還是后期規(guī)模上來了再做好？為什么？

既然Redis是如此的輕量（單實(shí)例只使用1M內(nèi)存），為防止以后的擴(kuò)容，最

好的辦法就是一開始就啟動較多實(shí)例。即便你只有一臺服務(wù)器，你也可以一開始

就讓Redis以分布式的方式運(yùn)行，使用分區(qū)，在同一臺服務(wù)器上啟動多個實(shí)例。

一開始就多設(shè)置幾個Redis實(shí)例，例如32或者64個實(shí)例，對大多數(shù)用戶來

說這操作起來可能比較麻煩，但是從長久來看做這點(diǎn)犧牲是值得的。

這樣的話，當(dāng)你的數(shù)據(jù)不斷增長，需要更多的Redis服務(wù)器時，你需要做的

就是僅僅將Redis實(shí)例從一臺服務(wù)遷移到另外一臺服務(wù)器而已（而不用考慮重新

分區(qū)的問題）。一旦你添加了另一臺服務(wù)器，你需要將你一半的Redis實(shí)例從第

一臺機(jī)器遷移到第二臺機(jī)器。

22、都有哪些辦法可以降低Redis的內(nèi)存使用情況呢？

如果你使用的是32位的Redis實(shí)例，可以好好利用Hash,list,sorledset,set等

集合類型數(shù)據(jù)，因為通常情況下很多小的Key-Value可以用更緊湊的方式存放到

一起。

23、查看Rcdis使用情況及狀態(tài)信息用什么命令？

Info

24、Rcdis的內(nèi)存用完了會發(fā)生什么？

如果達(dá)到設(shè)置的上限，Redis的寫命令會返回錯誤信息(但是讀命令還可以

正常返回。)或者你可以將Redis當(dāng)緩存來使用配置淘汰機(jī)制，當(dāng)Redis達(dá)到內(nèi)存

上限時會沖刷掉舊的內(nèi)容。

25.Redis是單線程的，如何提高多核CPU的利用率？

可以在同一個服務(wù)器部署多個Redis的實(shí)例，并把他們當(dāng)作不同的服務(wù)器來

使用，在某些時候，無論如何一個服務(wù)器是不夠的，所以，如果你想使用多個

CPU,你可以考慮一下分片(shard)。

26、一個Redis實(shí)例最多能存放多少的keys?List、Set、SortedSet他們最多

能存放多少元素？

理論上Redis可以處理多達(dá)232的keys,并且在實(shí)際中進(jìn)行了測試，每個實(shí)

例至少存放了2億5千萬的keyso我們正在測試一些較大的值。

任何listsset^和sortedset都可以放232個元素。

換句話說，Rcdis的存儲極限是系統(tǒng)中的可用內(nèi)存值。

27、Rcdis常見性能問題和解決方案？

(l)Master最好不要做任何持久化工作，如RDB內(nèi)存快照和AOF日志叉件

(2)如果數(shù)據(jù)比較重要，某個Slave開啟AOF備份數(shù)據(jù)，策略設(shè)置為每秒同

步一次

(3)為了主從復(fù)制的速度和連接的穩(wěn)定性，Master和Slave最好在同一個局域

網(wǎng)內(nèi)

(4)盡量避免在壓力很大的主庫上增加從庫

(5)主從復(fù)制不要用圖狀結(jié)構(gòu)，用單向鏈表結(jié)構(gòu)更為穩(wěn)定，即：

Master<-Slave1<-Slave2<-Slave3

這樣的結(jié)構(gòu)方便解決單點(diǎn)故障問題，實(shí)現(xiàn)Slave對Master的替換。如果Master

掛了，可以立刻啟用Slave1做Master,其他不變。

28、Redis提供了哪幾種持久化方式？

RDB持久化方式能夠在指定的時間間隔能對你的數(shù)據(jù)進(jìn)行快照存儲。

AOF持久化方式汜錄每次對服務(wù)器寫的操作，當(dāng)服務(wù)器重啟的時候會重新

執(zhí)行這些命令來恢復(fù)原始的數(shù)據(jù)，AOF命令以rcdis協(xié)議追加保存每次寫的操作

到文件末尾。Redis還能對AOF文件進(jìn)行后臺重寫，使得AOF文件的體積不至

于過大。

如果你只希望你的數(shù)據(jù)在服務(wù)器運(yùn)行的時候存在，你也可以不使用任何持久

化方式。

你也可以同時開啟兩種持久化方式，在這種情況下，當(dāng)redis重啟的時候會

優(yōu)先載入AOF文件來恢復(fù)原始的數(shù)據(jù)，因為在通常情況下AOF文件保存的數(shù)據(jù)

集要比RDB文件保存的數(shù)據(jù)集要完整。

最重要的事情是了解RDB和AOF持久化方式的不同，讓我們以RDB持久

化方式開始。

29、如何選擇合適的持久化方式？

一般來說，如果想達(dá)到足以媲美PostgreSQL的數(shù)據(jù)安全性，你應(yīng)該同時使

用兩種持久化功能。如果你非常關(guān)心你的數(shù)據(jù)，但仍然可以承受數(shù)分鐘以內(nèi)的數(shù)

據(jù)丟失，那么你可以只使用RDB持久化。

有很多用戶都只使用AOF持久化，但并不推薦這種方式:因為定時生成RDB

快照(snapshot)非常便于進(jìn)行數(shù)據(jù)庫備份，并且RDB恢復(fù)數(shù)據(jù)集的速度也要比

AOF恢復(fù)的速度要快，除此之外，使用RDB還可以避免之前提到的AOF程序

的bugo

30、修改配置不重啟Redis會實(shí)時生效嗎？

針對運(yùn)行實(shí)例，有許多配置選項可以通過CONFIGSET命令進(jìn)行修改，而無

需執(zhí)行任何形式的重啟。從Redis2.2開始，可以從AOF切換到RDB的快照持久

性或其他方式而不需要重啟RediSo檢索＜CONFIGGET,命令獲取更多信息。

但偶爾重新啟動是必須的，如為升級Redis程序到新的版本，或者當(dāng)你需要

修改某些目前CONFIG命令還不支持的配置參數(shù)的時候。

10個Redis架構(gòu)和運(yùn)維必懂的知識

一、高可用相關(guān)

1、Redis常用高可用架構(gòu)有哪些？

Redis高可用架構(gòu)如下：

RedisSentinel集群+內(nèi)網(wǎng)DNS+自定義腳本

RedisSentinel集群+VIP+自定義腳本

封裝客戶端直連RedisSentinel端口

JedisSentinelPool,適合Java

PHP基于phpredis自行封裝

RedisSentinel集群+Keepalived/Haproxy

RedisM/S+Keepalived

RedisCluster

Twemproxy

Codis

2、Redis高可用架構(gòu)優(yōu)劣對比？

—RedisSentinel集群+內(nèi)網(wǎng)DNS+自定義腳本

優(yōu)點(diǎn)：

秒級切換

腳本自定義，架構(gòu)可控

對應(yīng)用透明

缺點(diǎn)：

維護(hù)成本略高

依賴DNS,存在解析延時

Sentinel模式存在短時間的服務(wù)不可用

—RedisSentinel集群+VIP+自定義腳本

優(yōu)點(diǎn)：

秒級切換

腳本自定義，架構(gòu)可控

對應(yīng)用透明

缺點(diǎn)：

維護(hù)成本略高

Sentinel模式存在短時間的服務(wù)不可用

一封裝客戶端直連RedisSentinel端口

優(yōu)點(diǎn)：

服務(wù)探測故障及時

DBA維護(hù)成本低

缺點(diǎn)：

依賴客戶端支持Sentinel

Sentinel服務(wù)器需要開放訪問權(quán)限

對應(yīng)用有侵入性

—RedisSentinel集群+Keepalived/Haproxy

優(yōu)點(diǎn)：

秒級切換

對應(yīng)用透明

缺點(diǎn)：

維護(hù)成本高

存在腦裂

Sentinel模式存在短時間的服務(wù)不可用

一RedisM/S+Keepalived

優(yōu)點(diǎn)：

秒級切換

對應(yīng)用透明

部署簡單，維護(hù)成本低

缺點(diǎn)：

需要腳本實(shí)現(xiàn)切換功能

存在腦裂

（RedisCluster^Twemproxy>Codis優(yōu)劣對比見下個問題）

3、常見的Rcdis集群方案有哪些優(yōu)缺點(diǎn)？

Twemproxy:

多個同構(gòu)Twcmproxy（配置相同）同時工作，接受客戶端的請求，根據(jù)hash

算法，轉(zhuǎn)發(fā)給對應(yīng)的Redis。

優(yōu)點(diǎn)：

開發(fā)簡單，對應(yīng)用幾乎透明

歷史悠久，方案成熟

缺點(diǎn)：

代理影響性能

LVS和Twcmproxy會有節(jié)點(diǎn)性能瓶頸

Redis擴(kuò)容非常麻煩

Twitler內(nèi)部已放棄使用該方案，新使用的架構(gòu)未開源

Codis:

ZooKeeper

存放路由表和代理節(jié)點(diǎn)元數(shù)據(jù)

分發(fā)Codis-Config的命令

Codis-Config集成管理工具，有web界面

Codis-Proxy

無狀態(tài)代理，兼容Rcdis協(xié)議

對業(yè)務(wù)透明

Codis-Rcdis

基于2.8版本，二次開發(fā)

加入slot支持和遷移命令

優(yōu)點(diǎn)：

開發(fā)簡單，對應(yīng)用幾乎透明

性能比Twcmproxy好

有圖形化界面，擴(kuò)容容易，運(yùn)維方便

缺點(diǎn)：

代理依舊影響性能

組件過多，需要很多機(jī)器資源

修改了Redis代碼，導(dǎo)致和官方無法同步，新特性跟進(jìn)緩慢

開發(fā)團(tuán)隊準(zhǔn)備主推基于Redis改造的reborndb

RedisCluster:

P2P模式，無中心化。把key分成16384個slol,每個實(shí)例負(fù)責(zé)一部分slol。

客戶端請求若不在連接的實(shí)例，該實(shí)例會轉(zhuǎn)發(fā)給對應(yīng)的實(shí)例。通過Gossip協(xié)議

同步節(jié)點(diǎn)信息。

優(yōu)點(diǎn)：

組件all?in-box,部署簡單，節(jié)約機(jī)器資源

性能比proxy模式好

自動故障轉(zhuǎn)移、Slot遷移中數(shù)據(jù)可用

官方原生集群方案，更新與支持有保障

缺點(diǎn)：

架構(gòu)比較新，最佳實(shí)踐較少

多鍵操作支持有限（驅(qū)動可以曲線救國）

為了性能提升，客戶端需要緩存路由表信息

節(jié)點(diǎn)發(fā)現(xiàn)、rcshard操作不夠自動化

二、Redis通用

1、Redis相對MySQL、PostgreSQL這些關(guān)系型數(shù)據(jù)庫，有什么優(yōu)缺點(diǎn)？

期占—'?

Redis主要是用來做緩存，它有持久化，但也只是為了緩存的可靠而已，優(yōu)

點(diǎn)是數(shù)據(jù)全放內(nèi)存，速度快。缺點(diǎn)就是，數(shù)據(jù)大小不能超過內(nèi)存大小。兩個用在

不同業(yè)務(wù)場景，Redis無法取代傳統(tǒng)關(guān)系型數(shù)據(jù)庫。

觀點(diǎn)二：

Redis首先它是一種內(nèi)存數(shù)據(jù)庫，最大的優(yōu)勢在于效率高;尤其在某些特定

場合下，例如熱點(diǎn)數(shù)據(jù)量非常大，而數(shù)據(jù)從內(nèi)存和磁盤之間的換入換出代價比較

高的情況下，Redis就會體現(xiàn)它的價值。

傳統(tǒng)關(guān)系型數(shù)據(jù)庫在于它對數(shù)據(jù)的一致性保障，它的數(shù)據(jù)模型范式是遵循嚴(yán)

格事務(wù)規(guī)則的結(jié)構(gòu)化數(shù)據(jù)，由于其數(shù)據(jù)的高度抽象化，它調(diào)度到內(nèi)存的數(shù)據(jù)一般

場合下不會占用很大的內(nèi)存空間。

總的來說，兩種數(shù)據(jù)庫各有各的優(yōu)點(diǎn)和缺點(diǎn)。不同的業(yè)務(wù)場合有特定的追求

目標(biāo)，redis首要的是效率，適用的是一些單純二維結(jié)構(gòu)化數(shù)據(jù)無法表達(dá)的數(shù)據(jù)

模型，而關(guān)系型數(shù)據(jù)庫處理的是可以用范式模型表達(dá)的二維數(shù)據(jù)，追求的是數(shù)據(jù)

的高度一致性。隨著IT的發(fā)展，每一類型的數(shù)據(jù)庫都會在其特定的場合內(nèi)發(fā)揮

出無可比擬的優(yōu)勢，最終的趨勢是大家趨于平衡，沒有最好，只有最適合。

觀點(diǎn)三：

記窘一句話：任何數(shù)據(jù)庫都有自己的應(yīng)用場景，應(yīng)該關(guān)注數(shù)據(jù)流、數(shù)據(jù)屬性。

個人的經(jīng)驗來說，Rcdis不可能取代MySQL或者PG。

2、Redis有哪些應(yīng)用場景？

Rcdis是一個高性能的緩存，一般應(yīng)用在Session緩存、隊列、排行榜、計數(shù)

器、最近最熱文章、最近最熱評論、發(fā)布訂閱等。

更多應(yīng)用場景，可以參考此處。

可以這樣講，Redis適用于數(shù)據(jù)實(shí)時性要求高、數(shù)據(jù)存儲有過期和淘汰特征

的，不需要持久化或者只需要保證弱一致性，邏置簡單的場景。

3、新接手一個復(fù)雜的Redis集群（Sentinel模式），如何了解它

剛剛接手一套Redis集群，想要了解這套集群的相關(guān)配置。應(yīng)該如何入手。

難道只能通過info命令去查看各個配置嗎？

這是筆者的建議：

通讀Sentinel官方文檔

Google搜索RedisSentinel,找?guī)灼杏⑽牡奈恼驴纯?/p>

進(jìn)入Sentinel集群后，使用inf。查看集群信息

查看Sentinel配置文件，配合文檔搞清楚每個參數(shù)的含義

使用幾臺虛擬機(jī)模擬線上環(huán)境，然后做測試，在實(shí)踐中深入理解

思考當(dāng)前Sentinel集群是否有不合理的地方，如有，提出并改進(jìn)

三、Redis故障排查

1、Redis實(shí)例中，存在大量的FIN_WAIT2連接

客戶端TCP狀態(tài)遷移：

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TI

ME_WAIT->CLOSED

服務(wù)器TCP狀態(tài)遷移：

CLOSED->L1STEN->SYN收至l]

->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

這個狀態(tài)存在于主動發(fā)起時開請求的一端，如果服務(wù)器存在大量的這個狀

態(tài)，那么這個服務(wù)器就充當(dāng)客戶端的角色，如網(wǎng)絡(luò)爬蟲，出現(xiàn)的原因是由于客戶

端發(fā)起FIN請求結(jié)束連接之后，收到了服務(wù)端的應(yīng)答之后進(jìn)入FIN_WAIT2,之

后就沒收到服務(wù)端發(fā)送的FIN信號導(dǎo)致。

PS：線上Web客戶端用的什么語言？

2、如何知道當(dāng)前Rcdis實(shí)例是處于阻塞狀態(tài)？

解答一：隨便get一個key,然后卡著不動就行，簡單粗暴。優(yōu)雅一點(diǎn)是看

latency的延遲，blockcd_clients的數(shù)量，rejected_connections的數(shù)量等。

解答二：_

方法一：登錄Redis,執(zhí)行info,查看blocked_clients

方法二：執(zhí)行redis-cli-Iatency-h-p查看延時情況

3、Redis運(yùn)維的故障有哪些？

回答一：常見的運(yùn)維故障

使用keys*把庫堵死，——建議使用別名把這個命令改名

超過內(nèi)存使用后，部分?jǐn)?shù)據(jù)被刪除一一這個有刪除策略的，選擇適合自己的

即可

沒開持久化，卻重啟了實(shí)例，數(shù)據(jù)全掉一一記得非緩存的信息需要打開持久

化

RDB的持久化需要vm.overcommit_memory=l,否則會持久化失敗

沒有持久化情況下，主從，主重啟云快，從還沒認(rèn)為主掛的情況下，從會清

空自己的數(shù)據(jù)一一人為重啟主節(jié)點(diǎn)前，先關(guān)閉從節(jié)點(diǎn)的同步

回答二：我簡單說下Rcdis故障的排查方法吧。

了解清楚業(yè)務(wù)數(shù)據(jù)流是怎么樣的

結(jié)合Redis監(jiān)控查看QPS、緩存命中率、內(nèi)存使用率等信息

確認(rèn)機(jī)器層面的資源是否有異常

故障時及時上機(jī)，使用redis-climonilor打印出操作日志，然后分析（事后分

析此條失效）

和研發(fā)溝通，確認(rèn)是否有大Key在堵塞（大Key也可以在日常的巡檢中獲

得）

和組內(nèi)同事溝通，確實(shí)是否有誤操作

和運(yùn)維同事、研發(fā)一起排查流量是否正常，是否存在被刷的情況

更多的排查需要走線上系統(tǒng)的分析。

四、Redis性能優(yōu)化

1、提高Redis內(nèi)存數(shù)據(jù)庫的性能，有哪些措施？

這個問題有點(diǎn)偏題了，還是回答下吧。整理下工作中積累的經(jīng)驗：

根據(jù)不同業(yè)務(wù)選擇數(shù)據(jù)類型，有必要時對數(shù)據(jù)結(jié)構(gòu)進(jìn)行審核，減少數(shù)據(jù)冗余

精簡犍名和鍵值，控制鍵值的大小

使用前綴管理好key

使用scan代替keys,將遍歷RedisDB中所有key的操作放到客戶端來做

避免使用0（N）復(fù)雜度的命令

配置使用ziplist來優(yōu)化list

合理配置maxmemory

數(shù)據(jù)量大的情況，做好key和value的壓縮

利用管道，批量處理命令

根據(jù)不同業(yè)務(wù)選擇短鏈接或者長鏈接

定期使用redis-cli-big-keys檢測大Key

Redis調(diào)優(yōu)、監(jiān)控知識和10個具體應(yīng)用難點(diǎn)

一、Redis數(shù)據(jù)庫的優(yōu)缺點(diǎn)及適用場景

Redis持久服務(wù)的特點(diǎn)，key-value鍵值類型存儲系統(tǒng)，支持?jǐn)?shù)據(jù)可靠存儲，

單進(jìn)程單線程高性能服務(wù)器，恢復(fù)比較慢單機(jī)qps（秒并發(fā)）可以達(dá)到10W,適

合小數(shù)據(jù)高速讀寫訪問。

Rcdis存儲系統(tǒng)優(yōu)、缺點(diǎn)：可以持久化存儲數(shù)據(jù)，支持每秒10W的讀寫頻率,

支持豐富的數(shù)據(jù)類型，所有操作都是原子性的，支持異機(jī)主從復(fù)制，內(nèi)存管理開

銷大（低于物理內(nèi)存的3/5）,不同命令延遲差別大，官方網(wǎng)站：

主要使用場景分為兩大塊：

1、緩存：熱點(diǎn)數(shù)據(jù)放到緩存里，大部分情況命中緩存，不命中時，訪問磁

盤存儲并更新緩存

2、鍵值存儲，獨(dú)立使用緩存作為數(shù)據(jù)提供方。依賴于緩存服務(wù)的可靠性不

高，業(yè)務(wù)對事務(wù)和數(shù)據(jù)的一致性要求不高。具體的，一般由架構(gòu)師和開發(fā)人員，

根據(jù)業(yè)務(wù)的特性，設(shè)計出具體的使用方法。

二、Redis的調(diào)優(yōu)參數(shù)

Redis的參數(shù)調(diào)優(yōu)問題，根據(jù)場景不同，有不同的調(diào)優(yōu)方法，以下列舉踩過

的一些坑的參數(shù)調(diào)優(yōu)。我們的場景的海量數(shù)據(jù)，高并發(fā)。

(1)timeout參數(shù),非常需要關(guān)注,官方對timeout的解釋如下:該參數(shù)表

示當(dāng)某一個客戶端連接上來并閑置timeout(單位秒)的時間后，Redis服務(wù)端就

主動關(guān)閉這個客戶端連接。我們發(fā)現(xiàn)如果客戶端對連接處理比較差的時候，存在

連接不釋放的問題，導(dǎo)致連接池耗盡，單個redis默認(rèn)的連接數(shù)是1000.所以需要

在timeoul參數(shù)做文章，強(qiáng)制釋放無效連接，我們的參數(shù)調(diào)整為limeout30000

(2)持久化參數(shù)，RDB和AOF究竟開哪個，很多人很糾結(jié)。其實(shí)選擇很

簡單，兩者的區(qū)別是持久化的顆粒度不一樣，如果你關(guān)注數(shù)據(jù)的強(qiáng)一致性，選擇

AOF,如果你選擇更好的性能，選型RDBo如果你選擇極致的性能，又能容忍

數(shù)據(jù)的丟失，那你可以完全不用開啟持久化，當(dāng)然了，集群是一定要開持久化的。

(3)tcp-backlog和maxclient,這兩個參數(shù)可能大家也比較迷糊，maxclient

模式10000,一般情況下是夠了，但是在高并發(fā)海量訪問的時候，還是會出現(xiàn)客

戶端緩慢的情況，那就是系統(tǒng)的限制，就是backlog參數(shù)，你可以理解為在三次

握手時進(jìn)入acceptqueue隊列的最大值，也就是send_Q,所以這個值設(shè)大點(diǎn)是沒

有壞處的，我們的設(shè)置是1024

(4)重點(diǎn)提一下安全的參數(shù)，requirepassfoobared個人認(rèn)為，如果你們覺得

你們hold住，那就不用開，如果在DMZ區(qū)，數(shù)據(jù)又比較重要，那就開。個人認(rèn)

為，密碼的作用不是你想象中的帶給你安全，第一rcdis一分鐘可以訪問你想象

不到的次數(shù)，如果弱密碼，分分鐘破解，第二auth命令是明文的，破解也很容

易。

(5)maxmemory,這個參數(shù)比較常見，但是也非常的坑。如果你選擇用，

有個原則，你是當(dāng)數(shù)據(jù)庫用還是當(dāng)緩存用，如果當(dāng)數(shù)據(jù)庫用，就不要開，如果當(dāng)

緩存用，可以開。曾經(jīng)有個BUG,多個salve的情況下，會導(dǎo)致擦除主節(jié)點(diǎn)的數(shù)

據(jù)。如果你開啟這個參數(shù)，記得預(yù)留一些空間給系統(tǒng)的buffer。

遵循你的使用場景和你對參數(shù)的了解。寧愿逐步踩坑逐步解決問題逐步深入

了解，也不要盲從的調(diào)整參數(shù)。

三、Redis的監(jiān)控指標(biāo)

內(nèi)存使用。如果Redis使用的內(nèi)存超出了可用的物理內(nèi)存大小，那么Redis

很可能系統(tǒng)會被殺掉。針對這一點(diǎn)，你可以通過info命令對used_memory和

used_memory_peak進(jìn)行監(jiān)控，為使用內(nèi)存量設(shè)定閥值，并設(shè)定相應(yīng)的報警機(jī)制。

當(dāng)然，報警只是手段，重要的是你得預(yù)先計劃好，當(dāng)內(nèi)存使用量過大后，你應(yīng)該

做些什么，是清除一些沒用的冷數(shù)據(jù)，還是把Rcdis遷移到更強(qiáng)大的機(jī)器上去。

持久化。如果因為你的機(jī)器或Redis本身的問題導(dǎo)致Redis崩潰了，那么你

唯一的救命稻草可能就是dump出來的rdb文件了，所以，對Rcdisdump文件進(jìn)

行監(jiān)控也是很重要的?？梢酝ㄟ^對rdb_last_save_time進(jìn)行監(jiān)控，了解最近一次

dump數(shù)據(jù)操作的時間，還可以通過對rdb_changes_since」asl_save進(jìn)行監(jiān)控來獲

得如果這時候出現(xiàn)故障，會丟失(即已改屋)多少數(shù)據(jù)。

Keyso通過獲取Keyspace中的結(jié)果得到各個數(shù)據(jù)庫中key的數(shù)量

QPSo即每分鐘執(zhí)行的命令個數(shù)，即：

(total_commands_processed2-total_commands_processed1)/span,為了實(shí)時得

到QPS,可以他定腳本在后臺運(yùn)行，記錄過去幾分鐘的

total_commands_processedo在計算QPS時，利用過去的信息和當(dāng)前的信息得出

QPS的估計值。

四、如何更好更合理的使用Redis------1（）個具體應(yīng)用難點(diǎn)解讀

l.Redis與Oracle中存有同一份數(shù)據(jù)，當(dāng)數(shù)據(jù)發(fā)生變化時，應(yīng)用程序是先寫

Redis然后再同步到Oracle,還是先寫Oracle然后再同步到Redis呢，使用何種

同步機(jī)制可以有效的解決這個時間差中兩份數(shù)據(jù)的不一致性呢？

答：如果你是當(dāng)數(shù)據(jù)庫用，那就類似于電商搶購場景。搶購的場景中有個需

要解決的問題是超買和超賣，意思就是說，我要控制庫存數(shù)量，而且要保證可用

庫存的數(shù)量為0,不能出現(xiàn)負(fù)數(shù)。一般是把數(shù)據(jù)從Oracle刷到Redis,貼合題主

的問題，那就是同樣有一份數(shù)據(jù)，當(dāng)數(shù)據(jù)變化的時候，是先寫Redis還是先寫

Oracle?是先寫Redis,再寫Oracle,因為代碼層面保證數(shù)據(jù)的一致性，在高并發(fā)

情況下，悲觀鎖機(jī)制并不會很友好，而且影響性能。而redis天然的原子性事務(wù),

是可以保證數(shù)據(jù)的一致性。

如果你當(dāng)緩存用，又要確保數(shù)據(jù)的強(qiáng)一致性，是可以先寫Redis,也可以先

寫Oracle,如果先寫Redis,參考前一段話，采取Redis的強(qiáng)一致性；如果先寫

Oracle,那就采取悲觀鎖來實(shí)現(xiàn)。

2.目前的監(jiān)控系統(tǒng)是Python至Oracle取配置信息，經(jīng)過運(yùn)算之后再寫回

Oracle,然后根據(jù)閥值來觸發(fā)告警，在這樣的模式之下Redis是否有可以應(yīng)用的

空間呢？

答：當(dāng)你的監(jiān)控的需求具備秒級監(jiān)控的能力后，你的wcb-db的架構(gòu)就不再

滿足了

比如說以下場景

1：基于日志的流式計算

2：監(jiān)控指標(biāo)的基線

3：數(shù)據(jù)的統(tǒng)計分析

4：通用的計算周期

5：多維度的告警規(guī)則：如無數(shù)據(jù)告警、基于同環(huán)比的告警、基于基線的告

警、越來越多的監(jiān)控場景、監(jiān)控指標(biāo)、觸發(fā)器，「cdis的作用就是提供你更快、

更優(yōu)質(zhì)的服務(wù)

3.我們的系統(tǒng)現(xiàn)在使用了兩套Rcdis；分別用作熱點(diǎn)數(shù)據(jù)緩存、會話保持保

存全局ID。熱點(diǎn)數(shù)據(jù)緩存采用的是一主一從三哨兵（分別獨(dú)立，共五個節(jié)點(diǎn)）；

會話保持采用的是一主三從四個哨兵（共四個節(jié)點(diǎn)，每個節(jié)點(diǎn)上啟動了一個哨兵

進(jìn)程）；這個是乙方給的方案，請教大神，這個方案可靠嗎？能否使用cluster方

案來替代呢？有必要嗎？

答：你有兩套Redis,A作為熱數(shù)據(jù)緩存，B作為回話保持。

缺點(diǎn)：A有5個節(jié)點(diǎn)，B有4個節(jié)點(diǎn)，9個節(jié)點(diǎn)中只有2個節(jié)點(diǎn)是主節(jié)點(diǎn)，

提供服務(wù)，備節(jié)點(diǎn)只是冗余，存在比較大的資源浪費(fèi)。

優(yōu)點(diǎn)：sentinel集群，客戶端可以隨意地連接任意一個sentinel來獲得關(guān)于

redis集群中的信息，做到代理層的可用性。切換至clusler后在資源使用率方面,

按照9節(jié)點(diǎn)的規(guī)模，實(shí)際組網(wǎng)只能有8臺，4主4從，資源使用率得到很大的提

升，而且代理層分別由8個節(jié)點(diǎn)負(fù)擔(dān)，因此，也能保證了可用性。

4.主機(jī)房部署了Redis集群，并數(shù)據(jù)持久化。問題：要求在主機(jī)房發(fā)生災(zāi)難

并不可修復(fù)的情況下，容災(zāi)機(jī)房能在一定時間內(nèi)承擔(dān)起主機(jī)房的業(yè)務(wù)能力。如何

保隙容災(zāi)機(jī)房的Redis集群數(shù)據(jù)跟主機(jī)房一致？如何操作？

答：主要看你采用集群的方式，如果是cluster,請參考，關(guān)于雙活機(jī)房中

cluster模式的組網(wǎng)，根據(jù)你的業(yè)務(wù)場景來決定。如果redis的使用中并不處在核

心鏈路上，完全當(dāng)做cache來使用，且在擊穿情況下有后續(xù)的數(shù)據(jù)庫來支撐，可

以放在同一機(jī)房內(nèi)。如果Redis的使用在核心鏈路上，當(dāng)做數(shù)據(jù)庫來使用，在單

側(cè)機(jī)房部署，不能保證多機(jī)房環(huán)境下的多活。以雙活機(jī)房為例，集群有A、a、B、

b、C、c節(jié)點(diǎn)，A、B、C三個節(jié)點(diǎn)部署在甲機(jī)房，a、b、c