大家好，我是七哥。

自從上次分享了小伙伴在實(shí)習(xí)和秋招期間歷經(jīng)幾十場(chǎng)面試總結(jié)下來(lái)的 MySQL 面試那些事，小伙伴反響很不錯(cuò)，連我這平均閱讀100左右的號(hào)，那篇文章也獲得了將近900的閱讀量，我猜應(yīng)該很多小伙伴都熱心轉(zhuǎn)給了睡在自己上鋪的兄弟。

所以今天咱繼續(xù)安排，七哥苦苦滴從最近面試的小伙伴那里收集了 Redis 面試常考題（包括Oppo、字節(jié)、快手、阿里等公司），還貼心的整理了答案，快來(lái)看看你能答對(duì)幾個(gè)。

一、基礎(chǔ)篇

什么是Redis

Redis 是一個(gè)使用 C 語(yǔ)言寫成的，開(kāi)源的高性能key-value非關(guān)系緩存數(shù)據(jù)庫(kù)。它支持存儲(chǔ)的value類型相對(duì)更多，包括string(字符串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash（哈希類型）。Redis的數(shù)據(jù)都基于緩存的，所以很快，每秒可以處理超過(guò) 10萬(wàn)次讀寫操作，是已知性能最快的Key-Value DB。Redis也可以實(shí)現(xiàn)數(shù)據(jù)寫入磁盤中，保證了數(shù)據(jù)的安全不丟失，而且Redis的操作是原子性的。

Redis有哪些優(yōu)缺點(diǎn)

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

• 讀寫性能優(yōu)異， Redis能讀的速度是110000次/s，寫的速度是81000次/s。
• 支持?jǐn)?shù)據(jù)持久化，支持AOF和RDB兩種持久化方式。
• 支持事務(wù)，Redis的所有操作都是原子性的，同時(shí)Redis還支持對(duì)幾個(gè)操作合并后的原子性執(zhí)行。
• 數(shù)據(jù)結(jié)構(gòu)豐富，除了支持string類型的value外還支持hash、set、zset、list等數(shù)據(jù)結(jié)構(gòu)。
• 支持主從復(fù)制，主機(jī)會(huì)自動(dòng)將數(shù)據(jù)同步到從機(jī)，可以進(jìn)行讀寫分離。

缺點(diǎn)

• 數(shù)據(jù)庫(kù)容量受到物理內(nèi)存的限制，不能用作海量數(shù)據(jù)的高性能讀寫，因此Redis適合的場(chǎng)景主要局限在較小數(shù)據(jù)量的高性能操作和運(yùn)算上。
• Redis 不具備自動(dòng)容錯(cuò)和恢復(fù)功能，主機(jī)從機(jī)的宕機(jī)都會(huì)導(dǎo)致前端部分讀寫請(qǐng)求失敗，需要等待機(jī)器重啟或者手動(dòng)切換前端的IP才能恢復(fù)。
• 主機(jī)宕機(jī)，宕機(jī)前有部分?jǐn)?shù)據(jù)未能及時(shí)同步到從機(jī)，切換IP后還會(huì)引入數(shù)據(jù)不一致的問(wèn)題，降低了系統(tǒng)的可用性。
• Redis 較難支持在線擴(kuò)容，在集群容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜。為避免這一問(wèn)題，運(yùn)維人員在系統(tǒng)上線時(shí)必須確保有足夠的空間，這對(duì)資源造成了很大的浪費(fèi)。

為什么要用Redis/為什么要用緩存

主要從“高性能”和“高并發(fā)”這兩點(diǎn)來(lái)看待這個(gè)問(wèn)題。

高性能

• 假如用戶第一次訪問(wèn)數(shù)據(jù)庫(kù)中的某些數(shù)據(jù)。這個(gè)過(guò)程會(huì)比較慢，因?yàn)槭菑挠脖P上讀取的。將該用戶訪問(wèn)的數(shù)據(jù)存在數(shù)緩存中，這樣下一次再訪問(wèn)這些數(shù)據(jù)的時(shí)候就可以直接從緩存中獲取了。操作緩存就是直接操作內(nèi)存，所以速度相當(dāng)快。如果數(shù)據(jù)庫(kù)中的對(duì)應(yīng)數(shù)據(jù)改變的之后，同步改變緩存中相應(yīng)的數(shù)據(jù)即可！

高并發(fā)

• 直接操作緩存能夠承受的請(qǐng)求是遠(yuǎn)遠(yuǎn)大于直接訪問(wèn)數(shù)據(jù)庫(kù)的，所以我們可以考慮把數(shù)據(jù)庫(kù)中的部分?jǐn)?shù)據(jù)轉(zhuǎn)移到緩存中去，這樣用戶的一部分請(qǐng)求會(huì)直接到緩存這里而不用經(jīng)過(guò)數(shù)據(jù)庫(kù)。

為什么要用Redis而不用Map/Guava做緩存

• 緩存分為本地緩存和分布式緩存。以 Java 為例，使用自帶的 map 或者 guava 實(shí)現(xiàn)的是本地緩存，最主要的特點(diǎn)是輕量以及快速，生命周期隨著 jvm 的銷毀而結(jié)束，并且在多實(shí)例的情況下，每個(gè)實(shí)例都需要各自保存一份緩存，緩存不具有一致性。
• 使用 redis 或 memcached 之類的稱為分布式緩存，在多實(shí)例的情況下，各實(shí)例共用一份緩存數(shù)據(jù)，緩存具有一致性。缺點(diǎn)是需要保持 redis 或 memcached服務(wù)的高可用，整個(gè)程序架構(gòu)上較為復(fù)雜。

Redis為什么這么快

• 完全基于內(nèi)存，絕大部分請(qǐng)求是純粹的內(nèi)存操作，非常快速。數(shù)據(jù)存在內(nèi)存中，類似于 HashMap，HashMap 的優(yōu)勢(shì)就是查找和操作的時(shí)間復(fù)雜度都是O(1)；
• 數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單，對(duì)數(shù)據(jù)操作也簡(jiǎn)單，Redis 中的數(shù)據(jù)結(jié)構(gòu)是專門進(jìn)行設(shè)計(jì)的；
• 采用單線程，避免了不必要的上下文切換和競(jìng)爭(zhēng)條件，也不存在多進(jìn)程或者多線程導(dǎo)致的切換而消耗 CPU，不用去考慮各種鎖的問(wèn)題，不存在加鎖釋放鎖操作，沒(méi)有因?yàn)榭赡艹霈F(xiàn)死鎖而導(dǎo)致的性能消耗；
• 使用多路 I/O 復(fù)用模型，非阻塞 IO；

Redis有哪些數(shù)據(jù)類型

• Redis主要有5種數(shù)據(jù)類型，包括String，List，Set，Zset，Hash，滿足大部分的使用要求。

Redis的應(yīng)用場(chǎng)景

• 計(jì)數(shù)器?？梢詫?duì) String 進(jìn)行自增自減運(yùn)算，從而實(shí)現(xiàn)計(jì)數(shù)器功能。Redis 這種內(nèi)存型數(shù)據(jù)庫(kù)的讀寫性能非常高，很適合存儲(chǔ)頻繁讀寫的計(jì)數(shù)量。

• 緩存。將熱點(diǎn)數(shù)據(jù)放到內(nèi)存中，設(shè)置內(nèi)存的最大使用量以及淘汰策略來(lái)保證緩存的命中率。

• 會(huì)話緩存?？梢允褂?Redis 來(lái)統(tǒng)一存儲(chǔ)多臺(tái)應(yīng)用服務(wù)器的會(huì)話信息。當(dāng)應(yīng)用服務(wù)器不再存儲(chǔ)用戶的會(huì)話信息，也就不再具有狀態(tài)，一個(gè)用戶可以請(qǐng)求任意一個(gè)應(yīng)用服務(wù)器，從而更容易實(shí)現(xiàn)高可用性以及可伸縮性。

• 全頁(yè)緩存（FPC）。除基本的會(huì)話 token之外，Redis還提供很簡(jiǎn)便的FPC平臺(tái)。以Magento為例，Magento提供一個(gè)插件來(lái)使用Redis作為全頁(yè)緩存后端。此外，對(duì)WordPress的用戶來(lái)說(shuō)，Pantheon有一個(gè)非常好的插件 wp-redis，這個(gè)插件能幫助你以最快速度加載你曾瀏覽過(guò)的頁(yè)面。

• 查找表。例如 DNS 記錄就很適合使用 Redis 進(jìn)行存儲(chǔ)。查找表和緩存類似，也是利用了 Redis 快速的查找特性。但是查找表的內(nèi)容不能失效，而緩存的內(nèi)容可以失效，因?yàn)榫彺娌蛔鳛榭煽康臄?shù)據(jù)來(lái)源。

• 消息隊(duì)列(發(fā)布/訂閱功能)。List 是一個(gè)雙向鏈表，可以通過(guò) lpush 和 rpop 寫入和讀取消息。不過(guò)最好使用 Kafka、RabbitMQ 等消息中間件。

• 分布式鎖實(shí)現(xiàn)。在分布式場(chǎng)景下，無(wú)法使用單機(jī)環(huán)境下的鎖來(lái)對(duì)多個(gè)節(jié)點(diǎn)上的進(jìn)程進(jìn)行同步。可以使用 Redis 自帶的 SETNX 命令實(shí)現(xiàn)分布式鎖，除此之外，還可以使用官方提供的 RedLock 分布式鎖實(shí)現(xiàn)。

• 其它。Set 可以實(shí)現(xiàn)交集、并集等操作，從而實(shí)現(xiàn)共同好友等功能。ZSet 可以實(shí)現(xiàn)有序性操作，從而實(shí)現(xiàn)排行榜等功能。

Redis的持久化方式？?jī)?yōu)缺點(diǎn)？

什么是Redis持久化？持久化就是把內(nèi)存的數(shù)據(jù)寫到磁盤中去，防止服務(wù)宕機(jī)了內(nèi)存數(shù)據(jù)丟失。

Redis 提供兩種持久化機(jī)制 RDB（默認(rèn)） 和 AOF 機(jī)制

• RDB是Redis默認(rèn)的持久化方式。按照一定的時(shí)間將內(nèi)存的數(shù)據(jù)以快照的形式保存到硬盤中，對(duì)應(yīng)產(chǎn)生的數(shù)據(jù)文件為dump.rdb。通過(guò)配置文件中的save參數(shù)來(lái)定義快照的周期。

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

1. 只有一個(gè)文件 dump.rdb，方便持久化。
2. 容災(zāi)性好，一個(gè)文件可以保存到安全的磁盤。
3. 性能最大化，fork 子進(jìn)程來(lái)完成寫操作，讓主進(jìn)程繼續(xù)處理命令，所以是 IO 最大化。使用單獨(dú)子進(jìn)程來(lái)進(jìn)行持久化，主進(jìn)程不會(huì)進(jìn)行任何 IO 操作，保證了 redis 的高性能。
4. 相對(duì)于數(shù)據(jù)集大時(shí)，比 AOF 的啟動(dòng)效率更高。

缺點(diǎn)：

1. 數(shù)據(jù)安全性低。RDB 是間隔一段時(shí)間進(jìn)行持久化，如果持久化之間 redis 發(fā)生故障，會(huì)發(fā)生數(shù)據(jù)丟失。所以這種方式更適合數(shù)據(jù)要求不嚴(yán)謹(jǐn)?shù)臅r(shí)候)
2. AOF（Append-only file)持久化方式：是指所有的命令行記錄以 redis 命令請(qǐng) 求協(xié)議的格式完全持久化存儲(chǔ))保存為 aof 文件。

• AOF：持久化。AOF持久化(即Append Only File持久化)，則是將Redis執(zhí)行的每次寫命令記錄到單獨(dú)的日志文件中，當(dāng)重啟Redis會(huì)重新將持久化的日志中文件恢復(fù)數(shù)據(jù)。當(dāng)兩種方式同時(shí)開(kāi)啟時(shí)，數(shù)據(jù)恢復(fù)Redis會(huì)優(yōu)先選擇AOF恢復(fù)。

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

1. 數(shù)據(jù)安全，aof 持久化可以配置 appendfsync 屬性，有 always，每進(jìn)行一次 命令操作就記錄到 aof 文件中一次。
2. 通過(guò) append 模式寫文件，即使中途服務(wù)器宕機(jī)，可以通過(guò) redis-check-aof 工具解決數(shù)據(jù)一致性問(wèn)題。
3. AOF 機(jī)制的 rewrite 模式。AOF 文件沒(méi)被 rewrite 之前（文件過(guò)大時(shí)會(huì)對(duì)命令 進(jìn)行合并重寫），可以刪除其中的某些命令（比如誤操作的 flushall）)。

缺點(diǎn)：

1. AOF 文件比 RDB 文件大，且恢復(fù)速度慢。
2. 數(shù)據(jù)集大的時(shí)候，比 rdb 啟動(dòng)效率低。

倆種持久化的優(yōu)缺點(diǎn)是什么？

• AOF文件比RDB更新頻率高，優(yōu)先使用AOF還原數(shù)據(jù)。
• AOF比RDB更安全也更大。
• RDB性能比AOF好。
• 如果兩個(gè)都配了優(yōu)先加載AOF。

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

• 如果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集群可以做到這樣。

Redis的過(guò)期鍵的刪除策略

我們都知道，Redis是key-value數(shù)據(jù)庫(kù)，我們可以設(shè)置Redis中緩存的key的過(guò)期時(shí)間。Redis的過(guò)期策略就是指當(dāng)Redis中緩存的key過(guò)期了，Redis如何處理。

過(guò)期策略通常有以下三種：

• 立即過(guò)期：每個(gè)設(shè)置過(guò)期時(shí)間的key都需要?jiǎng)?chuàng)建一個(gè)定時(shí)器，到過(guò)期時(shí)間就會(huì)立即清除。該策略可以立即清除過(guò)期的數(shù)據(jù)，對(duì)內(nèi)存很友好；但是會(huì)占用大量的CPU資源去處理過(guò)期的數(shù)據(jù)，從而影響緩存的響應(yīng)時(shí)間和吞吐量。
• 惰性過(guò)期：只有當(dāng)訪問(wèn)一個(gè)key時(shí)，才會(huì)判斷該key是否已過(guò)期，過(guò)期則清除。該策略可以最大化地節(jié)省CPU資源，卻對(duì)內(nèi)存非常不友好。極端情況可能出現(xiàn)大量的過(guò)期key沒(méi)有再次被訪問(wèn)，從而不會(huì)被清除，占用大量?jī)?nèi)存。
• 定期過(guò)期：每隔一定的時(shí)間，會(huì)掃描 expires 字典中一定數(shù)量的key，并清除其中已過(guò)期的key。該策略是前兩者的一個(gè)折中方案。通過(guò)調(diào)整定時(shí)掃描的時(shí)間間隔和每次掃描的限定耗時(shí)，可以在不同情況下使得CPU和內(nèi)存資源達(dá)到最優(yōu)的平衡效果。(expires字典會(huì)保存所有設(shè)置了過(guò)期時(shí)間的key的過(guò)期時(shí)間數(shù)據(jù)，其中，key是指向鍵空間中的某個(gè)鍵的指針，value是該鍵的毫秒精度的UNIX時(shí)間戳表示的過(guò)期時(shí)間。鍵空間是指該Redis集群中保存的所有鍵。)

Redis中同時(shí)使用了惰性過(guò)期和定期過(guò)期兩種過(guò)期策略。

Redis key的過(guò)期時(shí)間和永久有效分別怎么設(shè)置？

• expire和 persist 命令。

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

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

Redis的內(nèi)存淘汰策略有哪些

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

全局的key選擇性移除

• noeviction：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，新寫入操作會(huì)報(bào)錯(cuò)。
• allkeys-lru：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在鍵空間中，移除最近最少使用的key。（這個(gè)是最常用的）
• allkeys-random：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在鍵空間中，隨機(jī)移除某個(gè)key。

設(shè)置過(guò)期時(shí)間的key選擇性移除

• volatile-lru：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在設(shè)置了過(guò)期時(shí)間的鍵空間中，移除最近最少使用的key。
• volatile-random：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在設(shè)置了過(guò)期時(shí)間的鍵空間中，隨機(jī)移除某個(gè)key。
• volatile-ttl：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在設(shè)置了過(guò)期時(shí)間的鍵空間中，有更早過(guò)期時(shí)間的key優(yōu)先移除。

這里Redis的內(nèi)存淘汰策略的選取并不會(huì)影響過(guò)期的key的處理。內(nèi)存淘汰策略是用于處理內(nèi)存不足時(shí)的需要申請(qǐng)額外空間的數(shù)據(jù)；而過(guò)期策略用于處理過(guò)期的緩存數(shù)據(jù)。

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

• 內(nèi)存。

Redis的內(nèi)存用完了會(huì)發(fā)生什么？

• 如果達(dá)到設(shè)置的上限，Redis的寫命令會(huì)返回錯(cuò)誤信息（但是讀命令還可以正常返回。）或者你可以配置內(nèi)存淘汰機(jī)制，當(dāng)Redis達(dá)到內(nèi)存上限時(shí)會(huì)沖刷掉舊的內(nèi)容。

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

• 可以好好利用Hash,list,sorted set,set等集合類型數(shù)據(jù)，因?yàn)橥ǔＧ闆r下很多小的Key-Value可以用更緊湊的方式存放到一起。盡可能使用散列表（hashes），散列表（是說(shuō)散列表里面存儲(chǔ)的數(shù)少）使用的內(nèi)存非常小，所以你應(yīng)該盡可能的將你的數(shù)據(jù)模型抽象到一個(gè)散列表里面。比如你的web系統(tǒng)中有一個(gè)用戶對(duì)象，不要為這個(gè)用戶的名稱，姓氏，郵箱，密碼設(shè)置單獨(dú)的key，而是應(yīng)該把這個(gè)用戶的所有信息存儲(chǔ)到一張散列表里面。

二、線程模型

Redis線程模型

Redis基于Reactor模式開(kāi)發(fā)了網(wǎng)絡(luò)事件處理器，這個(gè)處理器被稱為文件事件處理器（file event handler）。它的組成結(jié)構(gòu)為4部分：多個(gè)套接字、IO多路復(fù)用程序、文件事件分派器、事件處理器。因?yàn)槲募录峙善麝?duì)列的消費(fèi)是單線程的，所以Redis才叫單線程模型。

• 文件事件處理器使用 I/O 多路復(fù)用（multiplexing）程序來(lái)同時(shí)監(jiān)聽(tīng)多個(gè)套接字， 并根據(jù)套接字目前執(zhí)行的任務(wù)來(lái)為套接字關(guān)聯(lián)不同的事件處理器。
• 當(dāng)被監(jiān)聽(tīng)的套接字準(zhǔn)備好執(zhí)行連接應(yīng)答（accept）、讀取（read）、寫入（write）、關(guān)閉（close）等操作時(shí)， 與操作相對(duì)應(yīng)的文件事件就會(huì)產(chǎn)生， 這時(shí)文件事件處理器就會(huì)調(diào)用套接字之前關(guān)聯(lián)好的事件處理器來(lái)處理這些事件。

雖然文件事件處理器以單線程方式運(yùn)行， 但通過(guò)使用 I/O 多路復(fù)用程序來(lái)監(jiān)聽(tīng)多個(gè)套接字， 文件事件處理器既實(shí)現(xiàn)了高性能的網(wǎng)絡(luò)通信模型， 又可以很好地與 redis 服務(wù)器中其他同樣以單線程方式運(yùn)行的模塊進(jìn)行對(duì)接， 這保持了 Redis 內(nèi)部單線程設(shè)計(jì)的簡(jiǎn)單性。

三、事務(wù)

什么是事務(wù)？

• 事務(wù)是一個(gè)單獨(dú)的隔離操作：事務(wù)中的所有命令都會(huì)序列化、按順序地執(zhí)行。事務(wù)在執(zhí)行的過(guò)程中，不會(huì)被其他客戶端發(fā)送來(lái)的命令請(qǐng)求所打斷。
• 事務(wù)是一個(gè)原子操作：事務(wù)中的命令要么全部被執(zhí)行，要么全部都不執(zhí)行。

Redis事務(wù)的概念

• Redis 事務(wù)的本質(zhì)是通過(guò)MULTI、EXEC、WATCH等一組命令的集合。事務(wù)支持一次執(zhí)行多個(gè)命令，一個(gè)事務(wù)中所有命令都會(huì)被序列化。在事務(wù)執(zhí)行過(guò)程，會(huì)按照順序串行化執(zhí)行隊(duì)列中的命令，其他客戶端提交的命令請(qǐng)求不會(huì)插入到事務(wù)執(zhí)行命令序列中。
• 總結(jié)說(shuō)：redis事務(wù)就是一次性、順序性、排他性的執(zhí)行一個(gè)隊(duì)列中的一系列命令。

Redis事務(wù)的三個(gè)階段

1. 事務(wù)開(kāi)始 MULTI
2. 命令入隊(duì)
3. 事務(wù)執(zhí)行 EXEC

事務(wù)執(zhí)行過(guò)程中，如果服務(wù)端收到有EXEC、DISCARD、WATCH、MULTI之外的請(qǐng)求，將會(huì)把請(qǐng)求放入隊(duì)列中排隊(duì)。

Redis事務(wù)相關(guān)命令

Redis事務(wù)功能是通過(guò)MULTI、EXEC、DISCARD和WATCH 四個(gè)原語(yǔ)實(shí)現(xiàn)的，Redis會(huì)將一個(gè)事務(wù)中的所有命令序列化，然后按順序執(zhí)行。

1. Redis 不支持回滾，“Redis 在事務(wù)失敗時(shí)不進(jìn)行回滾，而是繼續(xù)執(zhí)行余下的命令”， 所以 Redis 的內(nèi)部可以保持簡(jiǎn)單且快速。
2. 如果在一個(gè)事務(wù)中的命令出現(xiàn)錯(cuò)誤，那么所有的命令都不會(huì)執(zhí)行；
3. 如果在一個(gè)事務(wù)中出現(xiàn)運(yùn)行錯(cuò)誤，那么正確的命令會(huì)被執(zhí)行。

• WATCH 命令是一個(gè)樂(lè)觀鎖，可以為 Redis 事務(wù)提供 check-and-set （CAS）行為?？梢员O(jiān)控一個(gè)或多個(gè)鍵，一旦其中有一個(gè)鍵被修改（或刪除），之后的事務(wù)就不會(huì)執(zhí)行，監(jiān)控一直持續(xù)到EXEC命令。
• MULTI命令用于開(kāi)啟一個(gè)事務(wù)，它總是返回OK。MULTI執(zhí)行之后，客戶端可以繼續(xù)向服務(wù)器發(fā)送任意多條命令，這些命令不會(huì)立即被執(zhí)行，而是被放到一個(gè)隊(duì)列中，當(dāng)EXEC命令被調(diào)用時(shí)，所有隊(duì)列中的命令才會(huì)被執(zhí)行。
• EXEC：執(zhí)行所有事務(wù)塊內(nèi)的命令。返回事務(wù)塊內(nèi)所有命令的返回值，按命令執(zhí)行的先后順序排列。當(dāng)操作被打斷時(shí)，返回空值 nil 。
• 通過(guò)調(diào)用DISCARD，客戶端可以清空事務(wù)隊(duì)列，并放棄執(zhí)行事務(wù)， 并且客戶端會(huì)從事務(wù)狀態(tài)中退出。
• UNWATCH命令可以取消watch對(duì)所有key的監(jiān)控。

事務(wù)管理（ACID）概述

• 原子性（Atomicity），原子性是指事務(wù)是一個(gè)不可分割的工作單位，事務(wù)中的操作要么都發(fā)生，要么都不發(fā)生。
• 一致性（Consistency），事務(wù)前后數(shù)據(jù)的完整性必須保持一致。
• 隔離性（Isolation），多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)，一個(gè)事務(wù)的執(zhí)行不應(yīng)影響其他事務(wù)的執(zhí)行
• 持久性（Durability），持久性是指一個(gè)事務(wù)一旦被提交，它對(duì)數(shù)據(jù)庫(kù)中數(shù)據(jù)的改變就是永久性的，接下來(lái)即使數(shù)據(jù)庫(kù)發(fā)生故障也不應(yīng)該對(duì)其有任何影響

Redis的事務(wù)總是具有ACID中的一致性和隔離性，其他特性是不支持的。當(dāng)服務(wù)器運(yùn)行在_AOF_持久化模式下，并且appendfsync選項(xiàng)的值為always時(shí)，事務(wù)也具有耐久性。

Redis事務(wù)支持隔離性嗎

• Redis 是單進(jìn)程程序，并且它保證在執(zhí)行事務(wù)時(shí)，不會(huì)對(duì)事務(wù)進(jìn)行中斷，事務(wù)可以運(yùn)行直到執(zhí)行完所有事務(wù)隊(duì)列中的命令為止。因此，Redis 的事務(wù)是總是帶有隔離性的。

Redis事務(wù)保證原子性嗎，支持回滾嗎

• Redis中，單條命令是原子性執(zhí)行的，但事務(wù)不保證原子性，且沒(méi)有回滾。事務(wù)中任意命令執(zhí)行失敗，其余的命令仍會(huì)被執(zhí)行。

Redis事務(wù)其他實(shí)現(xiàn)

• 基于Lua腳本，Redis可以保證腳本內(nèi)的命令一次性、按順序地執(zhí)行。其同時(shí)也不提供事務(wù)運(yùn)行錯(cuò)誤的回滾，執(zhí)行過(guò)程中如果部分命令運(yùn)行錯(cuò)誤，剩下的命令還是會(huì)繼續(xù)運(yùn)行完。
• 基于中間標(biāo)記變量，通過(guò)另外的標(biāo)記變量來(lái)標(biāo)識(shí)事務(wù)是否執(zhí)行完成，讀取數(shù)據(jù)時(shí)先讀取該標(biāo)記變量判斷是否事務(wù)執(zhí)行完成。但這樣會(huì)需要額外寫代碼實(shí)現(xiàn)，比較繁瑣。

四、集群相關(guān)

Redis哨兵機(jī)制？哨兵如何判斷主掛了？

哨兵的介紹

sentinel，中文名是哨兵。哨兵是 redis 集群機(jī)構(gòu)中非常重要的一個(gè)組件，主要有以下功能：

• 集群監(jiān)控：負(fù)責(zé)監(jiān)控 redis master 和 slave 進(jìn)程是否正常工作。

• 消息通知：如果某個(gè) redis 實(shí)例有故障，那么哨兵負(fù)責(zé)發(fā)送消息作為報(bào)警通知給管理員。

• 故障轉(zhuǎn)移：如果 master node 掛掉了，會(huì)自動(dòng)轉(zhuǎn)移到 slave node 上。

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

哨兵如何判斷主掛了

1. 哨兵啟動(dòng)后根據(jù)配置向 master 發(fā)送info指令，獲取并且保存所有哨兵狀態(tài)，主節(jié)點(diǎn)和從節(jié)點(diǎn)的信息；

2. 主節(jié)點(diǎn) master 會(huì)記錄所有 從節(jié)點(diǎn)和與它連接的哨兵實(shí)例的信息；

3. 哨兵會(huì)根據(jù)在主節(jié)點(diǎn)拿到的從節(jié)點(diǎn)信息，給對(duì)應(yīng)的從節(jié)點(diǎn)建立連接后發(fā)送info指令；

4. 接著哨兵2來(lái)了，同樣的也會(huì)給主節(jié)點(diǎn)發(fā)送 info 指令，同時(shí)拿到了從節(jié)點(diǎn)和哨兵的實(shí)例信息；

5. 此時(shí)哨兵2也會(huì)保存跟哨兵1一樣的信息，只不過(guò)它保存的哨兵信息是2個(gè)；

6. 這個(gè)時(shí)候?yàn)榱嗣總€(gè)哨兵的信息都一致它們之間建立了一個(gè)發(fā)布訂閱，互相發(fā)送 ping 命令 保證信息長(zhǎng)期對(duì)稱；

7. 當(dāng)再來(lái)一個(gè)哨兵3時(shí)，也會(huì)做同樣的事情，給主節(jié)點(diǎn)和從節(jié)點(diǎn)發(fā)送info，并且跟哨兵1和哨兵2建立連接；

官方Redis Cluster 方案

架構(gòu)圖

架構(gòu)細(xì)節(jié)

1. 圖中描述的是六個(gè)redis實(shí)例構(gòu)成的集群，6379端口為客戶端通訊端口，16379端口為集群總線端口

2. 集群內(nèi)部劃分為16384個(gè)數(shù)據(jù)分槽，分布在三個(gè)主redis中。

3. 從redis中沒(méi)有分槽，不會(huì)參與集群投票，也不會(huì)幫忙加快讀取數(shù)據(jù)，僅僅作為主機(jī)的備份。

4. 三個(gè)主節(jié)點(diǎn)中平均分布著16384數(shù)據(jù)分槽的三分之一，每個(gè)節(jié)點(diǎn)中不會(huì)存有有重復(fù)數(shù)據(jù)，僅僅有自己的從機(jī)幫忙冗余。

5. 所有的redis主節(jié)點(diǎn)彼此互聯(lián)(PING-PONG機(jī)制),內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬。

6. 客戶端與redis節(jié)點(diǎn)直連,不需要中間proxy層.客戶端不需要連接集群所有節(jié)點(diǎn),連接集群中任何一個(gè)可用節(jié)點(diǎn)即可。

7. 節(jié)點(diǎn)的fail是通過(guò)集群中超過(guò)半數(shù)的節(jié)點(diǎn)檢測(cè)失效時(shí)才生效。

操作原理演示

Redis 集群中內(nèi)置了 16384個(gè)哈希槽，當(dāng)需要在 Redis 集群中放置一個(gè) key-value 時(shí)，redis 先對(duì) key使用 crc16 算法算出一個(gè)結(jié)果，然后把結(jié)果對(duì) 16384 求余數(shù)，這樣每個(gè) key 都會(huì)對(duì)應(yīng)一個(gè)編號(hào)在 0-16383 之間的哈希槽，redis 會(huì)根據(jù)節(jié)點(diǎn)數(shù)量大致均等的將哈希槽映射到不同的節(jié)點(diǎn)。

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

• 無(wú)中心架構(gòu)，支持動(dòng)態(tài)擴(kuò)容，對(duì)業(yè)務(wù)透明
• 具備Sentinel的監(jiān)控和自動(dòng)Failover(故障轉(zhuǎn)移)能力
• 客戶端不需要連接集群所有節(jié)點(diǎn)，連接集群中任何一個(gè)可用節(jié)點(diǎn)即可
• 高性能，客戶端直連redis服務(wù)，免去了proxy代理的損耗

缺點(diǎn)

• 運(yùn)維也很復(fù)雜，數(shù)據(jù)遷移需要人工干預(yù)
• 只能使用0號(hào)數(shù)據(jù)庫(kù)
• 不支持批量操作(pipeline管道操作)
• 分布式邏輯和存儲(chǔ)模塊耦合等

Redis 主從架構(gòu)

• 單機(jī)的 redis，能夠承載的 QPS 大概就在上萬(wàn)到幾萬(wàn)不等。對(duì)于緩存來(lái)說(shuō)，一般都是用來(lái)支撐讀高并發(fā)的。因此架構(gòu)做成主從(master-slave)架構(gòu)，一主多從，主負(fù)責(zé)寫，并且將數(shù)據(jù)復(fù)制到其它的 slave 節(jié)點(diǎn)，從節(jié)點(diǎn)負(fù)責(zé)讀。所有的讀請(qǐng)求全部走從節(jié)點(diǎn)。這樣也可以很輕松實(shí)現(xiàn)水平擴(kuò)容，支撐讀高并發(fā)。

Redis 主從復(fù)制的核心原理

• 當(dāng)啟動(dòng)一個(gè) slave node 的時(shí)候，它會(huì)發(fā)送一個(gè) PSYNC 命令給 master node。
• 如果這是 slave node 初次連接到 master node，那么會(huì)觸發(fā)一次 full resynchronization 全量復(fù)制。此時(shí) master 會(huì)啟動(dòng)一個(gè)后臺(tái)線程，開(kāi)始生成一份 RDB 快照文件，
• 同時(shí)還會(huì)將從客戶端 client 新收到的所有寫命令緩存在內(nèi)存中。RDB 文件生成完畢后， master 會(huì)將這個(gè) RDB 發(fā)送給 slave，slave 會(huì)先寫入本地磁盤，然后再?gòu)谋镜卮疟P加載到內(nèi)存中，
• 接著 master 會(huì)將內(nèi)存中緩存的寫命令發(fā)送到 slave，slave 也會(huì)同步這些數(shù)據(jù)。
• slave node 如果跟 master node 有網(wǎng)絡(luò)故障，斷開(kāi)了連接，會(huì)自動(dòng)重連，連接之后 master node 僅會(huì)復(fù)制給 slave 部分缺少的數(shù)據(jù)。

缺點(diǎn)

所有的slave節(jié)點(diǎn)數(shù)據(jù)的復(fù)制和同步都由master節(jié)點(diǎn)來(lái)處理，會(huì)照成master節(jié)點(diǎn)壓力太大，使用主從從結(jié)構(gòu)來(lái)解決

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

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

說(shuō)說(shuō)Redis哈希槽的概念？

Redis集群沒(méi)有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384個(gè)哈希槽，每個(gè)key通過(guò)CRC16校驗(yàn)后對(duì)16384取模來(lái)決定放置哪個(gè)槽，集群的每個(gè)節(jié)點(diǎn)負(fù)責(zé)一部分hash槽。

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

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

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

采用異步復(fù)制。

Redis集群最大節(jié)點(diǎn)個(gè)數(shù)是多少？

16384個(gè)。

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

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

五、分區(qū)

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

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

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

分區(qū)可以讓Redis管理更大的內(nèi)存，Redis將可以使用所有機(jī)器的內(nèi)存。如果沒(méi)有分區(qū)，你最多只能使用一臺(tái)機(jī)器的內(nèi)存。分區(qū)使Redis的計(jì)算能力通過(guò)簡(jiǎn)單地增加計(jì)算機(jī)得到成倍提升，Redis的網(wǎng)絡(luò)帶寬也會(huì)隨著計(jì)算機(jī)和網(wǎng)卡的增加而成倍增長(zhǎng)。

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

• 客戶端分區(qū)就是在客戶端就已經(jīng)決定數(shù)據(jù)會(huì)被存儲(chǔ)到哪個(gè)redis節(jié)點(diǎn)或者從哪個(gè)redis節(jié)點(diǎn)讀取。大多數(shù)客戶端已經(jīng)實(shí)現(xiàn)了客戶端分區(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é)果返回給客戶端。redis和memcached的一種代理實(shí)現(xiàn)就是Twemproxy。

• 查詢路由(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)，而是在客戶端的幫助下直接redirected到正確的Redis節(jié)點(diǎn)。

Redis分區(qū)有什么缺點(diǎn)？

• 涉及多個(gè)key的操作通常不會(huì)被支持。例如你不能對(duì)兩個(gè)集合求交集，因?yàn)樗麄兛赡鼙淮鎯?chǔ)到不同的Redis實(shí)例（實(shí)際上這種情況也有辦法，但是不能直接使用交集指令）。
• 同時(shí)操作多個(gè)key,則不能使用Redis事務(wù)。
• 分區(qū)使用的粒度是key，不能使用一個(gè)非常長(zhǎng)的排序key存儲(chǔ)一個(gè)數(shù)據(jù)集。
• 當(dāng)使用分區(qū)的時(shí)候，數(shù)據(jù)處理會(huì)非常復(fù)雜，例如為了備份你必須從不同的Redis實(shí)例和主機(jī)同時(shí)收集RDB / AOF文件。
• 分區(qū)時(shí)動(dòng)態(tài)擴(kuò)容或縮容可能非常復(fù)雜。Redis集群在運(yùn)行時(shí)增加或者刪除Redis節(jié)點(diǎn)，能做到最大程度對(duì)用戶透明地?cái)?shù)據(jù)再平衡，但其他一些客戶端分區(qū)或者代理分區(qū)方法則不支持這種特性。然而，有一種預(yù)分片的技術(shù)也可以較好的解決這個(gè)問(wèn)題。

六、分布式問(wèn)題

Redis實(shí)現(xiàn)分布式鎖

• Redis為單進(jìn)程單線程模式，采用隊(duì)列模式將并發(fā)訪問(wèn)變成串行訪問(wèn)，且多客戶端對(duì)Redis的連接并不存在競(jìng)爭(zhēng)關(guān)系Redis中可以使用setNx命令實(shí)現(xiàn)分布式鎖。
• 當(dāng)且僅當(dāng) key 不存在，將 key 的值設(shè)為 value。若給定的 key 已經(jīng)存在，則 setNx不做任何動(dòng)作
• SETNX 是『SET if Not eXists』(如果不存在，則 SET)的簡(jiǎn)寫。
• 返回值：設(shè)置成功，返回 1 。設(shè)置失敗，返回 0 。

使用setNx完成同步鎖的流程及事項(xiàng)如下：

• 使用SETNX命令獲取鎖，若返回0（key已存在，鎖已存在）則獲取失敗，反之獲取成功;
• 為了防止獲取鎖后程序出現(xiàn)異常，導(dǎo)致其他線程/進(jìn)程調(diào)用setNx命令總是返回0而進(jìn)入死鎖狀態(tài)，需要為該key設(shè)置一個(gè)“合理”的過(guò)期時(shí)間釋放鎖，使用DEL命令將鎖數(shù)據(jù)刪除;

如何解決 Redis 的并發(fā)競(jìng)爭(zhēng) Key 問(wèn)題

所謂 Redis 的并發(fā)競(jìng)爭(zhēng) Key 的問(wèn)題也就是多個(gè)系統(tǒng)同時(shí)對(duì)一個(gè) key 進(jìn)行操作，但是最后執(zhí)行的順序和我們期望的順序不同，這樣也就導(dǎo)致了結(jié)果的不同！

推薦一種方案：分布式鎖（zookeeper 和 redis 都可以實(shí)現(xiàn)分布式鎖）。（如果不存在 Redis 的并發(fā)競(jìng)爭(zhēng) Key 問(wèn)題，不要使用分布式鎖，這樣會(huì)影響性能）

基于zookeeper臨時(shí)有序節(jié)點(diǎn)可以實(shí)現(xiàn)的分布式鎖。大致思想為：每個(gè)客戶端對(duì)某個(gè)方法加鎖時(shí)，在zookeeper上的與該方法對(duì)應(yīng)的指定節(jié)點(diǎn)的目錄下，生成一個(gè)唯一的瞬時(shí)有序節(jié)點(diǎn)。判斷是否獲取鎖的方式很簡(jiǎn)單，只需要判斷有序節(jié)點(diǎn)中序號(hào)最小的一個(gè)。當(dāng)釋放鎖的時(shí)候，只需將這個(gè)瞬時(shí)節(jié)點(diǎn)刪除即可。同時(shí)，其可以避免服務(wù)宕機(jī)導(dǎo)致的鎖無(wú)法釋放，而產(chǎn)生的死鎖問(wèn)題。完成業(yè)務(wù)流程后，刪除對(duì)應(yīng)的子節(jié)點(diǎn)釋放鎖。

在實(shí)踐中，當(dāng)然是從以可靠性為主。所以首推Zookeeper。

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

• 既然Redis是如此的輕量（單實(shí)例只使用1M內(nèi)存），為防止以后的擴(kuò)容，最好的辦法就是一開(kāi)始就啟動(dòng)較多實(shí)例。即便你只有一臺(tái)服務(wù)器，你也可以一開(kāi)始就讓Redis以分布式的方式運(yùn)行，使用分區(qū)，在同一臺(tái)服務(wù)器上啟動(dòng)多個(gè)實(shí)例。
• 一開(kāi)始就多設(shè)置幾個(gè)Redis實(shí)例，例如32或者64個(gè)實(shí)例，對(duì)大多數(shù)用戶來(lái)說(shuō)這操作起來(lái)可能比較麻煩，但是從長(zhǎng)久來(lái)看做這點(diǎn)犧牲是值得的。
• 這樣的話，當(dāng)你的數(shù)據(jù)不斷增長(zhǎng)，需要更多的Redis服務(wù)器時(shí)，你需要做的就是僅僅將Redis實(shí)例從一臺(tái)服務(wù)遷移到另外一臺(tái)服務(wù)器而已（而不用考慮重新分區(qū)的問(wèn)題）。一旦你添加了另一臺(tái)服務(wù)器，你需要將你一半的Redis實(shí)例從第一臺(tái)機(jī)器遷移到第二臺(tái)機(jī)器。

什么是 RedLock

Redis 官方站提出了一種權(quán)威的基于 Redis 實(shí)現(xiàn)分布式鎖的方式名叫Redlock。此種方式比原先的單節(jié)點(diǎn)的方法更安全。它可以保證以下特性：

• 安全特性：互斥訪問(wèn)，即永遠(yuǎn)只有一個(gè) client 能拿到鎖；
• 避免死鎖：最終 client 都可能拿到鎖，不會(huì)出現(xiàn)死鎖的情況，即使原本鎖住某資源的 client crash 了或者出現(xiàn)了網(wǎng)絡(luò)分區(qū)；
• 容錯(cuò)性：只要大部分 Redis 節(jié)點(diǎn)存活就可以正常提供服務(wù)；

七、緩存異常

什么是Redis穿透？

一般的緩存系統(tǒng)，都是按照key去緩存查詢，如果不存在對(duì)應(yīng)的value，就應(yīng)該去后端系統(tǒng)查找（比如MySQL）。如果key對(duì)應(yīng)的value是一定不存在的，并且對(duì)該key并發(fā)請(qǐng)求量很大，就會(huì)對(duì)后端系統(tǒng)造成很大的壓力。

也就是說(shuō)，對(duì)不存在的key進(jìn)行高并發(fā)訪問(wèn)，導(dǎo)致數(shù)據(jù)庫(kù)壓力瞬間增大，這就叫做【緩存穿透】。

解決方案：

• 對(duì)查詢結(jié)果為空的情況也進(jìn)行緩存，緩存時(shí)間設(shè)置短一點(diǎn)。
• 該key對(duì)應(yīng)的數(shù)據(jù) insert 了之后清理緩存。
• 采用布隆過(guò)濾器，將所有可能存在的數(shù)據(jù)哈希到一個(gè)足夠大的 bitmap 中，一個(gè)一定不存在的數(shù)據(jù)會(huì)被這個(gè) bitmap 攔截掉，從而避免了對(duì)底層存儲(chǔ)系統(tǒng)的查詢壓力。

什么是Redis雪崩？

當(dāng)緩存服務(wù)器重啟或者大量緩存集中在某一個(gè)時(shí)間段失效，這樣在失效的時(shí)候，也會(huì)給后端系統(tǒng)(比如DB)帶來(lái)很大壓力。

突然間大量的key失效了或Redis重啟，大量訪問(wèn)數(shù)據(jù)庫(kù)而導(dǎo)致的系統(tǒng)壓力劇增問(wèn)題就是緩存雪崩啦。

解決方案:

1. key的失效期分散開(kāi)，不同的key設(shè)置不同的有效期；
2. 設(shè)置二級(jí)緩存；
3. 高可用方案，比如Redis集群，保證不會(huì)因?yàn)榫彺嫦到y(tǒng)崩潰而導(dǎo)致緩存雪崩；

什么是Redis緩存擊穿？

對(duì)于一些設(shè)置了過(guò)期時(shí)間的key，如果這些key可能會(huì)在某些時(shí)間點(diǎn)被超高并發(fā)地訪問(wèn)，是一種非?！盁狳c(diǎn)”的數(shù)據(jù)。這個(gè)時(shí)候，需要考慮一個(gè)問(wèn)題：緩存被“擊穿”的問(wèn)題，這個(gè)和緩存雪崩的區(qū)別在于這里針對(duì)某一key緩存，前者則是很多key。

緩存在某個(gè)時(shí)間點(diǎn)過(guò)期的時(shí)候，恰好在這個(gè)時(shí)間點(diǎn)對(duì)這個(gè)Key有大量的并發(fā)請(qǐng)求過(guò)來(lái)，這些請(qǐng)求發(fā)現(xiàn)緩存過(guò)期一般都會(huì)從后端DB加載數(shù)據(jù)并回設(shè)到緩存，這個(gè)時(shí)候大并發(fā)的請(qǐng)求可能會(huì)瞬間把后端DB壓垮。

解決方案：

1. 用分布式鎖控制訪問(wèn)的線程，如：使用redis的setnx互斥鎖先進(jìn)行判斷，這樣其他線程就處于等待狀態(tài)，保證不會(huì)有大并發(fā)操作去操作數(shù)據(jù)庫(kù)。

if(redis.sexnx()==1){
?//先查詢緩存?
?//查詢數(shù)據(jù)庫(kù)?
?//加入緩存?
}

緩存預(yù)熱

緩存預(yù)熱就是系統(tǒng)上線后，將相關(guān)的緩存數(shù)據(jù)直接加載到緩存系統(tǒng)。這樣就可以避免在用戶請(qǐng)求的時(shí)候，先查詢數(shù)據(jù)庫(kù)，然后再將數(shù)據(jù)緩存的問(wèn)題！用戶直接查詢事先被預(yù)熱的緩存數(shù)據(jù)！

解決方案

1. 直接寫個(gè)緩存刷新頁(yè)面，上線時(shí)手工操作一下；
2. 數(shù)據(jù)量不大，可以在項(xiàng)目啟動(dòng)的時(shí)候自動(dòng)進(jìn)行加載；
3. 定時(shí)刷新緩存；

緩存降級(jí)

當(dāng)訪問(wèn)量劇增、服務(wù)出現(xiàn)問(wèn)題（如響應(yīng)時(shí)間慢或不響應(yīng)）或非核心服務(wù)影響到核心流程的性能時(shí)，仍然需要保證服務(wù)還是可用的，即使是有損服務(wù)。系統(tǒng)可以根據(jù)一些關(guān)鍵數(shù)據(jù)進(jìn)行自動(dòng)降級(jí)，也可以配置開(kāi)關(guān)實(shí)現(xiàn)人工降級(jí)。

緩存降級(jí)的最終目的是保證核心服務(wù)可用，即使是有損的。而且有些服務(wù)是無(wú)法降級(jí)的（如加入購(gòu)物車、結(jié)算）。

在進(jìn)行降級(jí)之前要對(duì)系統(tǒng)進(jìn)行梳理，看看系統(tǒng)是不是可以丟卒保帥；從而梳理出哪些必須誓死保護(hù)，哪些可降級(jí)；比如可以參考日志級(jí)別設(shè)置預(yù)案：

• info：比如有些服務(wù)偶爾因?yàn)榫W(wǎng)絡(luò)抖動(dòng)或者服務(wù)正在上線而超時(shí)，可以自動(dòng)降級(jí)；

• warning：有些服務(wù)在一段時(shí)間內(nèi)成功率有波動(dòng)（如在95~100%之間），可以自動(dòng)降級(jí)或人工降級(jí)，并發(fā)送告警；

• error：比如可用率低于90%，或者數(shù)據(jù)庫(kù)連接池被打爆了，或者訪問(wèn)量突然猛增到系統(tǒng)能承受的最大閥值，此時(shí)可以根據(jù)情況自動(dòng)降級(jí)或者人工降級(jí)；

• fatal：比如因?yàn)樘厥庠驍?shù)據(jù)錯(cuò)誤了，此時(shí)需要緊急人工降級(jí)。

服務(wù)降級(jí)的目的，是為了防止Redis服務(wù)故障，導(dǎo)致數(shù)據(jù)庫(kù)跟著一起發(fā)生雪崩問(wèn)題。因此，對(duì)于不重要的緩存數(shù)據(jù)，可以采取服務(wù)降級(jí)策略，例如一個(gè)比較常見(jiàn)的做法就是，Redis出現(xiàn)問(wèn)題，不去數(shù)據(jù)庫(kù)查詢，而是直接返回默認(rèn)值給用戶。

熱點(diǎn)數(shù)據(jù)和冷數(shù)據(jù)

熱點(diǎn)數(shù)據(jù)，緩存才有價(jià)值。

• 對(duì)于冷數(shù)據(jù)而言，大部分?jǐn)?shù)據(jù)可能還沒(méi)有再次訪問(wèn)到就已經(jīng)被擠出內(nèi)存，不僅占用內(nèi)存，而且價(jià)值不大。頻繁修改的數(shù)據(jù)，看情況考慮使用緩存。

• 對(duì)于熱點(diǎn)數(shù)據(jù)，比如我們的某IM產(chǎn)品，生日祝福模塊，當(dāng)天的壽星列表，緩存以后可能讀取數(shù)十萬(wàn)次。再舉個(gè)例子，某導(dǎo)航產(chǎn)品，我們將導(dǎo)航信息，緩存以后可能讀取數(shù)百萬(wàn)次。

• 數(shù)據(jù)更新前至少讀取兩次，緩存才有意義。這個(gè)是最基本的策略，如果緩存還沒(méi)有起作用就失效了，那就沒(méi)有太大價(jià)值了。

• 那存不存在，修改頻率很高，但是又不得不考慮緩存的場(chǎng)景呢？有！比如，這個(gè)讀取接口對(duì)數(shù)據(jù)庫(kù)的壓力很大，但是又是熱點(diǎn)數(shù)據(jù)，這個(gè)時(shí)候就需要考慮通過(guò)緩存手段，減少數(shù)據(jù)庫(kù)的壓力，比如我們的微信公眾號(hào)助手，點(diǎn)贊數(shù)，收藏?cái)?shù)，分享數(shù)等是非常典型的熱點(diǎn)數(shù)據(jù)，但是又不斷變化，此時(shí)就需要將數(shù)據(jù)同步保存到Redis緩存，減少數(shù)據(jù)庫(kù)壓力。

八、常用工具

Redis支持的Java客戶端都有哪些？官方推薦用哪個(gè)？

Redisson、Jedis、lettuce等等，官方推薦使用Redisson。

Redis和Redisson有什么關(guān)系？

Redisson是一個(gè)高級(jí)的分布式協(xié)調(diào)Redis客服端，能幫助用戶在分布式環(huán)境中輕松實(shí)現(xiàn)一些Java的對(duì)象。

Jedis與Redisson對(duì)比有什么優(yōu)缺點(diǎn)？

Jedis是Redis的Java實(shí)現(xiàn)的客戶端，其API提供了比較全面的Redis命令的支持；Redisson實(shí)現(xiàn)了分布式和可擴(kuò)展的Java數(shù)據(jù)結(jié)構(gòu)，和Jedis相比，功能較為簡(jiǎn)單，不支持字符串操作，不支持排序、事務(wù)、管道、分區(qū)等Redis特性。Redisson的宗旨是促進(jìn)使用者對(duì)Redis的關(guān)注分離，從而讓使用者能夠?qū)⒕Ω械胤旁谔幚順I(yè)務(wù)邏輯上。

九、其他問(wèn)題

Redis與Memcached的區(qū)別

兩者都是非關(guān)系型內(nèi)存鍵值數(shù)據(jù)庫(kù)，現(xiàn)在公司一般都是用 Redis 來(lái)實(shí)現(xiàn)緩存，而且 Redis 自身也越來(lái)越強(qiáng)大了！Redis 與 Memcached 主要有以下不同：

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

2. Redis可以將長(zhǎng)時(shí)間不用的key落盤，Memcached的數(shù)據(jù)則會(huì)一直在內(nèi)存中，所以不適合存儲(chǔ)大量數(shù)據(jù)；

3. Redis可以持久化其數(shù)據(jù)；

如何保證緩存與數(shù)據(jù)庫(kù)雙寫時(shí)的數(shù)據(jù)一致性？

你只要用緩存，就可能會(huì)涉及到緩存與數(shù)據(jù)庫(kù)雙存儲(chǔ)雙寫，你只要是雙寫，就一定會(huì)有數(shù)據(jù)一致性的問(wèn)題，那么你如何解決一致性問(wèn)題？

一般來(lái)說(shuō)，就是如果你的系統(tǒng)不是嚴(yán)格要求緩存+數(shù)據(jù)庫(kù)必須一致性的話，緩存可以稍微的跟數(shù)據(jù)庫(kù)偶爾有不一致的情況，最好不要做這個(gè)方案，讀請(qǐng)求和寫請(qǐng)求串行化，串到一個(gè)內(nèi)存隊(duì)列里去，這樣就可以保證一定不會(huì)出現(xiàn)不一致的情況

串行化之后，就會(huì)導(dǎo)致系統(tǒng)的吞吐量會(huì)大幅度的降低，用比正常情況下多幾倍的機(jī)器去支撐線上的一個(gè)請(qǐng)求。

先來(lái)看下我們?nèi)粘５倪@些操作是如何造成雙鞋數(shù)據(jù)不一致的吧：

1. 先更新數(shù)據(jù)庫(kù)再更新緩存(不建議使用)；

操作步驟（線程A和線程B都對(duì)同一數(shù)據(jù)進(jìn)行更新操作）：

1. 線程A更新了數(shù)據(jù)庫(kù)
2. 線程B更新了數(shù)據(jù)庫(kù)
3. 線程B更新了緩存
4. 線程A更新了緩存

顯而易見(jiàn)，這面這種操作的問(wèn)題在于：臟讀、浪費(fèi)性能

2. 先更新數(shù)據(jù)庫(kù)再刪除緩存（推薦）；

操作步驟：

1. 請(qǐng)求A進(jìn)行寫操作，刪除緩存，此時(shí)A的還沒(méi)有刪除緩存
2. 請(qǐng)求B查詢到緩存中的舊值后返回
3. 請(qǐng)求A將緩存刪除成功
4. 請(qǐng)求C發(fā)現(xiàn)緩存為空去讀取數(shù)據(jù)庫(kù)中正確的值
5. 請(qǐng)求C根據(jù)數(shù)據(jù)到緩存

此方案，可以看到在步驟2會(huì)將舊值讀取到，最終造成臟讀，這種方案暫時(shí)產(chǎn)生不一致的情況，但是發(fā)生的幾率特別小。

3. 先刪除緩存再更新數(shù)據(jù)庫(kù)

操作步驟：

1. 用戶A刪除緩存失敗
2. 用戶A成功更新了數(shù)據(jù)

或者：

1. 用戶A刪除了緩存；
2. 用戶B讀取緩存，緩存不存在；
3. 用戶B從數(shù)據(jù)庫(kù)拿到舊數(shù)據(jù)；
4. 用戶B更新了緩存；
5. 用戶A更新了數(shù)據(jù)庫(kù);

按照上面的步驟，此方案也是會(huì)出現(xiàn)臟讀問(wèn)題，導(dǎo)致數(shù)據(jù)雙寫不一致而引發(fā)業(yè)務(wù)系統(tǒng)異常。

這里給出幾種解決方案：

• 解決方案1：設(shè)置緩存有效時(shí)間（最簡(jiǎn)單），在接受最終一致性的場(chǎng)景下，配置合理的失效時(shí)間。
• 解決方案2：使用消息隊(duì)列，例如rocketMq等消息隊(duì)列可以保證數(shù)據(jù)操作順序一致性，確保緩存系統(tǒng)的數(shù)據(jù)正常。

Redis官方為什么不提供Windows版本？

因?yàn)槟壳癓inux版本已經(jīng)相當(dāng)穩(wěn)定，而且用戶量很大，無(wú)需開(kāi)發(fā)windows版本，反而會(huì)帶來(lái)兼容性等問(wèn)題。

一個(gè)字符串類型的值能存儲(chǔ)最大容量是多少？

512M。

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

LRU算法。

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

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

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

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

使用Redis做過(guò)異步隊(duì)列嗎，是如何實(shí)現(xiàn)的

使用list類型保存數(shù)據(jù)信息，rpush生產(chǎn)消息，lpop消費(fèi)消息，當(dāng)lpop沒(méi)有消息時(shí)，可以sleep一段時(shí)間，然后再檢查有沒(méi)有信息，如果不想sleep的話，可以使用blpop, 在沒(méi)有信息的時(shí)候，會(huì)一直阻塞，直到信息的到來(lái)。redis可以通過(guò)pub/sub主題訂閱模式實(shí)現(xiàn)一個(gè)生產(chǎn)者，多個(gè)消費(fèi)者，當(dāng)然也存在一定的缺點(diǎn)，當(dāng)消費(fèi)者下線時(shí)，生產(chǎn)的消息會(huì)丟失。

Redis如何實(shí)現(xiàn)延時(shí)隊(duì)列

使用 sortedset，使用時(shí)間戳做score, 消息內(nèi)容作為key,調(diào)用zadd來(lái)生產(chǎn)消息，消費(fèi)者使用zrangbyscore獲取n秒之前的數(shù)據(jù)做輪詢處理。

好了，上面的問(wèn)題都過(guò)一遍，應(yīng)付面試中 Redis 相關(guān)的問(wèn)題基本上就穩(wěn)了。

關(guān)注公眾號(hào)：七哥聊編程，我們一起探討，幫助修改簡(jiǎn)歷、回答疑問(wèn)、項(xiàng)目分析，只為幫助迷茫的你高效斬獲心儀的 offer。

另外技術(shù) 讀者群 也開(kāi)通了，添加七哥個(gè)人微信回復(fù)：進(jìn)群，一起成長(zhǎng)交流。群里有騰訊、字節(jié)等大廠的大佬，也有在校學(xué)習(xí)的大學(xué)生，可以內(nèi)推哦 ~