使用Redis的相關(guān)知識(shí)點(diǎn)有哪些

本篇內(nèi)容主要講解“使用Redis的相關(guān)知識(shí)點(diǎn)有哪些”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“使用Redis的相關(guān)知識(shí)點(diǎn)有哪些”吧!

1、使用redis有哪些好處？

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

2. 支持豐富數(shù)據(jù)類型，支持string，list，set，sorted set，hash

3. 支持事務(wù)，操作都是原子性，所謂的原子性就是對(duì)數(shù)據(jù)的更改要么全部執(zhí)行，要么全部不執(zhí)行

4. 豐富的特性：可用于緩存，消息，按key設(shè)置過(guò)期時(shí)間，過(guò)期后將會(huì)自動(dòng)刪除

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

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

2. redis的速度比memcached快很多

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

3、redis常見(jiàn)性能問(wèn)題和解決方案：

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

2. 如果數(shù)據(jù)比較重要，某個(gè)Slave開(kāi)啟AOF備份數(shù)據(jù)，策略設(shè)置為每秒同步一次

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

4. 盡量避免在壓力很大的主庫(kù)上增加從庫(kù)

5. 主從復(fù)制不要用圖狀結(jié)構(gòu)，用單向鏈表結(jié)構(gòu)更為穩(wěn)定，即：Master <- Slave1 <- Slave2 <- Slave3…

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

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

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

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

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

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

3. 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來(lái)緩存會(huì)話的文檔。甚至廣為人知的商業(yè)平臺(tái)Magento也提供Redis的插件。

（2）全頁(yè)緩存（FPC） 除基本的會(huì)話token之外，Redis還提供很簡(jiǎn)便的FPC平臺(tái)?；氐揭恢滦詥?wèn)題，即使重啟了Redis實(shí)例，因?yàn)橛写疟P的持久化，用戶也不會(huì)看到頁(yè)面加載速度的下降，這是一個(gè)極大改進(jìn)，類似PHP本地FPC。再次以Magento為例，Magento提供一個(gè)插件來(lái)使用Redis作為全頁(yè)緩存后端。此外，對(duì)WordPress的用戶來(lái)說(shuō)，Pantheon有一個(gè)非常好的插件 wp-redis，這個(gè)插件能幫助你以最快速度加載你曾瀏覽過(guò)的頁(yè)面。

（3）隊(duì)列 Reids在內(nèi)存存儲(chǔ)引擎領(lǐng)域的一大優(yōu)點(diǎn)是提供 list 和 set 操作，這使得Redis能作為一個(gè)很好的消息隊(duì)列平臺(tái)來(lái)使用。Redis作為隊(duì)列使用的操作，就類似于本地程序語(yǔ)言（如Python）對(duì) list 的 push/pop 操作。如果你快速的在Google中搜索“Redis queues”，你馬上就能找到大量的開(kāi)源項(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來(lái)存儲(chǔ)數(shù)據(jù)的，你可以在這里看到。

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

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

5、redis的一些其他特點(diǎn)

（1）Redis是單進(jìn)程單線程的 redis利用隊(duì)列技術(shù)將并發(fā)訪問(wèn)變?yōu)榇性L問(wèn)，消除了傳統(tǒng)數(shù)據(jù)庫(kù)串行控制的開(kāi)銷

（2）讀寫分離模型 通過(guò)增加Slave DB的數(shù)量，讀的性能可以線性增長(zhǎng)。為了避免Master DB的單點(diǎn)故障，集群一般都會(huì)采用兩臺(tái)Master DB做雙機(jī)熱備，所以整個(gè)集群的讀和寫的可用性都非常高。讀寫分離架構(gòu)的缺陷在于，不管是Master還是Slave，每個(gè)節(jié)點(diǎn)都必須保存完整的數(shù)據(jù)，如果在數(shù)據(jù)量很大的情況下，集群的擴(kuò)展能力還是受限于單個(gè)節(jié)點(diǎn)的存儲(chǔ)能力，而且對(duì)于Write-intensive類型的應(yīng)用，讀寫分離架構(gòu)并不適合。

（3）數(shù)據(jù)分片模型 為了解決讀寫分離模型的缺陷，可以將數(shù)據(jù)分片模型應(yīng)用進(jìn)來(lái)。可以將每個(gè)節(jié)點(diǎn)看成都是獨(dú)立的master，然后通過(guò)業(yè)務(wù)實(shí)現(xiàn)數(shù)據(jù)分片。結(jié)合上面兩種模型，可以將每個(gè)master設(shè)計(jì)成由一個(gè)master和多個(gè)slave組成的模型。

（4）Redis的回收策略

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

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

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

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

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

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

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

使用策略規(guī)則：

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

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

6、mySQL里有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ù)淘汰策略見(jiàn)上面一條

7、假如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)。

8、Redis 常見(jiàn)的性能問(wèn)題都有哪些？如何解決？

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

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

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

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

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

字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。

如果你是Redis中高級(jí)用戶，還需要加上下面幾種數(shù)據(jù)結(jié)構(gòu)HyperLogLog、Geo、Pub/Sub。

如果你說(shuō)還玩過(guò)Redis Module，像BloomFilter，RedisSearch，Redis-ML，面試官得眼睛就開(kāi)始發(fā)亮了。

10、使用過(guò)Redis分布式鎖么，它是什么回事？

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

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

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

11、使用過(guò)Redis做異步隊(duì)列么，你是怎么用的？

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

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

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

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

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

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

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

如果大量的key過(guò)期時(shí)間設(shè)置的過(guò)于集中，到過(guò)期的那個(gè)時(shí)間點(diǎn)，redis可能會(huì)出現(xiàn)短暫的卡頓現(xiàn)象。一般需要在時(shí)間上加一個(gè)隨機(jī)值，使得過(guò)期時(shí)間分散一些。

13、為什么Redis需要把所有數(shù)據(jù)放到內(nèi)存中？

Redis為了達(dá)到最快的讀寫速度將數(shù)據(jù)都讀到內(nèi)存中，并通過(guò)異步的方式將數(shù)據(jù)寫入磁盤。所以redis具有快速和數(shù)據(jù)持久化的特征。如果不將數(shù)據(jù)放在內(nèi)存中，磁盤I/O速度為嚴(yán)重影響redis的性能。在內(nèi)存越來(lái)越便宜的今天，redis將會(huì)越來(lái)越受歡迎。如果設(shè)置了最大使用的內(nèi)存，則數(shù)據(jù)已有記錄數(shù)達(dá)到內(nèi)存限值后不能繼續(xù)插入新值。

14、Redis 持久化機(jī)制

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

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

對(duì)方追問(wèn)bgsave的原理是什么？你給出兩個(gè)詞匯就可以了，fork和cow。fork是指redis通過(guò)創(chuàng)建子進(jìn)程來(lái)進(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)程分離開(kāi)來(lái)。

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

1. RDB持久化方式能夠在指定的時(shí)間間隔能對(duì)你的數(shù)據(jù)進(jìn)行快照存儲(chǔ)。

2. AOF持久化方式記錄每次對(duì)服務(wù)器寫的操作，當(dāng)服務(wù)器重啟的時(shí)候會(huì)重新執(zhí)行這些命令來(lái)恢復(fù)原始的數(shù)據(jù)，AOF命令以redis協(xié)議追加保存每次寫的操作到文件末尾。Redis還能對(duì)AOF文件進(jìn)行后臺(tái)重寫，使得AOF文件的體積不至于過(guò)大。

3. 如果你只希望你的數(shù)據(jù)在服務(wù)器運(yùn)行的時(shí)候存在，你也可以不使用任何持久化方式。

4. 你也可以同時(shí)開(kāi)啟兩種持久化方式， 在這種情況下， 當(dāng)redis重啟的時(shí)候會(huì)優(yōu)先載入AOF文件來(lái)恢復(fù)原始的數(shù)據(jù)，因?yàn)樵谕ǔＧ闆r下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整。

5. 最重要的事情是了解RDB和AOF持久化方式的不同，讓我們以RDB持久化方式開(kāi)始。

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

一般來(lái)說(shuō)， 如果想達(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。

17、Pipeline有什么好處，為什么要用pipeline？

可以將多次IO往返的時(shí)間縮減為一次，前提是pipeline執(zhí)行的指令之間沒(méi)有因果相關(guān)性。使用redis-benchmark進(jìn)行壓測(cè)的時(shí)候可以發(fā)現(xiàn)影響redis的QPS峰值的一個(gè)重要因素是pipeline批次指令的數(shù)目。

18、Redis的同步機(jī)制了解么？

Redis可以使用主從同步，從從同步。第一次同步時(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)行重放就完成了同步過(guò)程。

19、Redis 集群方案與實(shí)現(xiàn)

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

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

20、一個(gè)Redis實(shí)例最多能存放多少的keys？

List、Set、Sorted Set他們最多能存放多少元素？

理論上Redis可以處理多達(dá)232的keys，并且在實(shí)際中進(jìn)行了測(cè)試，每個(gè)實(shí)例至少存放了2億5千萬(wàn)的keys。我們正在測(cè)試一些較大的值。

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

換句話說(shuō)，Redis的存儲(chǔ)極限是系統(tǒng)中的可用內(nèi)存值。

21、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集群可以做到這樣。

到此，相信大家對(duì)“使用Redis的相關(guān)知識(shí)點(diǎn)有哪些”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！