1.為什么說redis快?

• 完全基于內(nèi)存
• 采用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導(dǎo)致的切換而消耗CPU，也不存在加鎖和釋放鎖的操作。
• 使用多路I/O復(fù)用模型，非阻塞IO。
• 使用底層模型不同。Redis自己有VM機制，因為一般的系統(tǒng)調(diào)用系統(tǒng)函數(shù)的話，會浪費一定的時間去移動和請求。

2.多路I/O復(fù)用模型

“多路”指的是多個網(wǎng)絡(luò)連接，“復(fù)用”指的是復(fù)用同一個線程。
利用select、poll、epoll可以同時監(jiān)察多個流的I/O事件的能力，在空閑的時候，會把當(dāng)前阻塞掉，當(dāng)有一個或多個流有I/O事件時，就從阻塞態(tài)喚醒，于是程序就會輪詢一遍所有的流（epoll只輪詢那些真正發(fā)出了事件的流），并且只依次順序處理就緒的流。

2.1 select

select(int nfds, fd_set *r, fd_set *w,fd_set *e, struct timeval *timeout)

• nfds：r、w、e集合中標識符最大值加一。
• r：讀集合
• w：寫集合
• e：異常集合
• timeout：表示等待時間。如果設(shè)置為null，表示如果沒有事件時，可以一直處于阻塞狀態(tài)；否則，會根據(jù)指定的時間進行阻塞。

問題：

• 大小限制（FD_SETSIZE,1024)
• 在每次返回時都會被內(nèi)核修改，需要重新設(shè)置
• 在讀寫事件比較少的時候，依然需要對所有的集合進行掃描

2.2 poll

poll(struct pollfd *fds, int nfds, inttimeout)

 

struct pollfd {

    int fd;

    short events;

    short revents;

}

3.redis實現(xiàn)樂觀鎖？

• watch
• multi
• exec

4.哨兵機制

• 每個哨兵進程以每秒鐘依次的頻率向整個集群的Master主服務(wù)器，Slave從服務(wù)器以及其他Sentinl進程發(fā)送依次PING命令。
• 如果一個實例距離最后一次有效回復(fù)PING命令的時間超過down-after-milliseconds選項設(shè)定的值，則這個實例會被哨兵進程標記為主觀下線（SDOWN）。
• 如果一個Master主服務(wù)器被標記為主觀下線（SDOWN），則正在監(jiān)視這個Master主服務(wù)器的所有哨兵

5.緩存穿透和緩存雪崩

• 緩存穿透：指查詢大量不在緩存中的數(shù)據(jù)，會直接請求數(shù)據(jù)庫。

解決方法：
1.采用布隆過濾器，攔截肯定不存在的數(shù)據(jù)
2.為不存在的數(shù)據(jù)設(shè)置空值

• 緩存雪崩：大量數(shù)據(jù)緩存同時過期。

解決方法：
1.加鎖排隊
2.在原來過期時間添加一個隨機時間

6.sorted set 底層實現(xiàn)？

• 當(dāng)數(shù)據(jù)較少時，sorted set是由一個ziplist來實現(xiàn)的。
• 當(dāng)數(shù)據(jù)較多的時候，sorted set是由一個dict + 一個skiplist來實現(xiàn)的。dict用來查詢數(shù)據(jù)到分數(shù)的對應(yīng)關(guān)系，而skiplist用來根據(jù)分數(shù)查詢數(shù)據(jù)。

** skiplist和平衡樹、哈希表的比較**

• skiplist和平衡樹的元素是有序排列的，而哈希表不是。
• skiplist的范圍查詢要優(yōu)于平衡樹。平衡樹需要先找到范圍的最小值，然后通過中序遍歷的方式繼續(xù)尋找；而skiplist在找到最小值后，只需要對最低層的鏈表進行遍歷。
• 平衡樹的插入和刪除操作可能會引起子樹的調(diào)整，而skiplist只需要修改相鄰節(jié)點的指針，相對簡單。
• 查找key的時候，skiplist和平衡樹的時間復(fù)雜度都是O(logn)，而哈希表是O(1)。

7.redis持久化

RDB和AOF

由于Redis是內(nèi)存數(shù)據(jù)庫，它將自己的數(shù)據(jù)庫狀態(tài)存儲在內(nèi)存中，如果不想辦法將存儲在內(nèi)存中的數(shù)據(jù)庫狀態(tài)保存到磁盤里面，那么一旦服務(wù)器進程退出，服務(wù)器中的數(shù)據(jù)庫狀態(tài)也會消失不見。

RDB

• SAVE：會阻塞Redis服務(wù)器進程，直到RDB文件創(chuàng)建完成為止，在服務(wù)器進程阻塞期間，服務(wù)器不能處理任何命令請求。
• BGSAVE：會派生出一個子進程，然后由子進程負責(zé)創(chuàng)建RDB文件，父進程進行處理命令請求。

一旦BGSAVE開始執(zhí)行了，SAVE命令和BGSAVE命令都會被服務(wù)器拒絕，避免產(chǎn)生競爭條件。如果BGSAVE命令正在執(zhí)行，那么客戶端發(fā)送的BGREWRITEAOF命令會被延遲到BGSAVE命令執(zhí)行完畢之后執(zhí)行；如果BGREWRITEAOF命令正在執(zhí)行，那么客戶端發(fā)送的BGSAVE命令會被服務(wù)器拒絕。避免產(chǎn)生大量的磁盤寫入操作。

將某段時間內(nèi)的所有數(shù)據(jù)持久化到磁盤中，類似快照的行為。當(dāng)在進行持久化的過程時有數(shù)據(jù)的更新，會把這些記錄保存到備份文件中，最后會把備份文件拿來替換原文件。

缺點：如果機器發(fā)生故障，容易丟失某個時間段內(nèi)的數(shù)據(jù)。

AOF

將所有寫命令保存到AOF緩沖區(qū)中，根據(jù)appendfsync的值（默認為everysec）來對AOF文件同步，由于大量的寫入命令會導(dǎo)致AOF文件過大，后臺就會開啟一個子進程對原AOF文件進行重寫（合并命令），對文件進行壓縮。如果在重寫期間執(zhí)行了寫入命令，會將寫入命令保存到AOF重寫緩沖區(qū)中，等到AOF重寫結(jié)束，再將AOF重寫緩沖區(qū)中的內(nèi)容追加到新AOF文件中，此時會對父進程阻塞，最后用新AOF文件替換原AOF文件。

• 每秒fsync一次（默認）
• 每次有新命令追加到AOF文件是就執(zhí)行一次fsync
• 從不

缺點：由于恢復(fù)要進行的操作較多，可能會導(dǎo)致主線程阻塞。

8. redis zset底層為啥用skiplist而不用跳表？

跳表：采用多層鏈表結(jié)構(gòu)，查詢、刪除、插入時間復(fù)雜度都是O(logn)。

在操作時間復(fù)雜度差不多的情況下，skiplist的實現(xiàn)簡單。

9. redis 查詢某一前綴的key

方法一：利用keys查找（不推薦）

keys pattern：查找所有符合給定模式pattern的key

通過這種方式查詢可能會導(dǎo)致查詢時間過長，導(dǎo)致redis其他服務(wù)卡頓。

方法二：利用scan查找（推薦）

scan cursor [MATCH pattern] [COUNT count]

• 基于游標的迭代器，需要基于上一次的游標延續(xù)之前的迭代過程；
• 以0作為游標開始一次新的迭代，直到命令返回游標0完成一次遍歷；
• 不保證每次執(zhí)行都返回某個給定數(shù)量的元素，支持模糊查詢；
• 一次返回的數(shù)量不可控，只能是大概率符合count參數(shù)。

keys命令的時間復(fù)雜度為O(n)，而scan命令會將遍歷操作分解成m次時間復(fù)雜度為O(1)的操作來執(zhí)行，從而解決使用keys命令遍歷大量數(shù)據(jù)而導(dǎo)致服務(wù)器阻塞的情況。

10. redis過期刪除策略

• 定時刪除：在設(shè)置鍵的過期時間的時候創(chuàng)建一個定時器，當(dāng)過期時間到的時候立馬執(zhí)行刪除操作。對CPU不是很友好。
• 惰性刪除：惰性刪除不會在鍵過期的時候立馬刪除，而是當(dāng)外部命令獲取這個鍵的時候才會主動刪除。過程為：接收get執(zhí)行、判斷是否過期、執(zhí)行刪除操作、返回nil。
• 定期刪除：每隔一段時間檢測是否有過期鍵，如果有執(zhí)行刪除操作。

11. 一致性hash算法

hash算法依賴于現(xiàn)有的機器數(shù)目，導(dǎo)致所有的位置都要發(fā)生變動。一致性hash算法是采用與2^32取模，形成一個虛擬的圓環(huán)，當(dāng)機器數(shù)目發(fā)生變動的時候，只有少量的位置變動。由于可能存在數(shù)據(jù)傾斜問題，引入虛擬節(jié)點來使數(shù)據(jù)分布均勻，只是多了虛擬節(jié)點到實際節(jié)點的映射。

12. 使用場景？

• 緩存
• 計數(shù)（String）
• 消息隊列（list）
• 求共同部分（set）
• 估算訪問量（hyperloglog）
• 過濾請求（bitmap）
• 排行榜（sorted set）
• session服務(wù)器