前言

2023-07-27 22:44:59
出自B站 灰灰的Java面試

Redis

Redis為什么快？

1.純內存KV操作
Redis的操作都是基于內存的，CPU不是 Redis性能瓶頸,，Redis的瓶頸是機器內存和網絡帶寬。
在計算機的世界中，CPU的速度是遠大于內存的速度的，同時內存的速度也是遠大于硬盤的速度。redis的操作都是基于內存的，絕大部分請求是純粹的內存操作，非常迅速。

2.單線程操作
使用單線程可以省去多線程時CPU上下文會切換的時間，也不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有死鎖問題導致的性能消耗。對于內存系統來說，多次讀寫都是在一個CPU上，沒有上下文切換效率就是最高的！既然單線程容易實現，而且 CPU 不會成為瓶頸，那就順理成章的采用單線程的方案了
Redis 單線程指的是網絡請求模塊使用了一個線程，即一個線程處理所有網絡請求，其他模塊該使用多線程，仍會使用了多個線程。

3.I/O 多路復用
為什么 Redis 中要使用 I/O 多路復用這種技術呢？
首先，Redis 是跑在單線程中的，所有的操作都是按照順序線性執行的，但是由于讀寫操作等待用戶輸入或輸出都是阻塞的，所以 I/O 操作在一般情況下往往不能直接返回，這會導致某一文件的 I/O 阻塞導致整個進程無法對其它客戶提供服務，而 I/O 多路復用就是為了解決這個問題而出現的

4.Reactor 設計模式
Redis基于Reactor模式開發了自己的網絡事件處理器，稱之為文件事件處理器(File Event Hanlder)。

自己補充：
高效的操作：漸進式rehash、緩存時間戳

Redis合適的應用場景？

1、會話緩存（Session Cache）最常用的一種使用 Redis 的情景是會話緩存（sessioncache），用 Redis 緩存會話比其他存儲（如Memcached）的優勢在于：Redis 提供持久化。當維護一個不是嚴格要求一致性的緩存時，如果用戶的購物車信息全部丟失，大部分人都會不高興的，現在，他們還會這樣嗎？幸運的是，隨著 Redis 這些年的改進，很容易找到怎么恰當的使用 Redis 來緩存會話的文檔。甚至廣為人知的商業平臺 Magento 也提供 Redis 的插件。
2、全頁緩存（FPC）除基本的會話 token 之外，Redis 還提供很簡便的 FPC 平臺。回到一致性問題，即使重啟了 Redis 實例，因為有磁盤的持久化，用戶也不會看到頁面加載速度的下降，這是一個極大改進，類似 PHP 本地FPC。再次以 Magento 為例，Magento 提供一個插件來使用 Redis 作為全頁緩存后端。此外，對 WordPress 的用戶來說，Pantheon 有一個非常好的插件 wp-redis，這個插件能幫助你以最快速度加載你曾瀏覽過的頁面。
3、隊列Reids 在內存存儲引擎領域的一大優點是提供 list 和 set 操作，這使得 Redis 能作為一個很好的消息隊列平臺來使用。Redis 作為隊列使用的操作，就類似于本地程序語言（如 Python）對 list 的 push/pop操作。如果你快速的在 Google 中搜索“Redis queues”，你馬上就能找到大量的開源項目，這些項目的目的就是利用 Redis 創建非常好的后端工具，以滿足各種隊列需求。例如，Celery 有一個后臺就是使用Redis 作為 broker，你可以從這里去查看。
4、排行榜/計數器Redis 在內存中對數字進行遞增或遞減的操作實現的非常好。集合（Set）和有序集合（SortedSet）也使得我們在執行這些操作的時候變的非常簡單，Redis 只是正好提供了這兩種數據結構。微信搜索公眾號：Java專欄，獲取最新面試手冊所以，我們要從排序集合中獲取到排名最靠前的 10 個用戶–我們稱之為“user_scores”，我們只需要像下面一樣執行即可：當然，這是假定你是根據你用戶的分數做遞增的排序。如果你想返回用戶及用戶的分數，你需要這樣執行：ZRANGE user_scores 0 10 WITHSCORESAgora Games 就是一個很好的例子，用 Ruby 實現的，它的排行榜就是使用 Redis 來存儲數據的，你可以在這里看到。
5、發布/訂閱最后（但肯定不是最不重要的）是 Redis 的發布/訂閱功能。發布/訂閱的使用場景確實非常多。我已看見人們在社交網絡連接中使用，還可作為基于發布/訂閱的腳本觸發器，甚至用 Redis 的發布/訂閱功能來建立聊天系統！

Redis6.0之前為什么一直不使用多線程？

官方曾做過類似問題的回復：使用Redis時，幾乎不存在CPU成為瓶頸的情況，
Redis主要受限于內存和網絡。例如在一個普通的Linux系統上，Redis通過使用pipelining每秒可以處理100萬個請求，所以如果應用程序主要使用O(N)或O(log(N))的命令，它幾乎不會占用太多CPU。

使用了單線程后，可維護性高。多線程模型雖然在某些方面表現優異，但是它卻引入了程序執行順序的不確定性，帶來了并發讀寫的一系列問題，增加了系統復雜度、同時可能存在線程切換、甚至加鎖解鎖、死鎖造成的性能損耗。Redis通過AE事件模型以及IO多路復用等技術，處理性能非常高，因此沒有必要使用多線程。單線程機制使得 Redis 內部實現的復雜度大大降低，Hash 的惰性 Rehash、Lpush 等等,“線程不安全” 的命令都可以無鎖進行。

Redis6.0為什么要引入多線程？

Redis將所有數據放在內存中，內存的響應時長大約為100納秒，對于小數據包，Redis服務器可以處理80,000到100,000 QPS，這也是Redis處理的極限了，對于80%的公司來說，單線程的Redis已經足夠使用了。

但隨著越來越復雜的業務場景，有些公司動不動就上億的交易量，因此需要更大的QPS。常見的解決方案是在分布式架構中對數據進行分區并采用多個服務器，但該方案有非常大的缺點，例如要管理的Redis服務器太多，維護代價大；某些適用于單個Redis服務器的命令不適用于數據分區；數據分區無法解決熱點讀/寫問題；數據偏斜，重新分配和放大/縮小變得更加復雜等等。

Redis有哪些高級功能？

消息隊列、自動過期刪除、事務、數據持久化、分布式鎖、附近的人、慢查詢分析、Sentinel和集群等多項功能。

為什么要用Redis？

使用緩存的目的就是提升讀寫性能。而實際業務場景下，更多的是為了提升讀性能，帶來更好的性能，帶來更高的并發量。Redis的讀寫性能比Mysql好的多，我們就可以把Mysql中的熱點數據緩存到Redis中，提升讀取性能，同時也減輕了Mysql的讀取壓力

Redis與memcached相對有哪些優勢？

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

(2) redis的速度比memcached快很多

(3) redis可以持久化其數據

(4)Redis支持數據的備份，即master-slave模式的數據備份。

(5) 使用底層模型不同，它們之間底層實現方式 以及與客戶端之間通信的應用協議不一樣。Redis直接自己構建了VM 機制 ，因為一般的系統調用系統函數的話，會浪費一定的時間去移動和請求。

(6）value大小：redis最大可以達到1GB，而memcache只有1MB

怎么理解Redis中事務？

事務是一個單獨的隔離操作：事務中的所有命令都會序列化、按順序地執行，事務在執行的過程中，不會被其他客戶端發送來的命令請求所打斷。事務是一個原子操作：事務中的命令要么全部被執行，要么全部都不執行。不過Redis的是弱事物。
事務是Redis實現在服務器端的行為，用戶執行MULTI命令時，服務器會將對應這個用戶的客戶端對象設置為一個特殊的狀態，在這個狀態下后續用戶執行的查詢命令不會被真的執行，而是被服務器緩存起來，直到用戶執行EXEC命令為止，服務器會將這個用戶對應的客戶端對象中緩存的命令按照提交的順序依次執行。
Redis提供了簡單的事務，之所以說它簡單，主要是因為它不支持事務中的回滾特性,同時無法實現命令之間的邏輯關系計算，當然也體現了Redis 的“keep it simple”的特性

為什么要使用pipeline

Pipeline（流水線)機制能改善上面這類問題,它能將一組 Redis命令進行組裝,通過一次RTT傳輸給Redis,再將這組Redis命令的執行結果按順序返回給客戶端,沒有使用Pipeline執行了n條命令,整個過程需要n次RTT。

使用Pipeline 執行了n次命令，整個過程需要1次RTT。

Redis的過期策略以及內存淘汰機制？

redis采用的是定期刪除+惰性刪除策略。 為什么不用定時刪除策略? 定時刪除,用一個定時器來負責監視key,過期則自動刪除。雖然內存及時釋放，但是十分消耗CPU資源。在大并發請求下，CPU要將時間應用在處理請求，而不是刪除key,因此沒有采用這一策略. 定期刪除+惰性刪除是如何工作的呢? 定期刪除，redis默認每個100ms檢查，是否有過期的key,有過期key則刪除。需要說明的是，redis不是每個100ms將所有的key檢查一次，而是隨機抽取進行檢查(如果每隔100ms,全部key進行檢查，redis豈不是卡死)。因此，如果只采用定期刪除策略，會導致很多key到時間沒有刪除。 于是，惰性刪除派上用場。也就是說在你獲取某個key的時候，redis會檢查一下，這個key如果設置了過期時間那么是否過期了？如果過期了此時就會刪除
1.noeviction:返回錯誤當內存限制達到，并且客戶端嘗試執行會讓更多內存被使用的命令。
2.allkeys-lru: 嘗試回收最少使用的鍵（LRU），使得新添加的數據有空間存放。
3.volatile-lru: 嘗試回收最少使用的鍵（LRU），但僅限于在過期集合的鍵,使得新添加的數據有空間存放。
4.allkeys-random: 回收隨機的鍵使得新添加的數據有空間存放。
5.volatile-random: 回收隨機的鍵使得新添加的數據有空間存放，但僅限于在過期集合的鍵。
6.volatile-ttl: 回收在過期集合的鍵，并且優先回收存活時間（TTL）較短的鍵,使得新添加的數據有空間存放。

什么是緩存穿透？如何避免？

緩存穿透：指查詢一個一定不存在的數據，如果從存儲層查不到數據則不寫入緩存，這將導致這個不存在的數據每次請求都要到 DB 去查詢，可能導致 DB 掛掉。
解決方案：1.查詢返回的數據為空，仍把這個空結果進行緩存，但過期時間會比較短；2.布隆過濾器：將所有可能存在的數據哈希到一個足夠大的 bitmap 中，一個一定不存在的數據會被這個 bitmap 攔截掉，從而避免了對 DB 的查詢。

什么是緩存雪崩？如何避免？

緩存雪崩：設置緩存時采用了相同的過期時間，導致緩存在某一時刻同時失效，請求全部轉發到 DB，DB 瞬時壓力過重雪崩。與緩存擊穿的區別：雪崩是很多 key，擊穿是某一個key 緩存。
解決方案：將緩存失效時間分散開，比如可以在原有的失效時間基礎上增加一個隨機值，比如 1-5 分鐘隨機，這樣每一個緩存的過期時間的重復率就會降低，就很難引發集體失效的事件。

使用Redis如何設計分布式鎖？

基于 Redis 實現的分布式鎖，一個嚴謹的的流程如下：
1、加鎖
SET lock_key $unique_id EX $expire_time NX
2、操作共享資源
3、釋放鎖：Lua 腳本，先 GET 判斷鎖是否歸屬自己，再DEL 釋放鎖

怎么使用Redis實現消息隊列？

基于List的 LPUSH+BRPOP 的實現
足夠簡單，消費消息延遲幾乎為零，但是需要處理空閑連接的問題。
如果線程一直阻塞在那里，Redis客戶端的連接就成了閑置連接，閑置過久，服務器一般會主動斷開連接，減少閑置資源占用，這個時候blpop和brpop或拋出異常，所以在編寫客戶端消費者的時候要小心，如果捕獲到異常，還有重試。
其他缺點包括：
做消費者確認ACK麻煩，不能保證消費者消費消息后是否成功處理的問題（宕機或處理異常等），通常需要維護一個Pending列表，保證消息處理確認；不能做廣播模式，如pub/sub，消息發布/訂閱模型；不能重復消費，一旦消費就會被刪除；不支持分組消費。
基于Sorted-Set的實現
多用來實現延遲隊列，當然也可以實現有序的普通的消息隊列，但是消費者無法阻塞的獲取消息，只能輪詢，不允許重復消息。
PUB/SUB，訂閱/發布模式
優點：
典型的廣播模式，一個消息可以發布到多個消費者；多信道訂閱，消費者可以同時訂閱多個信道，從而接收多類消息；消息即時發送，消息不用等待消費者讀取，消費者會自動接收到信道發布的消息。
缺點：
消息一旦發布，不能接收。換句話就是發布時若客戶端不在線，則消息丟失，不能尋回；不能保證每個消費者接收的時間是一致的；若消費者客戶端出現消息積壓，到一定程度，會被強制斷開，導致消息意外丟失。通常發生在消息的生產遠大于消費速度時；可見，Pub/Sub 模式不適合做消息存儲，消息積壓類的業務，而是擅長處理廣播，即時通訊，即時反饋的業務。
基于Stream類型的實現
基本上已經有了一個消息中間件的雛形，可以考慮在生產過程中使用。

什么是bigkey？會有什么影響？

bigkey是指key對應的value所占的內存空間比較大，例如一個字符串類型的value可以最大存到512MB，一個列表類型的value最多可以存儲23-1個元素。
如果按照數據結構來細分的話，一般分為字符串類型bigkey和非字符串類型bigkey。
字符串類型：體現在單個value值很大，一般認為超過10KB就是bigkey，但這個值和具體的OPS相關。
非字符串類型：哈希、列表、集合、有序集合,體現在元素個數過多。
bigkey無論是空間復雜度和時間復雜度都不太友好，下面我們將介紹它的危害。
bigkey的危害
bigkey的危害體現在三個方面:
1、內存空間不均勻.(平衡):例如在Redis Cluster中，bigkey 會造成節點的內存空間使用不均勻。
2、超時阻塞:由于Redis單線程的特性，操作bigkey比較耗時，也就意味著阻塞Redis可能性增大。
3、網絡擁塞:每次獲取bigkey產生的網絡流量較大
假設一個bigkey為1MB，每秒訪問量為1000，那么每秒產生1000MB 的流量,對于普通的千兆網卡(按照字節算是128MB/s)的服務器來說簡直是滅頂之災，而且一般服務器會采用單機多實例的方式來部署,也就是說一個bigkey可能會對其他實例造成影響,其后果不堪設想。

Redis如何解決key沖突？

遇到hash沖突采用鏈表進行處理

怎么提高緩存命中率？

需要在業務需求，緩存粒度，緩存策略，技術選型等各個方面去通盤考慮并做權衡。盡可能的聚焦在高頻訪問且時效性要求不高的熱點業務上，通過緩存預加載（預熱）、增加存儲容量、調整緩存粒度、更新緩存等手段來提高命中率。

Redis持久化方式有哪些？有什么區別？

RDB、AOF、混合持久化。
RDB的優缺點：
優點：RDB持久化文件，速度比較快，而且存儲的是一個二進制文件，傳輸起來很方便。
缺點：RDB無法保證數據的絕對安全，有時候就是1s也會有很大的數據丟失。
AOF的優缺點：
優點：AOF相對RDB更加安全，一般不會有數據的丟失或者很少，官方推薦同時開啟AOF和RDB。
缺點：AOF持久化的速度，相對于RDB較慢，存儲的是一個文本文件，到了后期文件會比較大，傳輸困難。

為什么Redis需要把所有數據放到內存中？

Redis為了達到最快的讀寫速度,將數據都讀到內存中,并通過異步的方式將數據寫入磁盤,所以Redis具有快速和數據持久化的特征。如果不將數據放在內存中,磁盤I/O速度為嚴重影響Redis的性能。

如何保證緩存與數據庫雙寫時的數據一致性

第一種方案：采用延時雙刪策略
具體的步驟就是：
先刪除緩存；
再寫數據庫；
休眠500毫秒；
再次刪除緩存。
第二種方案：異步更新緩存(基于訂閱binlog的同步機制)
技術整體思路：
MySQL binlog增量訂閱消費+消息隊列+增量數據更新到redis

Redis集群方案應該怎么做？

1. Redis Sentinel體量較小時，選擇 Redis Sentinel，單主 Redis 足以支撐業務。
2. Redis ClusterRedis 官方提供的集群化方案，體量較大時，選擇 Redis Cluster，通過分片，使用更多內存。
3. TwemproxTwemprox是Twtter開源的一個 Redis和 Memcached 代理服務器，主要用于管理 Redis和Memcached 集群，減少與Cache 服務器直接連接的數量。
4. CodisCodis是一個代理中間件，當客戶端向Codis發送指令時，Codis負責將指令轉發到后面的Redis來執行，并將結果返回給客戶端。一個Codis實例可以連接多個Redis實例，也可以啟動多個Codis實例來支撐，每個Codis節點都是對等的，這樣可以增加整體的QPS需求，還能起到容災功能。
5. 客戶端分片在Redis Cluster還沒出現之前使用較多，現在基本很少熱你使用了，在業務代碼層實現，起幾個毫無關聯的Redis實例，在代碼層，對 Key 進行 hash 計算，然后去對應的 Redis實例操作數據。這種方式對 hash 層代碼要求比較高，考慮部分包括，節點失效后的替代算法方案，數據震蕩后的自動腳本恢復，實例的監控，等等。

Redis集群方案什么情況下會導致整個集群不可用？

1.當訪問一個 Master 和 Slave 節點都掛了的槽的時候，會報槽無法獲取。
2.當集群 Master 節點個數小于 3 個的時候，或者集群可用節點個數為偶數的時候，基于 fail 的這種選舉機制的自動主從切換過程可能會不能正常工作，一個是標記 fail 的過程，一個是選舉新的 master 的過程，都有可能異常。

說一說Redis哈希槽的概念？

slot：稱為哈希槽
Redis 集群中內置了 16384 個哈希槽，當需要在 Redis 集群中放置一個 key-value時，redis 先對 key 使用 crc16 算法算出一個結果，然后把結果對 16384 求余數，這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽，redis 會根據節點數量大致均等的將哈希槽映射到不同的節點。
使用哈希槽的好處就在于可以方便的添加或移除節點。
當需要增加節點時，只需要把其他節點的某些哈希槽挪到新節點就可以了；
當需要移除節點時，只需要把移除節點上的哈希槽挪到其他節點就行了；

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

以下情況可能導致寫操作丟失：
過期 key 被清理
最大內存不足，導致 Redis 自動清理部分 key 以節省空間
主庫故障后自動重啟，從庫自動同步
單獨的主備方案，網絡不穩定觸發哨兵的自動切換主從節點，切換期間會有數據丟失

Redis常見性能問題和解決方案有哪些？

一、緩存穿透：就是查詢一個壓根就不存在的數據，即緩存中沒有，數據庫中也沒有
解決方案：使用布隆過濾器，把數據先加載到布隆過濾器中，訪問前先判斷是否存在于布隆過濾器中，不存在代表這筆數據壓根就不存在。
缺點：布隆過濾器是不可變的，可能一開始過濾器和數據庫數據時一致的，后面數據庫數據變了，或變多或變少，而對應的布隆過濾器的數據也要改變，這時會比較麻煩。
二、緩存擊穿：數據庫中有，緩存中沒有。緩存擊穿實際就是一個并發問題，一般來說查詢數據，先查詢緩存，有直接返回，沒有再查詢數據庫并放到緩存中之后返回，但這種場景在并發情況下就會有問題，假設同時又100個請求執行上面
邏輯的代碼，則可能會出現多個請求都查詢數據庫，因為大家同時執行，都查到了緩存中沒有數據。
解決方案：加鎖。如果是單機部署，則可以使用JVM級別的鎖，如lock、synchronized。如果是集群部署，則需要使用分布式鎖，如基于redis、zookeeper、mysql等實現的分布式鎖。
三、緩存雪崩：大部分數據同時失效、過期，新的緩存又沒來，導致大量的請求都去訪問數據庫而導致的服務器壓力過大、宕機、系統崩潰。
解決方案：搭建高可用的redis集群，避免壓力集中于一個節點；緩存失效時間錯開，避免緩存同時失效而都去請求數據庫。

熱點數據和冷數據是什么

對于冷數據而言，大部分數據可能還沒有再次訪問到就已經被擠出內存，不僅占用內存，而且價值不 大。頻繁修改的數據，看情況考慮使用緩存 對于上面兩個例子，壽星列表、導航信息都存在一個特點，就是信息修改頻率不高，讀取通常非常高的 場景。
對于熱點數據，比如我們的某IM產品，生日祝福模塊，當天的壽星列表，緩存以后可能讀取數十萬次。 再舉個例子，某導航產品，我們將導航信息，緩存以后可能讀取數百萬次。

什么情況下可能會導致Redis阻塞？

數據集中過期
不合理地使用API或數據結構
CPU飽和
持久化阻塞

什么時候選擇Redis，什么時候選擇Memcached？

實際業務分析
如果業務中更加側重性能的?效性，對持久化要求不?，那么應該優先選擇 Memcached。
如果業務中對持久化有需求或者對數據涉及到存儲、排序等一系列復雜的操作，比如業務中有排?榜類應?、社交關系存儲、數據排重、實時配置等功能，那么應該優先選擇 Redis

Redis過期策略都有哪些？LRU算法知道嗎？

1.noeviction:返回錯誤當內存限制達到，并且客戶端嘗試執行會讓更多內存被使用的命令。
2.allkeys-lru: 嘗試回收最少使用的鍵（LRU），使得新添加的數據有空間存放。
3.volatile-lru: 嘗試回收最少使用的鍵（LRU），但僅限于在過期集合的鍵,使得新添加的數據有空間存放。
4.allkeys-random: 回收隨機的鍵使得新添加的數據有空間存放。
5.volatile-random: 回收隨機的鍵使得新添加的數據有空間存放，但僅限于在過期集合的鍵。
6.volatile-ttl: 回收在過期集合的鍵，并且優先回收存活時間（TTL）較短的鍵,使得新添加的數據有空間存放。