一、什么是redis

其中對redis，我們通常用Jedis(也為我們提供了連接池JedisPool)。

在redis中,key就是byteredis的數(shù)據(jù)結(jié)構(gòu)(value):

String、list、set、orderset、hash

二、為什么快

1、純內(nèi)存操作

數(shù)據(jù)存放在內(nèi)存中，內(nèi)存的響應(yīng)時間大約是 100納秒 ，這是Redis每秒萬億級別訪問的重要基礎(chǔ)。

2、單線程操作，避免了頻繁的上下文切換

雖然是采用單線程，但是單線程避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導(dǎo)致的切換而消耗 CPU；雖然作者認(rèn)為CPU不是瓶頸，內(nèi)存與網(wǎng)絡(luò)帶寬才是。但實際測試時并非如此，見上。

3、采用了非阻塞I/O多路復(fù)用機制

多路I/O復(fù)用模型是利用 select、poll、epoll 可以同時監(jiān)察多個流的 I/O 事件的能力，在空閑的時候，會把當(dāng)前線程阻塞掉，當(dāng)有一個或多個流有 I/O 事件時，就從阻塞態(tài)中喚醒，于是程序就會輪詢一遍所有的流（epoll 是只輪詢那些真正發(fā)出了事件的流），并且只依次順序的處理就緒的流，這種做法就避免了大量的無用操作。這里“多路”指的是多個網(wǎng)絡(luò)連接，“復(fù)用”指的是復(fù)用同一個線程。加上Redis自身的事件處理模型將epoll中的連接，讀寫，關(guān)閉都轉(zhuǎn)換為了事件，不在I/O上浪費過多的時間。

4、純ANSI C編寫

不依賴第三方類庫，沒有像memcached那樣使用libevent，因為libevent迎合通用性而造成代碼龐大，所以作者用libevent中兩個文件修改實現(xiàn)了自己的epoll event loop。微軟的兼容Windows補丁也因為同樣原因被拒了。

快，原因之一是Redis多樣的數(shù)據(jù)結(jié)構(gòu)，每種結(jié)構(gòu)只做自己愛做的事，當(dāng)然比數(shù)據(jù)庫只有Table，MongogoDB只有JSON一種結(jié)構(gòu)快了。

三、I/O復(fù)用模型和Reactor 設(shè)計模式

詳情請看：使用 libevent 和 libev 提高網(wǎng)絡(luò)應(yīng)用性能——I/O模型演進變化史

Redis內(nèi)部實現(xiàn)采用epoll+自己實現(xiàn)的簡單的事件框架。 epoll中的讀、寫、關(guān)閉、連接都轉(zhuǎn)化成了事件，然后利用epoll的多路復(fù)用特性， 絕不在io上浪費一點時間：

1、I/O 多路復(fù)用的封裝

I/O 多路復(fù)用其實是在單個線程中通過記錄跟蹤每一個sock（I/O流） 的狀態(tài)來管理多個I/O流。

因為 Redis 需要在多個平臺上運行，同時為了最大化執(zhí)行的效率與性能，所以會根據(jù)編譯平臺的不同選擇不同的 I/O 多路復(fù)用函數(shù)作為子模塊，提供給上層統(tǒng)一的接口。

redis的多路復(fù)用， 提供了select, epoll, evport, kqueue幾種選擇，在編譯的時候來選擇一種。

select是POSIX提供的， 一般的操作系統(tǒng)都有支撐；

epoll 是LINUX系統(tǒng)內(nèi)核提供支持的；

evport是Solaris系統(tǒng)內(nèi)核提供支持的；

kqueue是Mac 系統(tǒng)提供支持的；

1. #ifdef HAVE_EVPORT
2. #include "ae_evport.c"
3. #else
4.     #ifdef HAVE_EPOLL
5.     #include "ae_epoll.c"
6.     #else
7.         #ifdef HAVE_KQUEUE
8.         #include "ae_kqueue.c"
9.         #else
10.         #include "ae_select.c"
11.         #endif
12.     #endif
13. #endif

為了將所有 IO 復(fù)用統(tǒng)一，Redis 為所有 IO 復(fù)用統(tǒng)一了類型名 aeApiState，對于 epoll 而言，類型成員就是調(diào)用 epoll_wait所需要的參數(shù)

接下來就是一些對epoll接口的封裝了：

包括創(chuàng)建 epoll(epoll_create)

注冊事件(epoll_ctl)

刪除事件(epoll_ctl)

阻塞監(jiān)聽(epoll_wait)等

創(chuàng)建 epoll 就是簡單的為 aeApiState 申請內(nèi)存空間，然后將返回的指針保存在事件驅(qū)動循環(huán)中，注冊事件和刪除事件就是對 epoll_ctl 的封裝，根據(jù)操作不同選擇不同的參數(shù)，阻塞監(jiān)聽是對 epoll_wait 的封裝，在返回后將激活的事件保存在事件驅(qū)動中。

2、Reactor 設(shè)計模式：事件驅(qū)動循環(huán)流程

Redis 服務(wù)采用 Reactor 的方式來實現(xiàn)文件事件處理器（每一個網(wǎng)絡(luò)連接其實都對應(yīng)一個文件描述符）

當(dāng) main 函數(shù)初始化工作完成后，就需要進行事件驅(qū)動循環(huán)，而在循環(huán)中，會調(diào)用 IO 復(fù)用函數(shù)進行監(jiān)聽

在初始化完成后，main 函數(shù)調(diào)用了 aeMain 函數(shù)，傳入的參數(shù)就是服務(wù)器的事件驅(qū)動

Redis 對于時間事件是采用鏈表的形式記錄的，這導(dǎo)致每次尋找最早超時的那個事件都需要遍歷整個鏈表，容易造成性能瓶頸。而 libevent 是采用最小堆記錄時間事件，尋找最早超時事件只需要 O(1) 的復(fù)雜度。

通過Reactor的方式，可以將用戶線程輪詢IO操作狀態(tài)的工作統(tǒng)一交給handle_events事件循環(huán)進行處理。

用戶線程注冊事件處理器之后可以繼續(xù)執(zhí)行做其他的工作（異步），而Reactor線程負(fù)責(zé)調(diào)用內(nèi)核的select/epoll函數(shù)檢查socket狀態(tài)。當(dāng)有socket被激活時，則通知相應(yīng)的用戶線程（或執(zhí)行用戶線程的回調(diào)函數(shù)），執(zhí)行handle_event進行數(shù)據(jù)讀取、處理的工作。由于select/epoll函數(shù)是阻塞的，因此多路IO復(fù)用模型也被稱為異步阻塞IO模型。注意，這里的所說的阻塞是指select函數(shù)執(zhí)行時線程被阻塞，而不是指socket。一般在使用IO多路復(fù)用模型時，socket都是設(shè)置為NONBLOCK的，不過這并不會產(chǎn)生影響，因為用戶發(fā)起IO請求時，數(shù)據(jù)已經(jīng)到達了，用戶線程一定不會被阻塞。

3、redis線程模型：

簡單來說，就是。我們的redis-client在操作的時候，會產(chǎn)生具有不同事件類型的socket。在服務(wù)端，有一段I/0多路復(fù)用程序，將其置入隊列之中。然后，IO事件分派器，依次去隊列中取，轉(zhuǎn)發(fā)到不同的事件處理器中。

四、redis的持久化方式：

能，將內(nèi)存中的數(shù)據(jù)異步寫入硬盤中，兩種方式：RDB（默認(rèn)）和AOF

1、RDB持久化原理

通過bgsave命令觸發(fā)，然后父進程執(zhí)行fork操作創(chuàng)建子進程，子進程創(chuàng)建RDB文件，根據(jù)父進程內(nèi)存生成臨時快照文件，完成后對原有文件進行原子替換（定時一次性將所有數(shù)據(jù)進行快照生成一份副本存儲在硬盤中）

優(yōu)點：是一個緊湊壓縮的二進制文件，Redis加載RDB恢復(fù)數(shù)據(jù)遠遠快于AOF的方式。

缺點：由于每次生成RDB開銷較大，非實時持久化，

2、AOF持久化原理

開啟后，Redis每執(zhí)行一個修改數(shù)據(jù)的命令，都會把這個命令添加到AOF文件中。

優(yōu)點：實時持久化。

缺點：所以AOF文件體積逐漸變大，需要定期執(zhí)行重寫操作來降低文件體積，加載慢

五、redis主掛了怎么操作

redis提供了哨兵模式，當(dāng)主掛了，可以選舉其他的進行代替，哨兵模式的實現(xiàn)原理，就是三個定時任務(wù)監(jiān)控。

每隔10s，每個S節(jié)點（哨兵節(jié)點）會向主節(jié)點和從節(jié)點發(fā)送info命令獲取最新的拓?fù)浣Y(jié)構(gòu)

每隔2s，每個S節(jié)點會向某頻道上發(fā)送該S節(jié)點對于主節(jié)點的判斷以及當(dāng)前Sl節(jié)點的信息，同時每個Sentinel節(jié)點也會訂閱該頻道，來了解其他S節(jié)點以及它們對主節(jié)點的判斷（做客觀下線依據(jù)）

每隔1s，每個S節(jié)點會向主節(jié)點、從節(jié)點、其余S節(jié)點發(fā)送一條ping命令做一次心跳檢測(心跳檢測機制)，來確認(rèn)這些節(jié)點當(dāng)前是否可達

當(dāng)三次心跳檢測之后，就會進行投票，當(dāng)超過半數(shù)以上的時候就會將該節(jié)點當(dāng)做主。

六、redis集群

redis集群在3.0以后提供了ruby腳本進行搭建，引入了糙的概念，

Redis集群內(nèi)節(jié)點通過ping/pong消息實現(xiàn)節(jié)點通信，消息不但可以傳播節(jié)點槽信息，還可以傳播其他狀態(tài)如：主從狀態(tài)、節(jié)點故障等。因此故障發(fā)現(xiàn)也是通過消息傳播機制實現(xiàn)的，主要環(huán)節(jié)包括：主觀下線（pfail）和客觀下線（fail）

1、主客觀下線：

主觀下線：集群中每個節(jié)點都會定期向其他節(jié)點發(fā)送ping消息，接收節(jié)點回復(fù)pong消息作為響應(yīng)。如果通信一直失敗，則發(fā)送節(jié)點會把接收節(jié)點標(biāo)記為主觀下線（pfail）狀態(tài)。

2、客觀下線

超過半數(shù)，對該主節(jié)點做客觀下線

主節(jié)點選舉出某一主節(jié)點作為領(lǐng)導(dǎo)者，來進行故障轉(zhuǎn)移。

故障轉(zhuǎn)移（選舉從節(jié)點作為新主節(jié)點）

七、內(nèi)存淘汰策略

Redis的內(nèi)存淘汰策略是指在Redis的用于緩存的內(nèi)存不足時，怎么處理需要新寫入且需要申請額外空間的數(shù)據(jù)。

noeviction：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時，新寫入操作會報錯。

allkeys-lru：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時，在鍵空間中，移除最近最少使用的key。

allkeys-random：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時，在鍵空間中，隨機移除某個key。

volatile-lru：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時，在設(shè)置了過期時間的鍵空間中，移除最近最少使用的key。

volatile-random：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時，在設(shè)置了過期時間的鍵空間中，隨機移除某個key。

volatile-ttl：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時，在設(shè)置了過期時間的鍵空間中，有更早過期時間的key優(yōu)先移除。

九、緩存擊穿的解決方案：

原因：

就是別人請求數(shù)據(jù)的時候，很多數(shù)據(jù)在緩存中無法查詢到，直接進入數(shù)據(jù)查詢，

解決方法：

對相關(guān)數(shù)據(jù)進行查詢的數(shù)據(jù)只查詢緩存，如果是一些特殊的可以進行數(shù)據(jù)庫查詢，也可以采用布隆過濾器進行查詢

十、緩存雪崩的解決方案：

緩存雪崩的原因：一次性加入緩存的數(shù)據(jù)過多，導(dǎo)致內(nèi)存過高，從而影響內(nèi)存的使用導(dǎo)致服務(wù)宕機

解決方法：

redis集群，通過集群方式將數(shù)據(jù)放置

后端服務(wù)降級和限流：當(dāng)一個接口請求次數(shù)過多，那么就會添加過多數(shù)據(jù)，可以對服務(wù)進行限流，限制訪問的數(shù)量，這樣就可以減少問題的出現(xiàn)

本文鏈接：http://www.51huadong.com/servernews/11007446.html