乾貨分享，值得收藏：搞懂這些redis知識點，還怕幹不過面試官？

是數據結構而非類型

很多文章都會說，redis支持5種常用的數據類型，這其實是存在很大的歧義。redis裏存的都是二進制數據，其實就是字節數組（byte[]），這些字節數據是沒有數據類型的，只有把它們按照合理的格式解碼後，可以變成一個字符串，整數或對象，此時才具有數據類型。

• 這一點必須要記住。所以任何東西只要能轉化成字節數組（byte[]）的，都可以存到redis裏。管你是字符串、數字、對象、圖片、聲音、視頻、還是文件，只要變成byte數組。

• 因此redis裏的String指的並不是字符串，它其實表示的是一種最簡單的數據結構，即一個key只能對應一個value。這裏的key和value都是byte數組，只不過key一般是由一個字符串轉換成的byte數組，value則根據實際需要而定。

• 在特定情況下，對value也會有一些要求，比如要進行自增或自減操作，那value對應的byte數組必須要能被解碼成一個數字才行，否則會報錯。

• 那麼List這種數據結構，其實表示一個key可以對應多個value，且value之間是有先後順序的，value值可以重複。

• Set這種數據結構，表示一個key可以對應多個value，且value之間是沒有先後順序的，value值也不可以重複。

• Hash這種數據結構，表示一個key可以對應多個key-value對，此時這些key-value對之間的先後順序一般意義不大，這是一個按照名稱語義來訪問的數據結構，而非位置語義。

• Sorted Set這種數據結構，表示一個key可以對應多個value，value之間是有大小排序的，value值不可以重複。每個value都和一個浮點數相關聯，該浮點數叫score。元素排序規則是：先按score排序，再按value排序。

• 相信現在你對這5種數據結構有了更清晰的認識，那它們的對應命令對你來說就是小case了。

集羣帶來的問題與解決思路

• 集羣帶來的好處是顯而易見的，比如容量增加、處理能力增強，還可以按需要進行動態的擴容、縮容。但同時也會引入一些新的問題，至少會有下面這兩個。

• 一是數據分配：存數據時應該放到哪個節點上，取數據時應該去哪個節點上找。
  二是數據移動：集羣擴容，新增加節點時，該節點上的數據從何處來；集羣縮容，要剔除節點時，該節點上的數據往何處去。

• 上面這兩個問題有一個共同點就是，如何去描述和存儲數據與節點的映射關係。又因爲數據的位置是由key決定的，所以問題就演變爲如何建立起各個key和集羣所有節點的關聯關係。

• 集羣的節點是相對固定和少數的，雖然有增加節點和剔除節點。但集羣裏存儲的key，則是完全隨機、沒有規律、不可預測、數量龐多，還非常瑣碎。

• 這就好比一所大學和它的所有學生之間的關係。如果大學和學生直接掛鉤的話，一定會比較混亂。現實是它們之間又加入了好幾層，首先有院系，其次有專業，再者有年級，最後還有班級。經過這四層映射之後，關係就清爽很多了。

• 這其實是一個非常重要的結論，這個世界上沒有什麼問題是不能通過加入一層來解決的。如果有，那就再加入一層。計算機裏也是這樣的。

• redis在數據和節點之間又加入了一層，把這層稱爲槽（slot），因該槽主要和哈希有關，又叫哈希槽。

• 最後變成了，節點上放的是槽，槽裏放的是數據。槽解決的是粒度問題，相當於把粒度變大了，這樣便於數據移動。哈希解決的是映射問題，使用key的哈希值來計算所在的槽，便於數據分配。

• 可以這樣來理解，你的學習桌子上堆滿了書，亂的很，想找到某本書非常困難。於是你買了幾個大的收納箱，把這些書按照書名的長度放入不同的收納箱，然後把這些收納箱放到桌子上。

• 這樣就變成了，桌子上是收納箱，收納箱裏是書籍。這樣書籍移動很方便，搬起一個箱子就走了。尋找書籍也很方便，只要數一數書名的長度，去對應的箱子裏找就行了。

• 其實我們也沒做什麼，只是買了幾個箱子，按照某種規則把書裝入箱子。就這麼簡單的舉動，就徹底改變了原來一盤散沙的狀況。是不是有點小小的神奇呢。

• 一個集羣只能有16384個槽，編號0-16383。這些槽會分配給集羣中的所有主節點，分配策略沒有要求。可以指定哪些編號的槽分配給哪個主節點。集羣會記錄節點和槽的對應關係。

• 接下來就需要對key求哈希值，然後對16384取餘，餘數是幾key就落入對應的槽裏。slot = CRC16(key) % 16384。

• 以槽爲單位移動數據，因爲槽的數目是固定的，處理起來比較容易，這樣數據移動問題就解決了。

• 使用哈希函數計算出key的哈希值，這樣就可以算出它對應的槽，然後利用集羣存儲的槽和節點的映射關係查詢出槽所在的節點，於是數據和節點就映射起來了，這樣數據分配問題就解決了。

• 我想說的是，一般的人只會去學習各種技術，高手更在乎如何跳出技術，尋求一種解決方案或思路方向，順着這個方向走下去，八九不離十能找到你想要的答案。

集羣對命令操作的取捨

• 客戶端只要和集羣中的一個節點建立鏈接後，就可以獲取到整個集羣的所有節點信息。此外還會獲取所有哈希槽和節點的對應關係信息，這些信息數據都會在客戶端緩存起來，因爲這些信息相當有用。

• 客戶端可以向任何節點發送請求，那麼拿到一個key後到底該向哪個節點發請求呢？其實就是把集羣裏的那套key和節點的映射關係理論搬到客戶端來就行了。

• 所以客戶端需要實現一個和集羣端一樣的哈希函數，先計算出key的哈希值，然後再對16384取餘，這樣就找到了該key對應的哈希槽，利用客戶端緩存的槽和節點的對應關係信息，就可以找到該key對應的節點了。

• 接下來發送請求就可以了。還可以把key和節點的映射關係緩存起來，下次再請求該key時，直接就拿到了它對應的節點，不用再計算一遍了。

• 理論和現實總是有差距的，集羣已經發生了變化，客戶端的緩存還沒來得及更新。肯定會出現拿到一個key向對應的節點發請求，其實這個key已經不在那個節點上了。此時這個節點應該怎麼辦？

• 這個節點可以去key實際所在的節點上拿到數據再返回給客戶端，也可以直接告訴客戶端key已經不在我這裏了，同時附上key現在所在的節點信息，讓客戶端再去請求一次，類似於HTTP的302重定向。

• 這其實是個選擇問題，也是個哲學問題。結果就是redis集羣選擇了後者。因此，節點只處理自己擁有的key，對於不擁有的key將返回重定向錯誤，即-MOVED key 127.0.0.1:6381，客戶端重新向這個新節點發送請求。

• 所以說選擇是一種哲學，也是個智慧。稍後再談這個問題。先來看看另一個情況，和這個問題有些相同點。

• redis有一種命令可以一次帶多個key，如MGET，我把這些稱爲多key命令。這個多key命令的請求被髮送到一個節點上，這裏有一個潛在的問題，不知道大家有沒有想到，就是這個命令裏的多個key一定都位於那同一個節點上嗎？

• 就分爲兩種情況了，如果多個key不在同一個節點上，此時節點只能返回重定向錯誤了，但是多個key完全可能位於多個不同的節點上，此時返回的重定向錯誤就會非常亂，所以redis集羣選擇不支持此種情況。

• 如果多個key位於同一個節點上呢，理論上是沒有問題的，redis集羣是否支持就和redis的版本有關係了，具體使用時自己測試一下就行了。

• 在這個過程中我們發現了一件頗有意義的事情，就是讓一組相關的key映射到同一個節點上是非常有必要的，這樣可以提高效率，通過多key命令一次獲取多個值。

• 那麼問題來了，如何給這些key起名字才能讓他們落到同一個節點上，難不成都要先計算個哈希值，再取個餘數，太麻煩了吧。當然不是這樣了，redis已經幫我們想好了。

• 可以來簡單推理下，要想讓兩個key位於同一個節點上，它們的哈希值必須要一樣。要想哈希值一樣，傳入哈希函數的字符串必須一樣。那我們只能傳進去兩個一模一樣的字符串了，那不就變成同一個key了，後面的會覆蓋前面的數據。

• 這裏的問題是我們都是拿整個key去計算哈希值，這就導致key和參與計算哈希值的字符串耦合了，需要將它們解耦才行，就是key和參與計算哈希值的字符串有關但是又不一樣。

• redis基於這個原理爲我們提供了方案，叫做key哈希標籤。先看例子，{user1000}.following，{user1000}.followers，相信你已經看出了門道，就是僅使用Key中的位於{和}間的字符串參與計算哈希值。

• 這樣可以保證哈希值相同，落到相同的節點上。但是key又是不同的，不會互相覆蓋。使用哈希標籤把一組相關的key關聯了起來，問題就這樣被輕鬆愉快地解決了。

• 相信你已經發現了，要解決問題靠的是巧妙的奇思妙想，而不是非要用牛逼的技術牛逼的算法。這就是小強，小而強大。

• 最後再來談選擇的哲學。redis的核心就是以最快的速度進行常用數據結構的key/value存取，以及圍繞這些數據結構的運算。對於與核心無關的或會拖累核心的都選擇弱化處理或不處理，這樣做是爲了保證核心的簡單、快速和穩定。

• 其實就是在廣度和深度面前，redis選擇了深度。所以節點不去處理自己不擁有的key，集羣不去支持多key命令。這樣一方面可以快速地響應客戶端，另一方面可以避免在集羣內部有大量的數據傳輸與合併。

單線程模型

• redis集羣的每個節點裏只有一個線程負責接受和執行所有客戶端發送的請求。技術上使用多路複用I/O，使用Linux的epoll函數，這樣一個線程就可以管理很多socket連接。

除此之外，選擇單線程還有以下這些原因：

1、redis都是對內存的操作，速度極快（10W+QPS）

2、整體的時間主要都是消耗在了網絡的傳輸上

3、如果使用了多線程，則需要多線程同步，這樣實現起來會變的複雜

4、線程的加鎖時間甚至都超過了對內存操作的時間

5、多線程上下文頻繁的切換需要消耗更多的CPU時間

6、還有就是單線程天然支持原子操作，而且單線程的代碼寫起來更簡單

事務

事務大家都知道，就是把多個操作捆綁在一起，要麼都執行（成功了），要麼一個也不執行（回滾了）。redis也是支持事務的，但可能和你想要的不太一樣，一起來看看吧。

• redis的事務可以分爲兩步，定義事務和執行事務。使用multi命令開啓一個事務，然後把要執行的所有命令都依次排上去。這就定義好了一個事務。此時使用exec命令來執行這個事務，或使用discard命令來放棄這個事務。

• 你可能希望在你的事務開始前，你關心的key不想被別人操作，那麼可以使用watch命令來監視這些key，如果開始執行前這些key被其它命令操作了則會取消事務的。也可以使用unwatch命令來取消對這些key的監視。

redis事務具有以下特點：

1、如果開始執行事務前出錯，則所有命令都不執行

2、一旦開始，則保證所有命令一次性按順序執行完而不被打斷

3、如果執行過程中遇到錯誤，會繼續執行下去，不會停止的

4、對於執行過程中遇到錯誤，是不會進行回滾的

看完這些，真想問一句話，你這能叫事務嗎？很顯然，這並不是我們通常認爲的事務，因爲它連原子性都保證不了。保證不了原子性是因爲redis不支持回滾，不過它也給出了不支持的理由。

不支持回滾的理由：

1、redis認爲，失敗都是由命令使用不當造成

2、redis這樣做，是爲了保持內部實現簡單快速

3、redis還認爲，回滾並不能解決所有問題

哈哈，這就是霸王條款，因此，好像使用redis事務的不太多

管道

• 客戶端和集羣的交互過程是串行化阻塞式的，即客戶端發送了一個命令後必須等到響應回來後才能發第二個命令，這一來一回就是一個往返時間。如果你有很多的命令，都這樣一個一個的來進行，會變得很慢。

• redis提供了一種管道技術，可以讓客戶端一次發送多個命令，期間不需要等待服務器端的響應，等所有的命令都發完了，再依次接收這些命令的全部響應。這就極大地節省了許多時間，提升了效率。

• 聰明的你是不是意識到了另外一個問題，多個命令就是多個key啊，這不就是上面提到的多key操作嘛，那麼問題來了，你如何保證這多個key都是同一個節點上的啊，哈哈，redis集羣又放棄了對管道的支持。

• 不過可以在客戶端模擬實現，就是使用多個連接往多個節點同時發送命令，然後等待所有的節點都返回了響應，再把它們按照發送命令的順序整理好，返回給用戶代碼。哎呀，好麻煩呀。

協議

簡單瞭解下redis的協議，知道redis的數據傳輸格式。

發送請求的協議：

• 參數個數CRLF[圖片上傳失敗…(image-db6153-1582806589792)]

  參數N的字節數CRLF參數N的數據CRLF

例如，SET name lixinjie，實際發送的數據是：

*3\r\n$3\r\nSET\r\n$4\r\nname\r\n$8\r\nlixinjie\r\n

接受響應的協議：

• 單行回覆，第一個字節是+

• 錯誤消息，第一個字節是-

• 整型數字，第一個字節是:

• 批量回復，第一個字節是$

• 多個批量回復，第一個字節是*

例如，

+OK\r\n

-ERR Operation against\r\n

:1000\r\n

$6\r\nfoobar\r\n

*2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n

可見redis的協議設計的非常簡單。

Redis面試真題分享

文章篇幅問題，我這裏只解析部分題目，，如有需要全部答案的可以關注我的公衆號【風平浪靜如碼】點資料領取獲取，另外我也整理出了全套Java面試題解析PDF版，有需要也可以進公衆號獲取！

1、什麼是 Redis？

Redis 本質上是一個 Key-Value 類型的內存數據庫，很像 memcached，整個數據庫統統加載在內存當中進行操作，定期通過異步操作把數據庫數據 flush 到硬盤上進行保存。因爲是純內存操作，Redis 的性能非常出色，每秒可以處理超過 10 萬次讀寫操作，是已知性能最快的 Key-Value DB。
Redis 的出色之處不僅僅是性能，Redis 最大的魅力是支持保存多種數據結構，此外單個value 的最大限制是 1GB，不像 memcached 只能保存 1MB 的數據，因此 Redis 可以用來實現很多有用的功能，比方說用他的 List 來做 FIFO 雙向鏈表，實現一個輕量級的高性 能消息隊列服務，用他的 Set 可以做高性能的 tag 系統等等。另外 Redis 也可以對存入的Key-Value 設置 expire 時間，因此也可以被當作一 個功能加強版的 memcached 來用。Redis 的主要缺點是數據庫容量受到物理內存的限制，不能用作海量數據的高性能讀寫，因此 Redis 適合的場景主要侷限在較小數據量的高性能操作和運算上。

2、Redis 相比 memcached 有哪些優勢？

1. memcached 所有的值均是簡單的字符串，Redis 作爲其替代者，支持更爲豐富的數據類
   型
2. Redis 的速度比 memcached 快很多
3. Redis 可以持久化其數據

3、Redis 支持哪幾種數據類型？

String、List、Set、Sorted Set、hashes

4、Redis 主要消耗什麼物理資源？

內存。

5、Redis 的全稱是什麼？

Remote Dictionary Server。

6、Redis 有哪幾種數據淘汰策略？

noeviction:返回錯誤當內存限制達到並且客戶端嘗試執行會讓更多內存被使用的命令（大部分的寫入指令，但 DEL 和幾個例外）
allkeys-lru: 嘗試回收最少使用的鍵（LRU），使得新添加的數據有空間存放。
volatile-lru: 嘗試回收最少使用的鍵（LRU），但僅限於在過期集合的鍵,使得新添加的數據有空間存放。
allkeys-random: 回收隨機的鍵使得新添加的數據有空間存放。
volatile-random: 回收隨機的鍵使得新添加的數據有空間存放，但僅限於在過期集合的鍵。
volatile-ttl: 回收在過期集合的鍵，並且優先回收存活時間（TTL）較短的鍵,使得新添加的數據有空間存放。

7、Redis 官方爲什麼不提供 Windows 版本？

因爲目前 Linux 版本已經相當穩定，而且用戶量很大，無需開發 windows 版本，反而會帶來兼容性等問題。

8、一個字符串類型的值能存儲最大容量是多少？

512M

9、爲什麼 Redis 需要把所有數據放到內存中？

Redis 爲了達到最快的讀寫速度將數據都讀到內存中，並通過異步的方式將數據寫入磁盤。
所以 Redis 具有快速和數據持久化的特徵。如果不將數據放在內存中，磁盤 I/O 速度爲嚴重影響 Redis 的性能。在內存越來越便宜的今天，Redis 將會越來越受歡迎。
如果設置了最大使用的內存，則數據已有記錄數達到內存限值後不能繼續插入新值。

10、Redis 集羣方案應該怎麼做？都有哪些方案？

1. twemproxy，大概概念是，它類似於一個代理方式，使用方法和普通 Redis 無任何區別，設置好它下屬的多個 Redis 實例後，使用時在本需要連接 Redis 的地方改爲連接twemproxy，它會以一個代理的身份接收請求並使用一致性 hash 算法，將請求轉接到具體 Redis，將結果再返回 twemproxy。使用方式簡便(相對 Redis 只需修改連接端口)，對舊項目擴展的首選。 問題：twemproxy 自身單端口實例的壓力，使用一致性 hash 後，對Redis 節點數量改變時候的計算值的改變，數據無法自動移動到新的節點。
2. codis，目前用的最多的集羣方案，基本和 twemproxy 一致的效果，但它支持在 節點數量改變情況下，舊節點數據可恢復到新 hash 節點。
3. Redis cluster3.0 自帶的集羣，特點在於他的分佈式算法不是一致性 hash，而是 hash槽的概念，以及自身支持節點設置從節點。具體看官方文檔介紹。
4. 在業務代碼層實現，起幾個毫無關聯的 Redis 實例，在代碼層，對 key 進行 hash 計算，然後去對應的 Redis 實例操作數據。 這種方式對 hash 層代碼要求比較高，考慮部分包括，節點失效後的替代算法方案，數據震盪後的自動腳本恢復，實例的監控，等等。

11、Redis 集羣方案什麼情況下會導致整個集羣不可用？

有 A，B，C 三個節點的集羣,在沒有複製模型的情況下,如果節點 B 失敗了，那麼整個集羣就會以爲缺少 5501-11000 這個範圍的槽而不可用。

12、MySQL 裏有 2000w 數據，Redis 中只存 20w 的數據，如何保證 Redis 中的數據都是熱點數據？

Redis 內存數據集大小上升到一定大小的時候，就會施行數據淘汰策略。

13、Redis 有哪些適合的場景？

• （1）、會話緩存（Session Cache）
  最常用的一種使用 Redis 的情景是會話緩存（session cache）。用 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 只是正好提供了這兩種數據結構。所以，我們要從排序集合中獲取到排名最靠前的 10 個用戶–我們稱之爲“user_scores”，我們只需要像下面一樣執行即可：
  當然，這是假定你是根據你用戶的分數做遞增的排序。如果你想返回用戶及用戶的分數，你需要這樣執行：
  ZRANGE user_scores 0 10 WITHSCORESAgora Games 就是一個很好的例子，用 Ruby 實現的，它的排行榜就是使用 Redis 來存儲數據的，你可以在這裏看到。
• （5）、發佈/訂閱
  最後（但肯定不是最不重要的）是 Redis 的發佈/訂閱功能。發佈/訂閱的使用場景確實非常多。我已看見人們在社交網絡連接中使用，還可作爲基於發佈/訂閱的腳本觸發器，甚至用 Redis 的發佈/訂閱功能來建立聊天系統！（不，這是真的，你可以去核實）。

14、Redis 支持的 Java 客戶端都有哪些？官方推薦用哪個？

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

15、Redis 和 Redisson 有什麼關係？

Redisson 是一個高級的分佈式協調 Redis 客服端，能幫助用戶在分佈式環境中輕鬆實現一些 Java 的對象 (Bloom filter, BitSet, Set, SetMultimap, ScoredSortedSet, SortedSet, Map, ConcurrentMap, List,ListMultimap, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, ReadWriteLock,AtomicLong, CountDownLatch, Publish / Subscribe, HyperLogLog)。

16、Jedis 與 Redisson 對比有什麼優缺點？

Jedis 是 Redis 的 Java 實現的客戶端，其 API 提供了比較全面的 Redis 命令的支持；Redisson 實現了分佈式和可擴展的 Java 數據結構，和 Jedis 相比，功能較爲簡單，不支持字符串操作，不支持排序、事務、管道、分區等 Redis 特性。Redisson 的宗旨是促進使用者對 Redis 的關注分離，從而讓使用者能夠將精力更集中地放在處理業務邏輯上。

17、Redis 如何設置密碼及驗證密碼？

設置密碼：config set requirepass 123456
授權密碼：auth 123456

18、說說 Redis 哈希槽的概念？

Redis 集羣沒有使用一致性 hash,而是引入了哈希槽的概念，Redis 集羣有 16384 個哈希槽，每個 key 通過 CRC16 校驗後對 16384 取模來決定放置哪個槽，集羣的每個節點負責一部分hash 槽。

19、Redis 集羣的主從複製模型是怎樣的？

爲了使在部分節點失敗或者大部分節點無法通信的情況下集羣仍然可用，所以集羣使用了主從複製模型,每個節點都會有 N-1 個複製品.

20、Redis 集羣會有寫操作丟失嗎？爲什麼？

Redis 並不能保證數據的強一致性，這意味這在實際中集羣在特定的條件下可能會丟失寫操作。

21、Redis 集羣之間是如何複製的？

22、Redis 集羣最大節點個數是多少？

23、Redis 集羣如何選擇數據庫？

24、怎麼測試 Redis 的連通性？

25、Redis 中的管道有什麼用？

26、怎麼理解 Redis 事務？

27、Redis 事務相關的命令有哪幾個？

28、Redis key 的過期時間和永久有效分別怎麼設置？

29、Redis 如何做內存優化？

30、Redis 回收進程如何工作的？

31、Redis 回收使用的是什麼算法？

32、Redis 如何做大量數據插入？

33、爲什麼要做 Redis 分區？

34、你知道有哪些 Redis 分區實現方案？

35、Redis 分區有什麼缺點？

36、Redis 持久化數據和緩存怎麼做擴容？

37、分佈式 Redis 是前期做還是後期規模上來了再做好？爲什麼？

38、Twemproxy 是什麼？

39、支持一致性哈希的客戶端有哪些？

40、Redis 與其他 key-value 存儲有什麼不同？

41、Redis 的內存佔用情況怎麼樣？

42、都有哪些辦法可以降低 Redis 的內存使用情況呢？

43、查看 Redis 使用情況及狀態信息用什麼命令？

44、Redis 的內存用完了會發生什麼？

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

46、一個 Redis 實例最多能存放多少的 keys？List、Set、Sorted Set 他們最多能存放多少元素？

47、Redis 常見性能問題和解決方案？

48、Redis 提供了哪幾種持久化方式？

49、如何選擇合適的持久化方式？

50、修改配置不重啓 Redis 會實時生效嗎？

文章篇幅問題，我這裏只解析部分題目，，如有需要全部答案的可以關注我的公衆號【風平浪靜如碼】點資料領取獲取，另外我也整理出了全套Java面試題解析PDF版，有需要也可以進公衆號獲取！

覺得寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！