什么是 Redis ？

Redis ，全稱 Remote Dictionary Server ，是一個(gè)基于內(nèi)存的高性能 Key-Value 數(shù)據(jù)庫(kù)。

另外，Redis 已經(jīng)成為互聯(lián)網(wǎng)公司在緩存組件選擇的唯一，更多的關(guān)注點(diǎn)是，如何使用好 Redis 。

Redis 有什么優(yōu)點(diǎn)？

🦅 1. 速度快

因?yàn)閿?shù)據(jù)存在內(nèi)存中，類似于 HashMap ，HashMap 的優(yōu)勢(shì)就是查找和操作的時(shí)間復(fù)雜度都是O (1) 。

Redis 本質(zhì)上是一個(gè) Key-Value 類型的內(nèi)存數(shù)據(jù)庫(kù)，很像Memcached ，整個(gè)數(shù)據(jù)庫(kù)統(tǒng)統(tǒng)加載在內(nèi)存當(dāng)中進(jìn)行操作，定期通過異步操作把數(shù)據(jù)庫(kù)數(shù)據(jù) flush 到硬盤上進(jìn)行保存。

因?yàn)槭羌儍?nèi)存操作，Redis 的性能非常出色，每秒可以處理超過 10 萬次讀寫操作，是已知性能最快的 Key-Value 數(shù)據(jù)庫(kù)。

• 如果我們查看在阿里云銷售的 Redis 規(guī)格，最低的也是 8W QPS 。

🦅 2. 支持豐富數(shù)據(jù)類型

支持 String ，List，Set，Sorted Set，Hash 。

Redis 的出色之處不僅僅是性能，Redis 最大的魅力是支持保存多種數(shù)據(jù)結(jié)構(gòu)，此外單個(gè) Value 的最大限制是1GB，不像 Memcached只能保存1MB的數(shù)據(jù)，因此Redis可以用來實(shí)現(xiàn)很多有用的功能。比方說：

• 用他的 List 來做 FIFO 雙向鏈表，實(shí)現(xiàn)一個(gè)輕量級(jí)的高性能消息隊(duì)列服務(wù)。

• 用他的 Set 可以做高性能的 tag 系統(tǒng)等等。

🦅 3. 豐富的特性

• 訂閱發(fā)布 Pub / Sub 功能

• Key 過期策略

• 事務(wù)

• 支持多個(gè) DB

• 計(jì)數(shù)

• …

并且在 Redis 5.0 增加了 Stream 功能，一個(gè)新的強(qiáng)大的支持多播的可持久化的消息隊(duì)列，提供類似 Kafka 的功能。

🦅 4. 持久化存儲(chǔ)

Redis 提供 RDB 和 AOF 兩種數(shù)據(jù)的持久化存儲(chǔ)方案，解決內(nèi)存數(shù)據(jù)庫(kù)最擔(dān)心的萬一 Redis 掛掉，數(shù)據(jù)會(huì)消失掉。

Redis 有什么缺點(diǎn)？

• 1、由于 Redis 是內(nèi)存數(shù)據(jù)庫(kù)，所以，單臺(tái)機(jī)器，存儲(chǔ)的數(shù)據(jù)量，跟機(jī)器本身的內(nèi)存大小。雖然 Redis 本身有 Key 過期策略，但是還是需要提前預(yù)估和節(jié)約內(nèi)存。如果內(nèi)存增長(zhǎng)過快，需要定期刪除數(shù)據(jù)。

  另外，可使用 Redis Cluster、Codis 等方案，對(duì) Redis 進(jìn)行分區(qū)，從單機(jī) Redis 變成集群 Redis 。

• 2、如果進(jìn)行完整重同步，由于需要生成 RDB 文件，并進(jìn)行傳輸，會(huì)占用主機(jī)的 CPU ，并會(huì)消耗現(xiàn)網(wǎng)的帶寬。不過 Redis2.8 版本，已經(jīng)有部分重同步的功能，但是還是有可能有完整重同步的。比如，新上線的備機(jī)。

• 3、修改配置文件，進(jìn)行重啟，將硬盤中的數(shù)據(jù)加載進(jìn)內(nèi)存，時(shí)間比較久。在這個(gè)過程中，Redis 不能提供服務(wù)。

Redis 和 Memcached 的區(qū)別有哪些？

🦅 1. Redis 支持復(fù)雜的數(shù)據(jù)結(jié)構(gòu)

• Memcached 僅提供簡(jiǎn)單的字符串。

• Redis 提供復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，豐富的數(shù)據(jù)操作。

也因?yàn)?Redis 支持復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，Redis 即使往于 Memcached 推出，卻獲得更多開發(fā)者的青睞。

Redis 相比 Memcached 來說，擁有更多的數(shù)據(jù)結(jié)構(gòu)，能支持更豐富的數(shù)據(jù)操作。如果需要緩存能夠支持更復(fù)雜的結(jié)構(gòu)和操作，Redis 會(huì)是不錯(cuò)的選擇。

🦅 2. Redis 原生支持集群模式

• 在 Redis3.x 版本中，官方便能支持 Cluster 模式。

• Memcached 沒有原生的集群模式，需要依靠客戶端來實(shí)現(xiàn)往集群中分片寫入數(shù)據(jù)。

🦅 3. 性能對(duì)比

• Redis 只使用單核，而 Memcached 可以使用多核，所以平均每一個(gè)核上 Redis在存儲(chǔ)小數(shù)據(jù)時(shí)比 Memcached 性能更高。

• 在 100k 以上的數(shù)據(jù)中，Memcached 性能要高于 Redis 。雖然 Redis 最近也在存儲(chǔ)大數(shù)據(jù)的性能上進(jìn)行優(yōu)化，但是比起 Memcached，還是稍有遜色。

更多關(guān)于性能的對(duì)比，可以看看 《Memcached 與 Redis 的關(guān)鍵性能指標(biāo)比較》 。

4. 內(nèi)存使用效率對(duì)比

• 簡(jiǎn)單的 Key-Value 存儲(chǔ)的話，Memcached 的內(nèi)存利用率更高，可以使用類似內(nèi)存池。

• 如果 Redis 采用 hash 結(jié)構(gòu)來做 key-value 存儲(chǔ)，由于其組合式的壓縮， 其內(nèi)存利用率會(huì)高于 Memcached 。

另外，Redis 和 Memcached 的內(nèi)存管理方法不同。

• Redis 采用的是包裝的 malloc/free ， 相較于 Memcached 的內(nèi)存管理方法 tcmalloc / jmalloc 來說，要簡(jiǎn)單很多 。

5. 網(wǎng)絡(luò) IO 模型

• Memcached 是多線程，非阻塞 IO 復(fù)用的網(wǎng)絡(luò)模型，原型上接近 Nignx 。

• Redis 使用單線程的 IO 復(fù)用模型，自己封裝了一個(gè)簡(jiǎn)單的 AeEvent 事件處理框架，主要實(shí)現(xiàn)了 epoll, kqueue 和 select ，更接近 Apache 早期的模式。

TODO 有點(diǎn)看不懂，找亞普表弟確認(rèn)中。

6. 持久化存儲(chǔ)

• Memcached 不支持持久化存儲(chǔ)，重啟時(shí)，數(shù)據(jù)被清空。

• Redis 支持持久化存儲(chǔ)，重啟時(shí)，可以恢復(fù)已持久化的數(shù)據(jù)。

也推薦閱讀下 《腳踏兩只船的困惑 - Memcached 與 Redis》 。

請(qǐng)說說 Redis 的線程模型？

：這個(gè)是我從網(wǎng)絡(luò)上找的資料，講的灰常不錯(cuò)。

redis 內(nèi)部使用文件事件處理器 file event handler，這個(gè)文件事件處理器是單線程的，所以 redis 才叫做單線程的模型。它采用 IO 多路復(fù)用機(jī)制同時(shí)監(jiān)聽多個(gè) socket，根據(jù) socket 上的事件來選擇對(duì)應(yīng)的事件處理器進(jìn)行處理。

文件事件處理器的結(jié)構(gòu)包含 4 個(gè)部分：

• 多個(gè) socket

• IO 多路復(fù)用程序

• 文件事件分派器

• 事件處理器（連接應(yīng)答處理器、命令請(qǐng)求處理器、命令回復(fù)處理器）

多個(gè) socket 可能會(huì)并發(fā)產(chǎn)生不同的操作，每個(gè)操作對(duì)應(yīng)不同的文件事件，但是 IO 多路復(fù)用程序會(huì)監(jiān)聽多個(gè) socket，會(huì)將 socket 產(chǎn)生的事件放入隊(duì)列中排隊(duì)，事件分派器每次從隊(duì)列中取出一個(gè)事件，把該事件交給對(duì)應(yīng)的事件處理器進(jìn)行處理。

來看客戶端與 redis 的一次通信過程：

• 客戶端 socket01 向 redis 的 server socket 請(qǐng)求建立連接，此時(shí) server socket 會(huì)產(chǎn)生一個(gè) AE_READABLE 事件，IO 多路復(fù)用程序監(jiān)聽到 server socket 產(chǎn)生的事件后，將該事件壓入隊(duì)列中。文件事件分派器從隊(duì)列中獲取該事件，交給連接應(yīng)答處理器。連接應(yīng)答處理器會(huì)創(chuàng)建一個(gè)能與客戶端通信的 socket01，并將該 socket01 的 AE_READABLE 事件與命令請(qǐng)求處理器關(guān)聯(lián)。

• 假設(shè)此時(shí)客戶端發(fā)送了一個(gè) set key value 請(qǐng)求，此時(shí) redis 中的 socket01 會(huì)產(chǎn)生 AE_READABLE 事件，IO 多路復(fù)用程序?qū)⑹录喝腙?duì)列，此時(shí)事件分派器從隊(duì)列中獲取到該事件，由于前面 socket01 的 AE_READABLE 事件已經(jīng)與命令請(qǐng)求處理器關(guān)聯(lián)，因此事件分派器將事件交給命令請(qǐng)求處理器來處理。命令請(qǐng)求處理器讀取 socket01 的 key value 并在自己內(nèi)存中完成 key value 的設(shè)置。操作完成后，它會(huì)將 socket01 的 AE_WRITABLE 事件與令回復(fù)處理器關(guān)聯(lián)。

• 如果此時(shí)客戶端準(zhǔn)備好接收返回結(jié)果了，那么 redis 中的 socket01 會(huì)產(chǎn)生一個(gè) AE_WRITABLE 事件，同樣壓入隊(duì)列中，事件分派器找到相關(guān)聯(lián)的命令回復(fù)處理器，由命令回復(fù)處理器對(duì) socket01 輸入本次操作的一個(gè)結(jié)果，比如 ok，之后解除 socket01 的 AE_WRITABLE 事件與命令回復(fù)處理器的關(guān)聯(lián)。

這樣便完成了一次通信。😈 耐心理解一下，灰常重要。如果還是不能理解，可以在網(wǎng)絡(luò)上搜一些資料，在理解理解。

為什么 Redis 單線程模型也能效率這么高？

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

  Redis 為了達(dá)到最快的讀寫速度，將數(shù)據(jù)都讀到內(nèi)存中，并通過異步的方式將數(shù)據(jù)寫入磁盤。所以 Redis 具有快速和數(shù)據(jù)持久化的特征。

  如果不將數(shù)據(jù)放在內(nèi)存中，磁盤 I/O 速度為嚴(yán)重影響 Redis 的性能。

• 2、核心是基于非阻塞的 IO 多路復(fù)用機(jī)制。

• 3、單線程反而避免了多線程的頻繁上下文切換問題。

  Redis 利用隊(duì)列技術(shù)，將并發(fā)訪問變?yōu)榇性L問，消除了傳統(tǒng)數(shù)據(jù)庫(kù)串行控制的開銷

• 4、Redis 全程使用 hash 結(jié)構(gòu)，讀取速度快，還有一些特殊的數(shù)據(jù)結(jié)構(gòu)，對(duì)數(shù)據(jù)存儲(chǔ)進(jìn)行了優(yōu)化，如壓縮表，對(duì)短數(shù)據(jù)進(jìn)行壓縮存儲(chǔ)，再如，跳表，使用有序的數(shù)據(jù)結(jié)構(gòu)加快讀取的速度。

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

可以在同一個(gè)服務(wù)器部署多個(gè) Redis 的實(shí)例，并把他們當(dāng)作不同的服務(wù)器來使用，在某些時(shí)候，無論如何一個(gè)服務(wù)器是不夠的， 所以，如果你想使用多個(gè) CPU ，你可以考慮一下分區(qū)。

Redis 有幾種持久化方式？

：這個(gè)問題有一丟丟長(zhǎng)，耐心看完。

面試的時(shí)候，如果不能完整回答出來，也不會(huì)有大問題。重點(diǎn)，在于有條理，對(duì) RDB 和 AOF 有理解。

🦅 持久化方式

Redis 提供了兩種方式，實(shí)現(xiàn)數(shù)據(jù)的持久化到硬盤。

• 1、【全量】RDB 持久化，是指在指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤。實(shí)際操作過程是，fork 一個(gè)子進(jìn)程，先將數(shù)據(jù)集寫入臨時(shí)文件，寫入成功后，再替換之前的文件，用二進(jìn)制壓縮存儲(chǔ)。

• 2、【增量】AOF持久化，以日志的形式記錄服務(wù)器所處理的每一個(gè)寫、刪除操作，查詢操作不會(huì)記錄，以文本的方式記錄，可以打開文件看到詳細(xì)的操作記錄。

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

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

• 靈活設(shè)置備份頻率和周期。你可能打算每個(gè)小時(shí)歸檔一次最近 24 小時(shí)的數(shù)據(jù)，同時(shí)還要每天歸檔一次最近 30 天的數(shù)據(jù)。通過這樣的備份策略，一旦系統(tǒng)出現(xiàn)災(zāi)難性故障，我們可以非常容易的進(jìn)行恢復(fù)。

• 非常適合冷備份，對(duì)于災(zāi)難恢復(fù)而言，RDB 是非常不錯(cuò)的選擇。因?yàn)槲覀兛梢苑浅］p松的將一個(gè)單獨(dú)的文件壓縮后再轉(zhuǎn)移到其它存儲(chǔ)介質(zhì)上。推薦，可以將這種完整的數(shù)據(jù)文件發(fā)送到一些遠(yuǎn)程的安全存儲(chǔ)上去，比如說 Amazon 的 S3 云服務(wù)上去，在國(guó)內(nèi)可以是阿里云的 OSS 分布式存儲(chǔ)上。

• 性能最大化。對(duì)于 Redis 的服務(wù)進(jìn)程而言，在開始持久化時(shí)，它唯一需要做的只是 fork 出子進(jìn)程，之后再由子進(jìn)程完成這些持久化的工作，這樣就可以極大的避免服務(wù)進(jìn)程執(zhí)行 IO 操作了。也就是說，RDB 對(duì) Redis 對(duì)外提供的讀寫服務(wù)，影響非常小，可以讓 Redis 保持高性能。

• 恢復(fù)更快。相比于 AOF 機(jī)制，RDB 的恢復(fù)速度更更快，更適合恢復(fù)數(shù)據(jù)，特別是在數(shù)據(jù)集非常大的情況。

② 缺點(diǎn)

• 如果你想保證數(shù)據(jù)的高可用性，即最大限度的避免數(shù)據(jù)丟失，那么 RDB 將不是一個(gè)很好的選擇。因?yàn)橄到y(tǒng)一旦在定時(shí)持久化之前出現(xiàn)宕機(jī)現(xiàn)象，此前沒有來得及寫入磁盤的數(shù)據(jù)都將丟失。

  所以，RDB 實(shí)際場(chǎng)景下，需要和 AOF 一起使用。

• 由于 RDB 是通過 fork 子進(jìn)程來協(xié)助完成數(shù)據(jù)持久化工作的，因此，如果當(dāng)數(shù)據(jù)集較大時(shí)，可能會(huì)導(dǎo)致整個(gè)服務(wù)器停止服務(wù)幾百毫秒，甚至是 1 秒鐘。

  所以，RDB 建議在業(yè)務(wù)低估，例如在半夜執(zhí)行。

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

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

• 該機(jī)制可以帶來更高的

  數(shù)據(jù)安全性

  ，即數(shù)據(jù)持久性。Redis 中提供了 3 種同步策略，即每秒同步、每修改(執(zhí)行一個(gè)命令)同步和不同步。

  • 事實(shí)上，每秒同步也是異步完成的，其效率也是非常高的，所差的是一旦系統(tǒng)出現(xiàn)宕機(jī)現(xiàn)象，那么這一秒鐘之內(nèi)修改的數(shù)據(jù)將會(huì)丟失。

  • 而每修改同步，我們可以將其視為同步持久化，即每次發(fā)生的數(shù)據(jù)變化都會(huì)被立即記錄到磁盤中。可以預(yù)見，這種方式在效率上是最低的。

  • 至于無同步，無需多言，我想大家都能正確的理解它。

• 由于該機(jī)制對(duì)日志文件的寫入操作采用的是append模式，因此在寫入過程中即使出現(xiàn)宕機(jī)現(xiàn)象，也不會(huì)破壞日志文件中已經(jīng)存在的內(nèi)容。

  • 因?yàn)橐?append-only 模式寫入，所以沒有任何磁盤尋址的開銷，寫入性能非常高。

  • 另外，如果我們本次操作只是寫入了一半數(shù)據(jù)就出現(xiàn)了系統(tǒng)崩潰問題，不用擔(dān)心，在 Redis 下一次啟動(dòng)之前，我們可以通過 redis-check-aof 工具來幫助我們解決數(shù)據(jù)一致性的問題。

• 如果日志過大，Redis可以自動(dòng)啟用 rewrite 機(jī)制。即使出現(xiàn)后臺(tái)重寫操作，也不會(huì)影響客戶端的讀寫。因?yàn)樵?rewrite log 的時(shí)候，會(huì)對(duì)其中的指令進(jìn)行壓縮，創(chuàng)建出一份需要恢復(fù)數(shù)據(jù)的最小日志出來。再創(chuàng)建新日志文件的時(shí)候，老的日志文件還是照常寫入。當(dāng)新的 merge 后的日志文件 ready 的時(shí)候，再交換新老日志文件即可。

• AOF 包含一個(gè)格式清晰、易于理解的日志文件用于記錄所有的修改操作。事實(shí)上，我們也可以通過該文件完成數(shù)據(jù)的重建。

② 缺點(diǎn)

• 對(duì)于相同數(shù)量的數(shù)據(jù)集而言，AOF 文件通常要大于 RDB 文件。RDB 在恢復(fù)大數(shù)據(jù)集時(shí)的速度比 AOF 的恢復(fù)速度要快。

• 根據(jù)同步策略的不同，AOF 在運(yùn)行效率上往往會(huì)慢于 RDB 。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和 RDB 一樣高效。

• 以前 AOF 發(fā)生過 bug ，就是通過 AOF 記錄的日志，進(jìn)行數(shù)據(jù)恢復(fù)的時(shí)候，沒有恢復(fù)一模一樣的數(shù)據(jù)出來。所以說，類似 AOF 這種較為復(fù)雜的基于命令日志/merge/回放的方式，比基于 RDB 每次持久化一份完整的數(shù)據(jù)快照文件的方式，更加脆弱一些，容易有 bug 。不過 AOF 就是為了避免 rewrite 過程導(dǎo)致的 bug ，因此每次 rewrite 并不是基于舊的指令日志進(jìn)行 merge 的，而是基于當(dāng)時(shí)內(nèi)存中的數(shù)據(jù)進(jìn)行指令的重新構(gòu)建，這樣健壯性會(huì)好很多。

🦅 如何選擇

• 不要僅僅使用 RDB，因?yàn)槟菢訒?huì)導(dǎo)致你丟失很多數(shù)據(jù)

• 也不要僅僅使用 AOF，因?yàn)槟菢佑袃蓚€(gè)問題，第一，你通過 AOF 做冷備，沒有 RDB 做冷備，來的恢復(fù)速度更快; 第二，RDB 每次簡(jiǎn)單粗暴生成數(shù)據(jù)快照，更加健壯，可以避免 AOF 這種復(fù)雜的備份和恢復(fù)機(jī)制的 bug 。

• Redis 支持同時(shí)開啟開啟兩種持久化方式，我們可以綜合使用 AOF 和 RDB 兩種持久化機(jī)制，用 AOF 來保證數(shù)據(jù)不丟失，作為數(shù)據(jù)恢復(fù)的第一選擇; 用 RDB 來做不同程度的冷備，在 AOF 文件都丟失或損壞不可用的時(shí)候，還可以使用 RDB 來進(jìn)行快速的數(shù)據(jù)恢復(fù)。

  • 如果同時(shí)使用 RDB 和 AOF 兩種持久化機(jī)制，那么在 Redis 重啟的時(shí)候，會(huì)使用 AOF 來重新構(gòu)建數(shù)據(jù)，因?yàn)?AOF 中的數(shù)據(jù)更加完整。

    一般來說， 如果想達(dá)到足以媲美 PostgreSQL 的數(shù)據(jù)安全性， 你應(yīng)該同時(shí)使用兩種持久化功能。如果你非常關(guān)心你的數(shù)據(jù)， 但仍然可以承受數(shù)分鐘以內(nèi)的數(shù)據(jù)丟失，那么你可以只使用 RDB 持久化。

    有很多用戶都只使用 AOF 持久化，但并不推薦這種方式：因?yàn)槎〞r(shí)生成 RDB 快照（snapshot）非常便于進(jìn)行數(shù)據(jù)庫(kù)備份， 并且 RDB 恢復(fù)數(shù)據(jù)集的速度也要比AOF恢復(fù)的速度要快，除此之外，使用 RDB 還可以避免之前提到的 AOF 程序的 bug。

在 Redis4.0 版本開始，允許你使用 RDB-AOF 混合持久化方式，詳細(xì)可見 《Redis4.0 之 RDB-AOF 混合持久化》 。也因此，RDB 和 AOF 同時(shí)使用，是希望達(dá)到安全的持久化的推薦方式。

---

另外，RDB 和 AOF 涉及的知識(shí)點(diǎn)蠻多的，可以看看：

• 《Redis 設(shè)計(jì)與實(shí)現(xiàn) —— RDB》

• 《Redis 設(shè)計(jì)與實(shí)現(xiàn) —— AOF》

如下是老錢對(duì)這塊的總結(jié)，可能更加適合面試的場(chǎng)景：

• bgsave 做鏡像全量持久化，AOF 做增量持久化。因?yàn)?bgsave 會(huì)耗費(fèi)較長(zhǎng)時(shí)間，不夠?qū)崟r(shí)，在停機(jī)的時(shí)候會(huì)導(dǎo)致大量丟失數(shù)據(jù)，所以需要 AOF 來配合使用。在 Redis 實(shí)例重啟時(shí)，會(huì)使用 bgsave 持久化文件重新構(gòu)建內(nèi)存，再使用 AOF 重放近期的操作指令來實(shí)現(xiàn)完整恢復(fù)重啟之前的狀態(tài)。

• 對(duì)方追問那如果突然機(jī)器掉電會(huì)怎樣？取決于 AOF 日志 sync 屬性的配置，如果不要求性能，在每條寫指令時(shí)都 sync 一下磁盤，就不會(huì)丟失數(shù)據(jù)。但是在高性能的要求下每次都 sync 是不現(xiàn)實(shí)的，一般都使用定時(shí) sync ，比如 1 秒 1 次，這個(gè)時(shí)候最多就會(huì)丟失 1 秒的數(shù)據(jù)。

• 對(duì)方追問 bgsave 的原理是什么？你給出兩個(gè)詞匯就可以了，fork 和 cow 。fork 是指 Redis 通過創(chuàng)建子進(jìn)程來進(jìn)行 bgsave 操作。cow 指的是 copy on write ，子進(jìn)程創(chuàng)建后，父子進(jìn)程共享數(shù)據(jù)段，父進(jìn)程繼續(xù)提供讀寫服務(wù)，寫臟的頁(yè)面數(shù)據(jù)會(huì)逐漸和子進(jìn)程分離開來。

  ：這里 bgsave 操作后，會(huì)產(chǎn)生 RDB 快照文件。

TODO 和曉峰溝通下，使用哪個(gè)策略。

TODO 來自飛哥，主 aof ，從 rdb + aof

Redis 有幾種數(shù)據(jù)“過期”策略？

Redis 的過期策略，就是指當(dāng) Redis 中緩存的 key 過期了，Redis 如何處理。

Redis 提供了 3 種數(shù)據(jù)過期策略：

• 被動(dòng)刪除：當(dāng)讀/寫一個(gè)已經(jīng)過期的 key 時(shí)，會(huì)觸發(fā)惰性刪除策略，直接刪除掉這個(gè)過期 key 。

• 主動(dòng)刪除：由于惰性刪除策略無法保證冷數(shù)據(jù)被及時(shí)刪掉，所以 Redis 會(huì)定期主動(dòng)淘汰一批已過期的 key 。

• 主動(dòng)刪除：當(dāng)前已用內(nèi)存超過 maxmemory 限定時(shí)，觸發(fā)主動(dòng)清理策略，即 「數(shù)據(jù)“淘汰”策略」 。

在 Redis 中，同時(shí)使用了上述 3 種策略，即它們非互斥的。

想要進(jìn)一步了解，可以看看 《關(guān)于 Redis 數(shù)據(jù)過期策略》 文章。

Redis 有哪幾種數(shù)據(jù)“淘汰”策略？

Redis 內(nèi)存數(shù)據(jù)集大小上升到一定大小的時(shí)候，就會(huì)進(jìn)行數(shù)據(jù)淘汰策略。

Redis 提供了 6 種數(shù)據(jù)淘汰策略：

volatile-lru

volatile-ttl

volatile-random

allkeys-lru

allkeys-random

no-enviction

具體的每種數(shù)據(jù)淘汰策略的定義，和如何選擇討論策略，可見 《Redis實(shí)戰(zhàn)（二） 內(nèi)存淘汰機(jī)制》 。

🦅 Redis LRU 算法

另外，Redis 的 LRU 算法，并不是一個(gè)嚴(yán)格的 LRU 實(shí)現(xiàn)。這意味著 Redis 不能選擇最佳候選鍵來回收，也就是最久未被訪問的那些鍵。相反，Redis 會(huì)嘗試執(zhí)行一個(gè)近似的 LRU 算法，通過采樣一小部分鍵，然后在采樣鍵中回收最適合(擁有最久未被訪問時(shí)間)的那個(gè)。

• 具體的可以看看 《使用 Redis 作為一個(gè) LRU 緩存》 文章。

🦅 MySQL 里有 2000w 數(shù)據(jù)，Redis 中只存 20w 的數(shù)據(jù)，如何保證 Redis 中的數(shù)據(jù)都是熱點(diǎn)數(shù)據(jù)？

：這個(gè)是從網(wǎng)絡(luò)上找到的一個(gè)神奇的問題，并且看了答案之后，覺得有點(diǎn)莫名的對(duì)不上。

所以，感覺這個(gè)問題的目的是，如何保證熱點(diǎn)數(shù)據(jù)不要被淘汰。

在 「Redis 有哪幾種數(shù)據(jù)“淘汰”策略？」 問題中，我們已經(jīng)看到，“Redis 內(nèi)存數(shù)據(jù)集大小上升到一定大小的時(shí)候，就會(huì)進(jìn)行數(shù)據(jù)淘汰策略。” 。

那么，如果我們此時(shí)要保證熱點(diǎn)數(shù)據(jù)不被淘汰，那么需要選擇 volatile-lru 或 allkeys-lru 這兩個(gè)基于 LRU 算法的淘汰策略。

相比較來說，最終會(huì)選擇 allkeys-lru 淘汰策略。原因是，如果我們的應(yīng)用對(duì)緩存的訪問符合冪律分布，也就是存在相對(duì)熱點(diǎn)數(shù)據(jù)，或者我們不太清楚我們應(yīng)用的緩存訪問分布狀況，我們可以選擇 allkeys-lru 策略。

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

理解回收進(jìn)程如何工作是非常重要的：

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

• Redis 檢查內(nèi)存使用情況，如果大于 maxmemory 的限制, 則根據(jù)設(shè)定好的策略進(jìn)行回收。

• Redis 執(zhí)行新命令……

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

如果有大量的 key 需要設(shè)置同一時(shí)間過期，一般需要注意什么？

如果大量的 key 過期時(shí)間設(shè)置的過于集中，到過期的那個(gè)時(shí)間點(diǎn)，Redis可能會(huì)出現(xiàn)短暫的卡頓現(xiàn)象。

一般需要在時(shí)間上加一個(gè)隨機(jī)值，使得過期時(shí)間分散一些。

---

上次基友也碰到這個(gè)問題，請(qǐng)教了下，他的方案是調(diào)大 hz 參數(shù)，每次過期的 key 更多，從而最終達(dá)到避免一次過期過多。

這個(gè)定期的頻率，由配置文件中的 hz 參數(shù)決定，代表了一秒鐘內(nèi)，后臺(tái)任務(wù)期望被調(diào)用的次數(shù)。Redis3.0.0 中的默認(rèn)值是 10 ，代表每秒鐘調(diào)用 10 次后臺(tái)任務(wù)。

hz 調(diào)大將會(huì)提高 Redis 主動(dòng)淘汰的頻率，如果你的 Redis 存儲(chǔ)中包含很多冷數(shù)據(jù)占用內(nèi)存過大的話，可以考慮將這個(gè)值調(diào)大，但 Redis 作者建議這個(gè)值不要超過 100 。我們實(shí)際線上將這個(gè)值調(diào)大到 100 ，觀察到 CPU 會(huì)增加 2% 左右，但對(duì)冷數(shù)據(jù)的內(nèi)存釋放速度確實(shí)有明顯的提高（通過觀察 keyspace 個(gè)數(shù)和 used_memory 大小）。

Redis 有哪些數(shù)據(jù)結(jié)構(gòu)？

如果你是 Redis 普通玩家，可能你的回答是如下五種數(shù)據(jù)結(jié)構(gòu)：

• 字符串 String

• 字典Hash

• 列表List

• 集合Set

• 有序集合 SortedSet

如果你是 Redis 中級(jí)玩家，還需要加上下面幾種數(shù)據(jù)結(jié)構(gòu)：

• HyperLogLog

• Geo

• Pub / Sub

如果你是 Redis 高端玩家，你可能玩過 Redis Module ，可以再加上下面幾種數(shù)據(jù)結(jié)構(gòu)：

• BloomFilter

• RedisSearch

• Redis-ML

• JSON

另外，在 Redis 5.0 增加了 Stream 功能，一個(gè)新的強(qiáng)大的支持多播的可持久化的消息隊(duì)列，提供類似 Kafka 的功能。😈 默默跟面試官在裝一波。

聊聊 Redis 使用場(chǎng)景

Redis 可用的場(chǎng)景非常之多：

• 數(shù)據(jù)緩存

• 會(huì)話緩存

• 時(shí)效性數(shù)據(jù)

• 訪問頻率

• 計(jì)數(shù)器

• 社交列表

• 記錄用戶判定信息

• 交集、并集和差集

• 熱門列表與排行榜

• 最新動(dòng)態(tài)

• 消息隊(duì)列

• 分布式鎖

詳細(xì)的介紹，可以看看如下文章：

• 《聊聊 Redis 使用場(chǎng)景》

• 《Redis 應(yīng)用場(chǎng)景及實(shí)例》

• 《Redis 常見的應(yīng)用場(chǎng)景解析》

• 《Redis 和 Memcached 各有什么優(yōu)缺點(diǎn)，主要的應(yīng)用場(chǎng)景是什么樣的？》

🦅 請(qǐng)用 Redis 和任意語言實(shí)現(xiàn)一段惡意登錄保護(hù)的代碼，限制 1 小時(shí)內(nèi)每用戶 Id 最多只能登錄 5 次。

用列表實(shí)現(xiàn)，列表中每個(gè)元素代表登陸時(shí)間，只要最后的第 5 次登陸時(shí)間和現(xiàn)在時(shí)間差不超過 1 小時(shí)就禁止登陸。

具體的代碼實(shí)現(xiàn)，可以看看 《一道 Redis 面試題》 。

Redis 支持的 Java 客戶端都有哪些？

使用比較廣泛的有三個(gè) Java 客戶端：

• Redisson

  Redisson ，是一個(gè)高級(jí)的分布式協(xié)調(diào) Redis 客服端，能幫助用戶在分布式環(huán)境中輕松實(shí)現(xiàn)一些 Java 的對(duì)象 (Bloom filter, BitSet, Set, SetMultimap, ScoredSortedSet, SortedSet, Map, ConcurrentMap, List, ListMultimap, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, ReadWriteLock, AtomicLong, CountDownLatch, Publish / Subscribe, HyperLogLog)。

• Jedis

  Jedis 是 Redis 的 Java 實(shí)現(xiàn)的客戶端，其 API 提供了比較全面的 Redis 命令的支持。

  Redisson 實(shí)現(xiàn)了分布式和可擴(kuò)展的 Java 數(shù)據(jù)結(jié)構(gòu)，和 Jedis 相比，Jedis 功能較為簡(jiǎn)單，不支持字符串操作，不支持排序、事務(wù)、管道、分區(qū)等 Redis 特性。

  Redisson 的宗旨是促進(jìn)使用者對(duì) Redis 的關(guān)注分離，從而讓使用者能夠?qū)⒕Ω械胤旁谔幚順I(yè)務(wù)邏輯上。

• Lettuce

  Lettuc e是一個(gè)可伸縮線程安全的 Redis 客戶端。多個(gè)線程可以共享同一個(gè) RedisConnection 。它利用優(yōu)秀 Netty NIO 框架來高效地管理多個(gè)連接。

Redis 官方推薦使用 Redisson 或 Jedis 。Spring Boot 2.x 內(nèi)置使用 Lettuce 。

如何使用 Redis 實(shí)現(xiàn)分布式鎖？

🦅 方案一：set 指令

先拿 setnx 來爭(zhēng)搶鎖，搶到之后，再用 expire 給鎖加一個(gè)過期時(shí)間防止鎖忘記了釋放。

• 這時(shí)候?qū)Ψ綍?huì)告訴你說你回答得不錯(cuò)，然后接著問如果在 setnx 之后執(zhí)行 expire 之前進(jìn)程意外 crash 或者要重啟維護(hù)了，那會(huì)怎么樣？

• 這時(shí)候你要給予驚訝的反饋：唉，是喔，這個(gè)鎖就永遠(yuǎn)得不到釋放了。緊接著你需要抓一抓自己得腦袋，故作思考片刻，好像接下來的結(jié)果是你主動(dòng)思考出來的，然后回答：我記得 set 指令有非常復(fù)雜的參數(shù)，這個(gè)應(yīng)該是可以同時(shí)把 setnx 和 expire 合成一條指令來用的！對(duì)方這時(shí)會(huì)顯露笑容，心里開始默念：摁，這小子還不錯(cuò)。

所以，我們可以使用 set 指令，實(shí)現(xiàn)分布式鎖。指令如下：

SET key value [EX seconds] [PX milliseconds] [NX|XX]

• 可以使用 SET key value EX seconds NX 命令，嘗試獲得鎖。

• 具體的實(shí)現(xiàn)，可以參考 《Redis 分布式鎖的正確實(shí)現(xiàn)方式（Java版）》 文章。

🦅 方案二：redlock

set 指令的方案，適合用于在單機(jī) Redis 節(jié)點(diǎn)的場(chǎng)景下，在多 Redis 節(jié)點(diǎn)的場(chǎng)景下，會(huì)存在分布式鎖丟失的問題。所以，Redis 作者 Antirez 基于分布式環(huán)境下提出了一種更高級(jí)的分布式鎖的實(shí)現(xiàn)方式：Redlock 。

具體的方案，同學(xué)們可以看看老友飛哥的兩篇博客：

• 《Redlock：Redis分布式鎖最牛逼的實(shí)現(xiàn)》

• 《Redisson 實(shí)現(xiàn) Redis 分布式鎖的 N 種姿勢(shì)》

🦅 對(duì)比 Zookeeper 分布式鎖

• 從可靠性上來說，Zookeeper 分布式鎖好于 Redis 分布式鎖。

• 從性能上來說，Redis 分布式鎖好于 Zookeeper 分布式鎖。

所以，沒有絕對(duì)的好壞，可以根據(jù)自己的業(yè)務(wù)來具體選擇。

如何使用 Redis 實(shí)現(xiàn)分布式限流？

在 Spring Cloud Gateway 中，提供了 Redis 分布式限流器的實(shí)現(xiàn)，具體直接看寫的 《Spring-Cloud-Gateway 源碼解析 —— 過濾器 (4.10) 之 RequestRateLimiterGatewayFilterFactory 請(qǐng)求限流》 的 「5.3 Redis Lua 腳本」 部分。

另外，Redisson 庫(kù)中，也提供了 Redis 分布式限流的實(shí)現(xiàn)，不過需要使用 Pro 版本。

如何使用 Redis 實(shí)現(xiàn)消息隊(duì)列？

一般使用 list 結(jié)構(gòu)作為隊(duì)列，rpush 生產(chǎn)消息，lpop 消費(fèi)消息。當(dāng) lpop 沒有消息的時(shí)候，要適當(dāng) sleep 一會(huì)再重試。

• 如果對(duì)方追問可不可以不用 sleep 呢？list 還有個(gè)指令叫 blpop ，在沒有消息的時(shí)候，它會(huì)阻塞住直到消息到來。

• 如果對(duì)方追問能不能生產(chǎn)一次消費(fèi)多次呢？使用 pub / sub 主題訂閱者模式，可以實(shí)現(xiàn) 1:N 的消息隊(duì)列。

• 如果對(duì)方追問 pub / sub 有什么缺點(diǎn)？在消費(fèi)者下線的情況下，生產(chǎn)的消息會(huì)丟失，得使用專業(yè)的消息隊(duì)列如 rabbitmq 等。

• 如果對(duì)方追問 redis 如何實(shí)現(xiàn)延時(shí)隊(duì)列？我估計(jì)現(xiàn)在你很想把面試官一棒打死如果你手上有一根棒球棍的話，怎么問的這么詳細(xì)。但是你很克制，然后神態(tài)自若的回答道：使用 sortedset ，拿時(shí)間戳作為 score ，消息內(nèi)容作為 key 調(diào)用 zadd 來生產(chǎn)消息，消費(fèi)者用 zrangebyscore 指令獲取 N 秒之前的數(shù)據(jù)輪詢進(jìn)行處理。

到這里，面試官暗地里已經(jīng)對(duì)你豎起了大拇指。但是他不知道的是此刻你卻豎起了中指，在椅子背后。

當(dāng)然，實(shí)際上 Redis 真的真的真的不推薦作為消息隊(duì)列使用，它最多只是消息隊(duì)列的存儲(chǔ)層，上層的邏輯，還需要做大量的封裝和支持。

另外，在 Redis 5.0 增加了 Stream 功能，一個(gè)新的強(qiáng)大的支持多播的可持久化的消息隊(duì)列，提供類似 Kafka 的功能。

什么是 Redis Pipelining ？

一次請(qǐng)求/響應(yīng)服務(wù)器能實(shí)現(xiàn)處理新的請(qǐng)求即使舊的請(qǐng)求還未被響應(yīng)。這樣就可以將多個(gè)命令發(fā)送到服務(wù)器，而不用等待回復(fù)，最后在一個(gè)步驟中讀取該答復(fù)。

這就是管道（pipelining），是一種幾十年來廣泛使用的技術(shù)。例如許多 POP3 協(xié)議已經(jīng)實(shí)現(xiàn)支持這個(gè)功能，大大加快了從服務(wù)器下載新郵件的過程。

Redis 很早就支持管道（pipelining）技術(shù)，因此無論你運(yùn)行的是什么版本，你都可以使用管道（pipelining）操作 Redis。

🦅 Redis 如何做大量數(shù)據(jù)插入？

Redis2.6 開始，Redis-cli 支持一種新的被稱之為 pipe mode 的新模式用于執(zhí)行大量數(shù)據(jù)插入工作。

具體可見 《Redis 大量數(shù)據(jù)插入》 文章。

什么是 Redis 事務(wù)？

和眾多其它數(shù)據(jù)庫(kù)一樣，Redis 作為 NoSQL 數(shù)據(jù)庫(kù)也同樣提供了事務(wù)機(jī)制。在Redis中，MULTI / EXEC / DISCARD / WATCH 這四個(gè)命令是我們實(shí)現(xiàn)事務(wù)的基石。相信對(duì)有關(guān)系型數(shù)據(jù)庫(kù)開發(fā)經(jīng)驗(yàn)的開發(fā)者而言這一概念并不陌生，即便如此，我們還是會(huì)簡(jiǎn)要的列出 Redis 中事務(wù)的實(shí)現(xiàn)特征：

• 1、在事務(wù)中的所有命令都將會(huì)被串行化的順序執(zhí)行，事務(wù)執(zhí)行期間，Redis 不會(huì)再為其它客戶端的請(qǐng)求提供任何服務(wù)，從而保證了事物中的所有命令被原子的執(zhí)行。

• 2、和關(guān)系型數(shù)據(jù)庫(kù)中的事務(wù)相比，在 Redis 事務(wù)中如果有某一條命令執(zhí)行失敗，其后的命令仍然會(huì)被繼續(xù)執(zhí)行。

• 3、我們可以通過 MULTI 命令開啟一個(gè)事務(wù)，有關(guān)系型數(shù)據(jù)庫(kù)開發(fā)經(jīng)驗(yàn)的人可以將其理解為 "BEGIN TRANSACTION" 語句。在該語句之后執(zhí)行的命令都，將被視為事務(wù)之內(nèi)的操作，最后我們可以通過執(zhí)行 EXEC / DISCARD 命令來提交 / 回滾該事務(wù)內(nèi)的所有操作。這兩個(gè) Redis 命令，可被視為等同于關(guān)系型數(shù)據(jù)庫(kù)中的 COMMIT / ROLLBACK 語句。

• 4、在事務(wù)開啟之前，如果客戶端與服務(wù)器之間出現(xiàn)通訊故障并導(dǎo)致網(wǎng)絡(luò)斷開，其后所有待執(zhí)行的語句都將不會(huì)被服務(wù)器執(zhí)行。然而如果網(wǎng)絡(luò)中斷事件是發(fā)生在客戶端執(zhí)行 EXEC 命令之后，那么該事務(wù)中的所有命令都會(huì)被服務(wù)器執(zhí)行。

• 5、當(dāng)使用 Append-Only 模式時(shí)，Redis 會(huì)通過調(diào)用系統(tǒng)函數(shù) write 將該事務(wù)內(nèi)的所有寫操作在本次調(diào)用中全部寫入磁盤。然而如果在寫入的過程中出現(xiàn)系統(tǒng)崩潰，如電源故障導(dǎo)致的宕機(jī)，那么此時(shí)也許只有部分?jǐn)?shù)據(jù)被寫入到磁盤，而另外一部分?jǐn)?shù)據(jù)卻已經(jīng)丟失。

  Redis 服務(wù)器會(huì)在重新啟動(dòng)時(shí)執(zhí)行一系列必要的一致性檢測(cè)，一旦發(fā)現(xiàn)類似問題，就會(huì)立即退出并給出相應(yīng)的錯(cuò)誤提示。此時(shí)，我們就要充分利用 Redis 工具包中提供的 redis-check-aof 工具，該工具可以幫助我們定位到數(shù)據(jù)不一致的錯(cuò)誤，并將已經(jīng)寫入的部分?jǐn)?shù)據(jù)進(jìn)行回滾。修復(fù)之后我們就可以再次重新啟動(dòng)Redis服務(wù)器了。

🦅 如何實(shí)現(xiàn) Redis CAS 操作？

在 Redis 的事務(wù)中，WATCH 命令可用于提供CAS(check-and-set)功能。

假設(shè)我們通過 WATCH 命令在事務(wù)執(zhí)行之前監(jiān)控了多個(gè) keys ，倘若在 WATCH 之后有任何 Key 的值發(fā)生了變化，EXEC 命令執(zhí)行的事務(wù)都將被放棄，同時(shí)返回 nil 應(yīng)答以通知調(diào)用者事務(wù)執(zhí)行失敗。

具體的示例，可以看看 《Redis 事務(wù)鎖 CAS 實(shí)現(xiàn)以及深入誤區(qū)》 。

##

Redis 集群都有哪些方案？

Redis 集群方案如下：

• 1、Redis Sentinel

• 2、Redis Cluster

• 3、Twemproxy

• 4、Codis

• 5、客戶端分片

關(guān)于前四種，可以看看 《Redis 實(shí)戰(zhàn)（四）集群機(jī)制》 這篇文章。

關(guān)于最后一種，客戶端分片，在 Redis Cluster 出現(xiàn)之前使用較多，目前已經(jīng)使用比較少了。實(shí)現(xiàn)方式如下：

在業(yè)務(wù)代碼層實(shí)現(xiàn)，起幾個(gè)毫無關(guān)聯(lián)的 Redis 實(shí)例，在代碼層，對(duì) Key 進(jìn)行 hash 計(jì)算，然后去對(duì)應(yīng)的 Redis 實(shí)例操作數(shù)據(jù)。

這種方式對(duì) hash 層代碼要求比較高，考慮部分包括，節(jié)點(diǎn)失效后的替代算法方案，數(shù)據(jù)震蕩后的自動(dòng)腳本恢復(fù)，實(shí)例的監(jiān)控，等等。

🦅 選擇

目前一般在選型上來說：

• 體量較小時(shí)，選擇 Redis Sentinel ，單主 Redis 足以支撐業(yè)務(wù)。

• 體量較大時(shí)，選擇 Redis Cluster ，通過分片，使用更多內(nèi)存。

🦅 Redis 集群如何擴(kuò)容？

這個(gè)問題，了解的也不是很多，建議在搜索有什么方案。

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

• 如果 Redis 被當(dāng)做一個(gè)持久化存儲(chǔ)使用，必須使用固定的 keys-to-nodes 映射關(guān)系，節(jié)點(diǎn)的數(shù)量一旦確定不能變化。否則的話(即Redis 節(jié)點(diǎn)需要?jiǎng)討B(tài)變化的情況），必須使用可以在運(yùn)行時(shí)進(jìn)行數(shù)據(jù)再平衡的一套系統(tǒng)，而當(dāng)前只有 Redis Cluster、Codis 可以做到這樣。

什么是 Redis 主從同步？

Redis 主從同步

Redis 的主從同步(replication)機(jī)制，允許 Slave 從 Master 那里，通過網(wǎng)絡(luò)傳輸拷貝到完整的數(shù)據(jù)備份，從而達(dá)到主從機(jī)制。

• 主數(shù)據(jù)庫(kù)可以進(jìn)行讀寫操作，當(dāng)發(fā)生寫操作的時(shí)候自動(dòng)將數(shù)據(jù)同步到從數(shù)據(jù)庫(kù)，而從數(shù)據(jù)庫(kù)一般是只讀的，并接收主數(shù)據(jù)庫(kù)同步過來的數(shù)據(jù)。

• 一個(gè)主數(shù)據(jù)庫(kù)可以有多個(gè)從數(shù)據(jù)庫(kù)，而一個(gè)從數(shù)據(jù)庫(kù)只能有一個(gè)主數(shù)據(jù)庫(kù)。

• 第一次同步時(shí)，主節(jié)點(diǎn)做一次 bgsave 操作，并同時(shí)將后續(xù)修改操作記錄到內(nèi)存 buffer ，待完成后將 RDB 文件全量同步到復(fù)制節(jié)點(diǎn)，復(fù)制節(jié)點(diǎn)接受完成后將 RDB 鏡像加載到內(nèi)存。加載完成后，再通知主節(jié)點(diǎn)將期間修改的操作記錄同步到復(fù)制節(jié)點(diǎn)進(jìn)行重放就完成了同步過程。

好處

通過 Redis 的復(fù)制功，能可以很好的實(shí)現(xiàn)數(shù)據(jù)庫(kù)的讀寫分離，提高服務(wù)器的負(fù)載能力。主數(shù)據(jù)庫(kù)主要進(jìn)行寫操作，而從數(shù)據(jù)庫(kù)負(fù)責(zé)讀操作。

---

Redis 主從同步，是很多 Redis 集群方案的基礎(chǔ)，例如 Redis Sentinel、Redis Cluster 等等。

更多詳細(xì)，可以看看 《Redis 主從架構(gòu)》 。

如何使用 Redis Sentinel 實(shí)現(xiàn)高可用？

可以看看 《Redis 哨兵集群實(shí)現(xiàn)高可用》 。

如果使用 Redis Cluster 實(shí)現(xiàn)高可用？

可以看看

• 《Redis 集群教程》 完整版

• 《Redis 集群模式的工作原理能說一下么？》 精簡(jiǎn)版

🦅 說說 Redis 哈希槽的概念？

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

Redis 集群有 16384 個(gè)哈希槽，每個(gè) key 通過 CRC16 校驗(yàn)后對(duì) 16384 取模來決定放置哪個(gè)槽，集群的每個(gè)節(jié)點(diǎn)負(fù)責(zé)一部分 hash 槽。

因?yàn)樽畲笫?16384 個(gè)哈希槽，所以考慮 Redis 集群中的每個(gè)節(jié)點(diǎn)都能分配到一個(gè)哈希槽，所以最多支持 16384 個(gè) Redis 節(jié)點(diǎn)。

🦅 Redis Cluster 的主從復(fù)制模型是怎樣的？

為了使在部分節(jié)點(diǎn)失敗或者大部分節(jié)點(diǎn)無法通信的情況下集群仍然可用，所以集群使用了主從復(fù)制模型，每個(gè)節(jié)點(diǎn)都會(huì)有 N-1 個(gè)復(fù)制節(jié)點(diǎn)。

所以，Redis Cluster 可以說是 Redis Sentinel 帶分片的加強(qiáng)版。也可以說：

• Redis Sentinel 著眼于高可用，在 master 宕機(jī)時(shí)會(huì)自動(dòng)將 slave 提升為 master ，繼續(xù)提供服務(wù)。

• Redis Cluster 著眼于擴(kuò)展性，在單個(gè) Redis 內(nèi)存不足時(shí)，使用Cluster 進(jìn)行分片存儲(chǔ)。

🦅 Redis Cluster 方案什么情況下會(huì)導(dǎo)致整個(gè)集群不可用？

有 A，B，C 三個(gè)節(jié)點(diǎn)的集群，在沒有復(fù)制模型的情況下，如果節(jié)點(diǎn) B 宕機(jī)了，那么整個(gè)集群就會(huì)以為缺少 5501-11000 這個(gè)范圍的槽而不可用。

🦅 Redis Cluster 會(huì)有寫操作丟失嗎？為什么？

Redis 并不能保證數(shù)據(jù)的強(qiáng)一致性，而是【異步復(fù)制】，這意味這在實(shí)際中集群在特定的條件下可能會(huì)丟失寫操作。

🦅 Redis 集群如何選擇數(shù)據(jù)庫(kù)？

Redis 集群目前無法做數(shù)據(jù)庫(kù)選擇，默認(rèn)在 0 數(shù)據(jù)庫(kù)。

🦅 請(qǐng)說說生產(chǎn)環(huán)境中的 Redis 是怎么部署的？

重點(diǎn)問題，仔細(xì)理解。

• Redis Cluster，10 臺(tái)機(jī)器，5 臺(tái)機(jī)器部署了 redis 主實(shí)例，另外 5 臺(tái)機(jī)器部署了 redis 的從實(shí)例，每個(gè)主實(shí)例掛了一個(gè)從實(shí)例，5 個(gè)節(jié)點(diǎn)對(duì)外提供讀寫服務(wù)，每個(gè)節(jié)點(diǎn)的讀寫高峰 qps 可能可以達(dá)到每秒 5 萬，5 臺(tái)機(jī)器最多是 25 萬讀寫請(qǐng)求每秒。

• 機(jī)器是什么配置？32G 內(nèi)存 + 8 核 CPU + 1T 磁盤，但是分配給 Redis 進(jìn)程的是 10g 內(nèi)存，一般線上生產(chǎn)環(huán)境，Redis 的內(nèi)存盡量不要超過 10g，超過 10g 可能會(huì)有問題。那么，5 臺(tái)機(jī)器對(duì)外提供讀寫，一共有 50g 內(nèi)存。

• 因?yàn)槊總€(gè)主實(shí)例都掛了一個(gè)從實(shí)例，所以是高可用的，任何一個(gè)主實(shí)例宕機(jī)，都會(huì)自動(dòng)故障遷移，Redis 從實(shí)例會(huì)自動(dòng)變成主實(shí)例繼續(xù)提供讀寫服務(wù)。

• 你往內(nèi)存里寫的是什么數(shù)據(jù)？每條數(shù)據(jù)的大小是多少？商品數(shù)據(jù)，每條數(shù)據(jù)是 10kb 。100 條數(shù)據(jù)是 1mb ，10 萬條數(shù)據(jù)是 1g 。常駐內(nèi)存的是 200 萬條商品數(shù)據(jù)，占用內(nèi)存是 20g，僅僅不到總內(nèi)存的 50%。目前高峰期每秒就是 3500 左右的請(qǐng)求量。

• 其實(shí)大型的公司，會(huì)有基礎(chǔ)架構(gòu)的 team 負(fù)責(zé)緩存集群的運(yùn)維。

什么是 Redis 分區(qū)？

這個(gè)問題，和 「Redis 集群都有哪些方案？」 是同類問題。

🦅 關(guān)于如下四個(gè)問題，直接看 《Redis 分區(qū)》 文章。

• Redis 分區(qū)是什么？

• 分區(qū)的優(yōu)勢(shì)？

• 分區(qū)的不足？

• 分區(qū)類型？

可能有同學(xué)們會(huì)懵逼，又是 Redis 主從復(fù)制，又是 Redis 分區(qū)，又是 Redis 集群。傻傻分不清啊！

• Redis 分區(qū)是一種模式，將數(shù)據(jù)分區(qū)到不同的 Redis 節(jié)點(diǎn)上，而 Redis 集群的 Redis Cluster、Twemproxy、Codis、客戶端分片( 不包括 Redis Sentinel ) 這四種方案，是 Redis 分區(qū)的具體實(shí)現(xiàn)。

• Redis 每個(gè)分區(qū)，如果想要實(shí)現(xiàn)高可用，需要使用到 Redis 主從復(fù)制。

🦅 你知道有哪些 Redis 分區(qū)實(shí)現(xiàn)方案？

Redis 分區(qū)方案，主要分成兩種類型：

• 客戶端分區(qū)，就是在客戶端就已經(jīng)決定數(shù)據(jù)會(huì)被存儲(chǔ)到哪個(gè) Redis 節(jié)點(diǎn)或者從哪個(gè) Redis 節(jié)點(diǎn)讀取。大多數(shù)客戶端已經(jīng)實(shí)現(xiàn)了客戶端分區(qū)。

  • 案例：Redis Cluster 和客戶端分區(qū)。

• 代理分區(qū)，意味著客戶端將請(qǐng)求發(fā)送給代理，然后代理決定去哪個(gè)節(jié)點(diǎn)寫數(shù)據(jù)或者讀數(shù)據(jù)。代理根據(jù)分區(qū)規(guī)則決定請(qǐng)求哪些 Redis 實(shí)例，然后根據(jù) Redis 的響應(yīng)結(jié)果返回給客戶端。

  • 案例：Twemproxy 和 Codis 。

查詢路由(Query routing)的意思，是客戶端隨機(jī)地請(qǐng)求任意一個(gè) Redis 實(shí)例，然后由 Redis 將請(qǐng)求轉(zhuǎn)發(fā)給正確的 Redis 節(jié)點(diǎn)。Redis Cluster 實(shí)現(xiàn)了一種混合形式的查詢路由，但并不是直接將請(qǐng)求從一個(gè)Redis 節(jié)點(diǎn)轉(zhuǎn)發(fā)到另一個(gè) Redis 節(jié)點(diǎn)，而是在客戶端的幫助下直接 redirect 到正確的 Redis 節(jié)點(diǎn)。

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

如下是網(wǎng)絡(luò)上的一個(gè)大答案：

既然 Redis 是如此的輕量（單實(shí)例只使用1M內(nèi)存），為防止以后的擴(kuò)容，最好的辦法就是一開始就啟動(dòng)較多實(shí)例。即便你只有一臺(tái)服務(wù)器，你也可以一開始就讓 Redis 以分布式的方式運(yùn)行，使用分區(qū)，在同一臺(tái)服務(wù)器上啟動(dòng)多個(gè)實(shí)例。

一開始就多設(shè)置幾個(gè) Redis 實(shí)例，例如 32 或者 64 個(gè)實(shí)例，對(duì)大多數(shù)用戶來說這操作起來可能比較麻煩，但是從長(zhǎng)久來看做這點(diǎn)犧牲是值得的。

這樣的話，當(dāng)你的數(shù)據(jù)不斷增長(zhǎng)，需要更多的 Redis 服務(wù)器時(shí)，你需要做的就是僅僅將 Redis 實(shí)例從一臺(tái)服務(wù)遷移到另外一臺(tái)服務(wù)器而已（而不用考慮重新分區(qū)的問題）。一旦你添加了另一臺(tái)服務(wù)器，你需要將你一半的 Redis 實(shí)例從第一臺(tái)機(jī)器遷移到第二臺(tái)機(jī)器。

• 和飛哥溝通了下，這個(gè)操作不是很合理。

• 無論怎么說，建議，需要搭建下 Redis Sentinel 高可用，至于拓展性，根據(jù)自己的情況，是否使用 Redis Cluster 集群。

Redis 有哪些重要的健康指標(biāo)？

推薦閱讀 《Redis 幾個(gè)重要的健康指標(biāo)》

• 存活情況

• 連接數(shù)

• 阻塞客戶端數(shù)量

• 使用內(nèi)存峰值

• 內(nèi)存碎片率

• 緩存命中率

• OPS

• 持久化

• 失效KEY

• 慢日志

如何提高 Redis 命中率？

推薦閱讀 《如何提高緩存命中率（Redis）》 。

怎么優(yōu)化 Redis 的內(nèi)存占用

推薦閱讀 《Redis 的內(nèi)存優(yōu)化》

• redisObject 對(duì)象

• 縮減鍵值對(duì)象

• 共享對(duì)象池

• 字符串優(yōu)化

• 編碼優(yōu)化

• 控制 key 的數(shù)量

🦅 一個(gè) Redis 實(shí)例最多能存放多少的 keys？List、Set、Sorted Set 他們最多能存放多少元素？

一個(gè) Redis 實(shí)例，最多能存放多少的 keys ，List、Set、Sorted Set 他們最多能存放多少元素。

理論上，Redis 可以處理多達(dá) 2^32 的 keys ，并且在實(shí)際中進(jìn)行了測(cè)試，每個(gè)實(shí)例至少存放了 2 億 5 千萬的 keys。

任何 list、set、和 sorted set 都可以放 2^32 個(gè)元素。

🦅 假如 Redis 里面有 1 億個(gè) key，其中有 10w 個(gè) key 是以某個(gè)固定的已知的前綴開頭的，如果將它們?nèi)空页鰜?#xff1f;

使用 keys 指令可以掃出指定模式的 key 列表。

• 對(duì)方接著追問：如果這個(gè) Redis 正在給線上的業(yè)務(wù)提供服務(wù)，那使用keys指令會(huì)有什么問題？

• 這個(gè)時(shí)候你要回答 Redis 關(guān)鍵的一個(gè)特性：Redis 的單線程的。keys 指令會(huì)導(dǎo)致線程阻塞一段時(shí)間，線上服務(wù)會(huì)停頓，直到指令執(zhí)行完畢，服務(wù)才能恢復(fù)。這個(gè)時(shí)候可以使用 scan 指令，scan 指令可以無阻塞的提取出指定模式的 key 列表，但是會(huì)有一定的重復(fù)概率，在客戶端做一次去重就可以了，但是整體所花費(fèi)的時(shí)間會(huì)比直接用 keys 指令長(zhǎng)。

Redis 常見的性能問題都有哪些？如何解決？

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

  • Master 寫內(nèi)存快照，save 命令調(diào)度 rdbSave 函數(shù)，會(huì)阻塞主線程的工作，當(dāng)快照比較大時(shí)對(duì)性能影響是非常大的，會(huì)間斷性暫停服務(wù)，所以 Master 最好不要寫內(nèi)存快照。

  • Master AOF 持久化，如果不重寫 AOF 文件，這個(gè)持久化方式對(duì)性能的影響是最小的，但是 AOF 文件會(huì)不斷增大，AOF 文件過大會(huì)影響 Master 重啟的恢復(fù)速度。

  • 所以，Master 最好不要做任何持久化工作，包括內(nèi)存快照和 AOF 日志文件，特別是不要啟用內(nèi)存快照做持久化。如果數(shù)據(jù)比較關(guān)鍵，某個(gè) Slave 開啟AOF備份數(shù)據(jù)，策略為每秒同步一次。

• 2、Master 調(diào)用 BGREWRITEAOF 重寫 AOF 文件，AOF 在重寫的時(shí)候會(huì)占大量的 CPU 和內(nèi)存資源，導(dǎo)致服務(wù) load 過高，出現(xiàn)短暫服務(wù)暫停現(xiàn)象。

  • TODO 怎么解決？

• 3、盡量避免在壓力很大的主庫(kù)上增加從庫(kù)。

  • TODO 怎么解決？

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

  Master <- Slave1 <- Slave2 <- Slave3...。

  • 這樣的結(jié)構(gòu)，也方便解決單點(diǎn)故障問題，實(shí)現(xiàn) Slave 對(duì) Master 的替換。如果 Master掛了，可以立刻啟用 Slave1 做 Master ，其他不變。

• 5、Redis 主從復(fù)制的性能問題，為了主從復(fù)制的速度和連接的穩(wěn)定性，Slave 和 Master 最好在同一個(gè)局域網(wǎng)內(nèi)。

---

和飛哥溝通過后，他們主節(jié)點(diǎn)開啟 AOF ，從節(jié)點(diǎn)開啟 AOF + RDB 。

和曉峰溝通后，他們主節(jié)點(diǎn)開啟 AOF ，從節(jié)點(diǎn)開啟 RDB 居多，也有開啟 AOF + RDB 的。

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

針對(duì)運(yùn)行實(shí)例，有許多配置選項(xiàng)可以通過 CONFIG SET 命令進(jìn)行修改，而無需執(zhí)行任何形式的重啟。

從 Redis 2.2 開始，可以從 AOF 切換到 RDB 的快照持久性或其他方式而不需要重啟 Redis。檢索 CONFIG GET * 命令獲取更多信息。

但偶爾重新啟動(dòng)是必須的，如為升級(jí) Redis 程序到新的版本，或者當(dāng)你需要修改某些目前 CONFIG 命令還不支持的配置參數(shù)的時(shí)候。

redis相比memcached有哪些優(yōu)勢(shì)？

memcached所有的值均是簡(jiǎn)單的字符串，redis作為其替代者，支持更為豐富的數(shù)據(jù)類型

redis的速度比memcached快很多

redis可以持久化其數(shù)據(jù)

Memcache與Redis的區(qū)別都有哪些？

存儲(chǔ)方式 Memecache把數(shù)據(jù)全部存在內(nèi)存之中，斷電后會(huì)掛掉，數(shù)據(jù)不能超過內(nèi)存大小。 Redis有部份存在硬盤上，這樣能保證數(shù)據(jù)的持久性。

數(shù)據(jù)支持類型 Memcache對(duì)數(shù)據(jù)類型支持相對(duì)簡(jiǎn)單。 Redis有復(fù)雜的數(shù)據(jù)類型。

使用底層模型不同 它們之間底層實(shí)現(xiàn)方式 以及與客戶端之間通信的應(yīng)用協(xié)議不一樣。 Redis直接自己構(gòu)建了VM 機(jī)制 ，因?yàn)橐话愕南到y(tǒng)調(diào)用系統(tǒng)函數(shù)的話，會(huì)浪費(fèi)一定的時(shí)間去移動(dòng)和請(qǐng)求。

redis常見性能問題和解決方案：

Master寫內(nèi)存快照，save命令調(diào)度rdbSave函數(shù)，會(huì)阻塞主線程的工作，當(dāng)快照比較大時(shí)對(duì)性能影響是非常大的，會(huì)間斷性暫停服務(wù)，所以Master最好不要寫內(nèi)存快照。

Master AOF持久化，如果不重寫AOF文件，這個(gè)持久化方式對(duì)性能的影響是最小的，但是AOF文件會(huì)不斷增大，AOF文件過大會(huì)影響Master重啟的恢復(fù)速度。Master最好不要做任何持久化工作，包括內(nèi)存快照和AOF日志文件，特別是不要啟用內(nèi)存快照做持久化,如果數(shù)據(jù)比較關(guān)鍵，某個(gè)Slave開啟AOF備份數(shù)據(jù)，策略為每秒同步一次。

Master調(diào)用BGREWRITEAOF重寫AOF文件，AOF在重寫的時(shí)候會(huì)占大量的CPU和內(nèi)存資源，導(dǎo)致服務(wù)load過高，出現(xiàn)短暫服務(wù)暫停現(xiàn)象。

Redis主從復(fù)制的性能問題，為了主從復(fù)制的速度和連接的穩(wěn)定性，Slave和Master最好在同一個(gè)局域網(wǎng)內(nèi)

7mySQL里有2000w數(shù)據(jù)，redis中只存20w的數(shù)據(jù)，如何保證redis中的數(shù)據(jù)都是熱點(diǎn)數(shù)據(jù)

相關(guān)知識(shí)：redis 內(nèi)存數(shù)據(jù)集大小上升到一定大小的時(shí)候，就會(huì)施行數(shù)據(jù)淘汰策略（回收策略）。

redis 提供 6種數(shù)據(jù)淘汰策略：

volatile-lru：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中挑選最近最少使用的數(shù)據(jù)淘汰

volatile-ttl：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中挑選將要過期的數(shù)據(jù)淘汰

volatile-random：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中任意選擇數(shù)據(jù)淘汰

allkeys-lru：從數(shù)據(jù)集（server.db[i].dict）中挑選最近最少使用的數(shù)據(jù)淘汰

allkeys-random：從數(shù)據(jù)集（server.db[i].dict）中任意選擇數(shù)據(jù)淘汰

no-enviction（驅(qū)逐）：禁止驅(qū)逐數(shù)據(jù)

請(qǐng)用Redis和任意語言實(shí)現(xiàn)一段惡意登錄保護(hù)的代碼，限制1小時(shí)內(nèi)每用戶Id最多只能登錄5次。具體登錄函數(shù)或功能用空函數(shù)即可，不用詳細(xì)寫出。

用列表實(shí)現(xiàn):列表中每個(gè)元素代表登陸時(shí)間,只要最后的第5次登陸時(shí)間和現(xiàn)在時(shí)間差不超過1小時(shí)就禁止登陸.用Python寫的代碼如下：

#!/usr/bin/env python3 import redis ? import sys ? import time ? ? r = redis.StrictRedis(host=’127.0.0.1′, port=6379, db=0) ? try: ? ? ? id = sys.argv[1] except: ? ? ?print(‘input argument error’) ? ?sys.exit(0) ? if r.llen(id) >= 5 and time.time() – float(r.lindex(id, 4)) <= 3600: ? ? ?print(“you are forbidden logining”) else: ? ? ? print(‘you are allowed to login’) ? ?r.lpush(id, time.time()) ? ?# login_func()

?

為什么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將會(huì)越來越受歡迎。

如果設(shè)置了最大使用的內(nèi)存，則數(shù)據(jù)已有記錄數(shù)達(dá)到內(nèi)存限值后不能繼續(xù)插入新值。

?

Redis是單進(jìn)程單線程的

redis利用隊(duì)列技術(shù)將并發(fā)訪問變?yōu)榇性L問，消除了傳統(tǒng)數(shù)據(jù)庫(kù)串行控制的開銷

?

redis的并發(fā)競(jìng)爭(zhēng)問題如何解決?

Redis為單進(jìn)程單線程模式，采用隊(duì)列模式將并發(fā)訪問變?yōu)榇性L問。Redis本身沒有鎖的概念，Redis對(duì)于多個(gè)客戶端連接并不存在競(jìng)爭(zhēng)，但是在Jedis客戶端對(duì)Redis進(jìn)行并發(fā)訪問時(shí)會(huì)發(fā)生連接超時(shí)、數(shù)據(jù)轉(zhuǎn)換錯(cuò)誤、阻塞、客戶端關(guān)閉連接等問題，這些問題均是由于客戶端連接混亂造成。

對(duì)此有2種解決方法：

1.客戶端角度，為保證每個(gè)客戶端間正常有序與Redis進(jìn)行通信，對(duì)連接進(jìn)行池化，同時(shí)對(duì)客戶端讀寫Redis操作采用內(nèi)部鎖synchronized。

2.服務(wù)器角度，利用setnx實(shí)現(xiàn)鎖。

注：對(duì)于第一種，需要應(yīng)用程序自己處理資源的同步，可以使用的方法比較通俗，可以使用synchronized也可以使用lock；第二種需要用到Redis的setnx命令，但是需要注意一些問題。

?

redis事物的了解CAS(check-and-set 操作實(shí)現(xiàn)樂觀鎖 )?

和眾多其它數(shù)據(jù)庫(kù)一樣，Redis作為NoSQL數(shù)據(jù)庫(kù)也同樣提供了事務(wù)機(jī)制。在Redis中，MULTI/EXEC/DISCARD/WATCH這四個(gè)命令是我們實(shí)現(xiàn)事務(wù)的基石。

相信對(duì)有關(guān)系型數(shù)據(jù)庫(kù)開發(fā)經(jīng)驗(yàn)的開發(fā)者而言這一概念并不陌生，即便如此，我們還是會(huì)簡(jiǎn)要的列出Redis中事務(wù)的實(shí)現(xiàn)特征：

在事務(wù)中的所有命令都將會(huì)被串行化的順序執(zhí)行，事務(wù)執(zhí)行期間，Redis不會(huì)再為其它客戶端的請(qǐng)求提供任何服務(wù)，從而保證了事物中的所有命令被原子的執(zhí)行。

和關(guān)系型數(shù)據(jù)庫(kù)中的事務(wù)相比，在Redis事務(wù)中如果有某一條命令執(zhí)行失敗，其后的命令仍然會(huì)被繼續(xù)執(zhí)行。

我們可以通過MULTI命令開啟一個(gè)事務(wù)，有關(guān)系型數(shù)據(jù)庫(kù)開發(fā)經(jīng)驗(yàn)的人可以將其理解為"BEGIN TRANSACTION"語句。在該語句之后執(zhí)行的命令都將被視為事務(wù)之內(nèi)的操作，最后我們可以通過執(zhí)行EXEC/DISCARD命令來提交/回滾該事務(wù)內(nèi)的所有操作。這兩個(gè)Redis命令可被視為等同于關(guān)系型數(shù)據(jù)庫(kù)中的COMMIT/ROLLBACK語句。

在事務(wù)開啟之前，如果客戶端與服務(wù)器之間出現(xiàn)通訊故障并導(dǎo)致網(wǎng)絡(luò)斷開，其后所有待執(zhí)行的語句都將不會(huì)被服務(wù)器執(zhí)行。然而如果網(wǎng)絡(luò)中斷事件是發(fā)生在客戶端執(zhí)行EXEC命令之后，那么該事務(wù)中的所有命令都會(huì)被服務(wù)器執(zhí)行。

當(dāng)使用Append-Only模式時(shí)，Redis會(huì)通過調(diào)用系統(tǒng)函數(shù)write將該事務(wù)內(nèi)的所有寫操作在本次調(diào)用中全部寫入磁盤。然而如果在寫入的過程中出現(xiàn)系統(tǒng)崩潰，如電源故障導(dǎo)致的宕機(jī)，那么此時(shí)也許只有部分?jǐn)?shù)據(jù)被寫入到磁盤，而另外一部分?jǐn)?shù)據(jù)卻已經(jīng)丟失。

Redis服務(wù)器會(huì)在重新啟動(dòng)時(shí)執(zhí)行一系列必要的一致性檢測(cè)，一旦發(fā)現(xiàn)類似問題，就會(huì)立即退出并給出相應(yīng)的錯(cuò)誤提示。

此時(shí)，我們就要充分利用Redis工具包中提供的redis-check-aof工具，該工具可以幫助我們定位到數(shù)據(jù)不一致的錯(cuò)誤，并將已經(jīng)寫入的部分?jǐn)?shù)據(jù)進(jìn)行回滾。修復(fù)之后我們就可以再次重新啟動(dòng)Redis服務(wù)器了。

?

WATCH命令和基于CAS的樂觀鎖：

在Redis的事務(wù)中，WATCH命令可用于提供CAS(check-and-set)功能。假設(shè)我們通過WATCH命令在事務(wù)執(zhí)行之前監(jiān)控了多個(gè)Keys，倘若在WATCH之后有任何Key的值發(fā)生了變化，EXEC命令執(zhí)行的事務(wù)都將被放棄，同時(shí)返回Null multi-bulk應(yīng)答以通知調(diào)用者事務(wù)

執(zhí)行失敗。例如，我們?cè)俅渭僭O(shè)Redis中并未提供incr命令來完成鍵值的原子性遞增，如果要實(shí)現(xiàn)該功能，我們只能自行編寫相應(yīng)的代碼。其偽碼如下：

val = GET mykey val = val + 1 SET mykey $val

以上代碼只有在單連接的情況下才可以保證執(zhí)行結(jié)果是正確的，因?yàn)槿绻谕粫r(shí)刻有多個(gè)客戶端在同時(shí)執(zhí)行該段代碼，那么就會(huì)出現(xiàn)多線程程序中經(jīng)常出現(xiàn)的一種錯(cuò)誤場(chǎng)景--競(jìng)態(tài)爭(zhēng)用(race condition)。

比如，客戶端A和B都在同一時(shí)刻讀取了mykey的原有值，假設(shè)該值為10，此后兩個(gè)客戶端又均將該值加一后set回Redis服務(wù)器，這樣就會(huì)導(dǎo)致mykey的結(jié)果為11，而不是我們認(rèn)為的12。為了解決類似的問題，我們需要借助WATCH命令的幫助，見如下代碼：

WATCH mykey val = GET mykey val = val + 1 MULTI SET mykey $val EXEC

和此前代碼不同的是，新代碼在獲取mykey的值之前先通過WATCH命令監(jiān)控了該鍵，此后又將set命令包圍在事務(wù)中，這樣就可以有效的保證每個(gè)連接在執(zhí)行EXEC之前，如果當(dāng)前連接獲取的mykey的值被其它連接的客戶端修改，那么當(dāng)前連接的EXEC命令將執(zhí)行失敗。這樣調(diào)用者在判斷返回值后就可以獲悉val是否被重新設(shè)置成功。

?

redis持久化的幾種方式

1、快照（snapshots）

缺省情況情況下，Redis把數(shù)據(jù)快照存放在磁盤上的二進(jìn)制文件中，文件名為dump.rdb。你可以配置Redis的持久化策略，例如數(shù)據(jù)集中每N秒鐘有超過M次更新，就將數(shù)據(jù)寫入磁盤；或者你可以手工調(diào)用命令SAVE或BGSAVE。

工作原理

• Redis forks.

• 子進(jìn)程開始將數(shù)據(jù)寫到臨時(shí)RDB文件中。

• 當(dāng)子進(jìn)程完成寫RDB文件，用新文件替換老文件。

• 這種方式可以使Redis使用copy-on-write技術(shù)。

2、AOF

快照模式并不十分健壯，當(dāng)系統(tǒng)停止，或者無意中Redis被kill掉，最后寫入Redis的數(shù)據(jù)就會(huì)丟失。

這對(duì)某些應(yīng)用也許不是大問題，但對(duì)于要求高可靠性的應(yīng)用來說，Redis就不是一個(gè)合適的選擇。Append-only文件模式是另一種選擇。你可以在配置文件中打開AOF模式

3、虛擬內(nèi)存方式

當(dāng)你的key很小而value很大時(shí),使用VM的效果會(huì)比較好.因?yàn)檫@樣節(jié)約的內(nèi)存比較大.

當(dāng)你的key不小時(shí),可以考慮使用一些非常方法將很大的key變成很大的value,比如你可以考慮將key,value組合成一個(gè)新的value.

vm-max-threads這個(gè)參數(shù),可以設(shè)置訪問swap文件的線程數(shù),設(shè)置最好不要超過機(jī)器的核數(shù),如果設(shè)置為0,那么所有對(duì)swap文件的操作都是串行的.可能會(huì)造成比較長(zhǎng)時(shí)間的延遲,但是對(duì)數(shù)據(jù)完整性有很好的保證.

自己測(cè)試的時(shí)候發(fā)現(xiàn)用虛擬內(nèi)存性能也不錯(cuò)。如果數(shù)據(jù)量很大，可以考慮分布式或者其他數(shù)據(jù)庫(kù)。

?

redis的緩存失效策略和主鍵失效機(jī)制

作為緩存系統(tǒng)都要定期清理無效數(shù)據(jù)，就需要一個(gè)主鍵失效和淘汰策略.

在Redis當(dāng)中，有生存期的key被稱為volatile。在創(chuàng)建緩存時(shí)，要為給定的key設(shè)置生存期，當(dāng)key過期的時(shí)候（生存期為0），它可能會(huì)被刪除。　

1、影響生存時(shí)間的一些操作

生存時(shí)間可以通過使用 DEL 命令來刪除整個(gè) key 來移除，或者被 SET 和 GETSET 命令覆蓋原來的數(shù)據(jù)，也就是說，修改key對(duì)應(yīng)的value和使用另外相同的key和value來覆蓋以后，當(dāng)前數(shù)據(jù)的生存時(shí)間不同。　

比如說，對(duì)一個(gè) key 執(zhí)行INCR命令，對(duì)一個(gè)列表進(jìn)行LPUSH命令，或者對(duì)一個(gè)哈希表執(zhí)行HSET命令，這類操作都不會(huì)修改 key 本身的生存時(shí)間。另一方面，如果使用RENAME對(duì)一個(gè) key 進(jìn)行改名，那么改名后的 key的生存時(shí)間和改名前一樣。　

RENAME命令的另一種可能是，嘗試將一個(gè)帶生存時(shí)間的 key 改名成另一個(gè)帶生存時(shí)間的 another_key ，這時(shí)舊的 another_key (以及它的生存時(shí)間)會(huì)被刪除，然后舊的 key 會(huì)改名為 another_key ，因此，新的 another_key 的生存時(shí)間也和原本的 key 一樣。使用PERSIST命令可以在不刪除 key 的情況下，移除 key 的生存時(shí)間，讓 key 重新成為一個(gè)persistent key 。　

2、如何更新生存時(shí)間

可以對(duì)一個(gè)已經(jīng)帶有生存時(shí)間的 key 執(zhí)行EXPIRE命令，新指定的生存時(shí)間會(huì)取代舊的生存時(shí)間。過期時(shí)間的精度已經(jīng)被控制在1ms之內(nèi)，主鍵失效的時(shí)間復(fù)雜度是O（1），EXPIRE和TTL命令搭配使用，TTL可以查看key的當(dāng)前生存時(shí)間。設(shè)置成功返回 1；當(dāng) key 不存在或者不能為 key 設(shè)置生存時(shí)間時(shí)，返回 0 。

最大緩存配置：

在 redis 中，允許用戶設(shè)置最大使用內(nèi)存大小，server.maxmemory默認(rèn)為0，沒有指定最大緩存，如果有新的數(shù)據(jù)添加，超過最大內(nèi)存，則會(huì)使redis崩潰，所以一定要設(shè)置。redis 內(nèi)存數(shù)據(jù)集大小上升到一定大小的時(shí)候，就會(huì)實(shí)行數(shù)據(jù)淘汰策略。

redis 提供 6種數(shù)據(jù)淘汰策略：

volatile-lru：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中挑選最近最少使用的數(shù)據(jù)淘汰

volatile-ttl：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中挑選將要過期的數(shù)據(jù)淘汰

volatile-random：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中任意選擇數(shù)據(jù)淘汰

allkeys-lru：從數(shù)據(jù)集（server.db[i].dict）中挑選最近最少使用的數(shù)據(jù)淘汰

allkeys-random：從數(shù)據(jù)集（server.db[i].dict）中任意選擇數(shù)據(jù)淘汰

no-enviction（驅(qū)逐）：禁止驅(qū)逐數(shù)據(jù)　

注意這里的6種機(jī)制，volatile和allkeys規(guī)定了是對(duì)已設(shè)置過期時(shí)間的數(shù)據(jù)集淘汰數(shù)據(jù)還是從全部數(shù)據(jù)集淘汰數(shù)據(jù)，后面的lru、ttl以及random是三種不同的淘汰策略，再加上一種no-enviction永不回收的策略。

使用策略規(guī)則：

如果數(shù)據(jù)呈現(xiàn)冪律分布，也就是一部分?jǐn)?shù)據(jù)訪問頻率高，一部分?jǐn)?shù)據(jù)訪問頻率低，則使用allkeys-lru

如果數(shù)據(jù)呈現(xiàn)平等分布，也就是所有的數(shù)據(jù)訪問頻率都相同，則使用allkeys-random　　

三種數(shù)據(jù)淘汰策略：

ttl和random比較容易理解，實(shí)現(xiàn)也會(huì)比較簡(jiǎn)單。主要是Lru最近最少使用淘汰策略，設(shè)計(jì)上會(huì)對(duì)key 按失效時(shí)間排序，然后取最先失效的key進(jìn)行淘汰

?

redis 最適合的場(chǎng)景

Redis最適合所有數(shù)據(jù)in-momory的場(chǎng)景，雖然Redis也提供持久化功能，但實(shí)際更多的是一個(gè)disk-backed的功能，跟傳統(tǒng)意義上的持久化有比較大的差別，那么可能大家就會(huì)有疑問，似乎Redis更像一個(gè)加強(qiáng)版的Memcached，那么何時(shí)使用Memcached，何時(shí)使用Redis呢?

如果簡(jiǎn)單地比較Redis與Memcached的區(qū)別，大多數(shù)都會(huì)得到以下觀點(diǎn)：

Redis不僅僅支持簡(jiǎn)單的k/v類型的數(shù)據(jù)，同時(shí)還提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。

Redis支持?jǐn)?shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。

Redis支持?jǐn)?shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤中，重啟的時(shí)候可以再次加載進(jìn)行使用。

1、會(huì)話緩存（Session Cache）

最常用的一種使用Redis的情景是會(huì)話緩存（session cache）。用Redis緩存會(huì)話比其他存儲(chǔ)（如Memcached）的優(yōu)勢(shì)在于：Redis提供持久化。當(dāng)維護(hù)一個(gè)不是嚴(yán)格要求一致性的緩存時(shí)，如果用戶的購(gòu)物車信息全部丟失，大部分人都會(huì)不高興的，現(xiàn)在，他們還會(huì)這樣嗎？　

幸運(yùn)的是，隨著 Redis 這些年的改進(jìn)，很容易找到怎么恰當(dāng)?shù)氖褂肦edis來緩存會(huì)話的文檔。甚至廣為人知的商業(yè)平臺(tái)Magento也提供Redis的插件。

2、全頁(yè)緩存（FPC）

除基本的會(huì)話token之外，Redis還提供很簡(jiǎn)便的FPC平臺(tái)。回到一致性問題，即使重啟了Redis實(shí)例，因?yàn)橛写疟P的持久化，用戶也不會(huì)看到頁(yè)面加載速度的下降，這是一個(gè)極大改進(jìn)，類似PHP本地FPC。

再次以Magento為例，Magento提供一個(gè)插件來使用Redis作為全頁(yè)緩存后端。

此外，對(duì)WordPress的用戶來說，Pantheon有一個(gè)非常好的插件 wp-redis，這個(gè)插件能幫助你以最快速度加載你曾瀏覽過的頁(yè)面。

3、隊(duì)列

Reids在內(nèi)存存儲(chǔ)引擎領(lǐng)域的一大優(yōu)點(diǎn)是提供 list 和 set 操作，這使得Redis能作為一個(gè)很好的消息隊(duì)列平臺(tái)來使用。Redis作為隊(duì)列使用的操作，就類似于本地程序語言（如Python）對(duì) list 的 push/pop 操作。

如果你快速的在Google中搜索“Redis queues”，你馬上就能找到大量的開源項(xiàng)目，這些項(xiàng)目的目的就是利用Redis創(chuàng)建非常好的后端工具，以滿足各種隊(duì)列需求。例如，Celery有一個(gè)后臺(tái)就是使用Redis作為broker，你可以從這里去查看。

4、排行榜/計(jì)數(shù)器

Redis在內(nèi)存中對(duì)數(shù)字進(jìn)行遞增或遞減的操作實(shí)現(xiàn)的非常好。集合（Set）和有序集合（Sorted Set）也使得我們?cè)趫?zhí)行這些操作的時(shí)候變的非常簡(jiǎn)單，Redis只是正好提供了這兩種數(shù)據(jù)結(jié)構(gòu)。

所以，我們要從排序集合中獲取到排名最靠前的10個(gè)用戶–我們稱之為“user_scores”，我們只需要像下面一樣執(zhí)行即可：

當(dāng)然，這是假定你是根據(jù)你用戶的分?jǐn)?shù)做遞增的排序。如果你想返回用戶及用戶的分?jǐn)?shù)，你需要這樣執(zhí)行：

ZRANGE user_scores 0 10 WITHSCORES

Agora Games就是一個(gè)很好的例子，用Ruby實(shí)現(xiàn)的，它的排行榜就是使用Redis來存儲(chǔ)數(shù)據(jù)的，你可以在這里看到。

5、發(fā)布/訂閱

最后（但肯定不是最不重要的）是Redis的發(fā)布/訂閱功能。發(fā)布/訂閱的使用場(chǎng)景確實(shí)非常多。我已看見人們?cè)谏缃痪W(wǎng)絡(luò)連接中使用，還可作為基于發(fā)布/訂閱的腳本觸發(fā)器，甚至用Redis的發(fā)布/訂閱功能來建立聊天系統(tǒng)！（不，這是真的，你可以去核實(shí)）。

Redis提供的所有特性中，我感覺這個(gè)是喜歡的人最少的一個(gè)，雖然它為用戶提供如果此多功能。

其他問題

有些比較兇殘的面試官，可能會(huì)問我們一些 Redis 數(shù)據(jù)結(jié)構(gòu)的問題，例如：

• Skiplist 插入和查詢?cè)?#xff1f;

• 壓縮列表的原理？

• Redis 底層為什么使用跳躍表而不是紅黑樹？

  跳躍表在范圍查找的時(shí)候性能比較高。

666. 彩蛋

哇哦，爽。雖然過程痛苦，但是中間請(qǐng)教了蠻多人問題，收獲頗多哈。

參考與推薦如下文章：

• JeffreyLcm 《Redis 面試題》

• 烙印99 《史上最全 Redis 面試題及答案》

• yanglbme 《Redis 和 Memcached 有什么區(qū)別？Redis 的線程模型是什么？為什么單線程的 Redis 比多線程的 Memcached 效率要高得多？》

• 老錢 《天下無難試之 Redis 面試題刁難大全》

• yanglbme 《Redis 的持久化有哪幾種方式？不同的持久化機(jī)制都有什么優(yōu)缺點(diǎn)？持久化機(jī)制具體底層是如何實(shí)現(xiàn)的？》

總結(jié)

以上是生活随笔為你收集整理的Redis面试题详解的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。