乾貨分享，值得收藏：搞懂這些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版，有需要也可以進公眾號獲取！

部分資料圖分享

寫在最後：

歡迎大家關注我新開通的公眾號【風平浪靜如碼】，海量Java相關文章，學習資料都會在裡面更新，整理的資料也會放在裡面。

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