1.Redis 是一個基于內(nèi)存的高性能key-value數(shù)據(jù)庫。

2.Redis相比memcached有哪些優(yōu)勢：

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

• redis的速度比memcached快很多

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

3.Redis是單線程

redis利用隊列技術(shù)將并發(fā)訪問變?yōu)榇性L問，消除了傳統(tǒng)數(shù)據(jù)庫串行控制的開銷

4.Reids常用5種數(shù)據(jù)類型

• string，list，set，sorted set，hash

6.Reids6種淘汰策略：

• noeviction: 不刪除策略, 達(dá)到最大內(nèi)存限制時, 如果需要更多內(nèi)存, 直接返回錯誤信息。大多數(shù)寫命令都會導(dǎo)致占用更多的內(nèi)存(有極少數(shù)會例外。

• **allkeys-lru:**所有key通用; 優(yōu)先刪除最近最少使用(less recently used ,LRU) 的 key。

• **volatile-lru:**只限于設(shè)置了 expire 的部分; 優(yōu)先刪除最近最少使用(less recently used ,LRU) 的 key。

• **allkeys-random:**所有key通用; 隨機(jī)刪除一部分 key。

• volatile-random: 只限于設(shè)置了 expire 的部分; 隨機(jī)刪除一部分 key。

• volatile-ttl: 只限于設(shè)置了 expire 的部分; 優(yōu)先刪除剩余時間(time to live,TTL) 短的key。

7.Redis的并發(fā)競爭問題如何解決?

單進(jìn)程單線程模式，采用隊列模式將并發(fā)訪問變?yōu)榇性L問。Redis本身沒有鎖的概念，Redis對于多個客戶端連接并不存在競爭，利用setnx實現(xiàn)鎖。

8.Redis是使用c語言開發(fā)的。

9.Redis前端啟動命令

./redis-server

10.Reids支持的語言：

java、C、C#、C++、php、Node.js、Go等。

11.Redis 持久化方案：

Rdb 和 Aof

12.Redis 的主從復(fù)制

持久化保證了即使redis服務(wù)重啟也不會丟失數(shù)據(jù)，因為redis服務(wù)重啟后會將硬盤上持久化的數(shù)據(jù)恢復(fù)到內(nèi)存中，但是當(dāng)redis服務(wù)器的硬盤損壞了可能會導(dǎo)致數(shù)據(jù)丟失，如果通過redis的主從復(fù)制機(jī)制就可以避免這種單點故障，

13.Redis是單線程的，但Redis為什么這么快？

1、完全基于內(nèi)存，絕大部分請求是純粹的內(nèi)存操作，非常快速。數(shù)據(jù)存在內(nèi)存中，類似于HashMap，HashMap的優(yōu)勢就是查找和操作的時間復(fù)雜度都是O(1)；

2、數(shù)據(jù)結(jié)構(gòu)簡單，對數(shù)據(jù)操作也簡單，Redis中的數(shù)據(jù)結(jié)構(gòu)是專門進(jìn)行設(shè)計的；

3、采用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進(jìn)程或者多線程導(dǎo)致的切換而消耗 CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現(xiàn)死鎖而導(dǎo)致的性能消耗；

4、使用多路I/O復(fù)用模型，非阻塞IO；這里“多路”指的是多個網(wǎng)絡(luò)連接，“復(fù)用”指的是復(fù)用同一個線程

5、使用底層模型不同，它們之間底層實現(xiàn)方式以及與客戶端之間通信的應(yīng)用協(xié)議不一樣，Redis直接自己構(gòu)建了VM 機(jī)制 ，因為一般的系統(tǒng)調(diào)用系統(tǒng)函數(shù)的話，會浪費一定的時間去移動和請求；

14.為什么Redis是單線程的？

Redis是基于內(nèi)存的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機(jī)器內(nèi)存的大小或者網(wǎng)絡(luò)帶寬。既然單線程容易實現(xiàn)，而且CPU不會成為瓶頸，那就順理成章地采用單線程的方案了（畢竟采用多線程會有很多麻煩！）。

15.Redis info查看命令：info memory

16.Redis內(nèi)存模型

used_memory：Redis分配器分配的內(nèi)存總量（單位是字節(jié)），包括使用的虛擬內(nèi)存（即swap）；Redis分配器后面會介紹。used_memory_human只是顯示更友好。

used_memory_rss**：**Redis進(jìn)程占據(jù)操作系統(tǒng)的內(nèi)存（單位是字節(jié)），與top及ps命令看到的值是一致的；除了分配器分配的內(nèi)存之外，used_memory_rss還包括進(jìn)程運行本身需要的內(nèi)存、內(nèi)存碎片等，但是不包括虛擬內(nèi)存。

mem_fragmentation_ratio**：**內(nèi)存碎片比率，該值是used_memory_rss / used_memory的比值。

mem_allocator**：**Redis使用的內(nèi)存分配器，在編譯時指定；可以是 libc 、jemalloc或者tcmalloc，默認(rèn)是jemalloc；截圖中使用的便是默認(rèn)的jemalloc。

17.Redis內(nèi)存劃分

數(shù)據(jù)

作為數(shù)據(jù)庫，數(shù)據(jù)是最主要的部分；這部分占用的內(nèi)存會統(tǒng)計在used_memory中。

進(jìn)程本身運行需要的內(nèi)存

Redis主進(jìn)程本身運行肯定需要占用內(nèi)存，如代碼、常量池等等；這部分內(nèi)存大約幾兆，在大多數(shù)生產(chǎn)環(huán)境中與Redis數(shù)據(jù)占用的內(nèi)存相比可以忽略。這部分內(nèi)存不是由jemalloc分配，因此不會統(tǒng)計在used_memory中。

緩沖內(nèi)存

緩沖內(nèi)存包括客戶端緩沖區(qū)、復(fù)制積壓緩沖區(qū)、AOF緩沖區(qū)等；其中，客戶端緩沖存儲客戶端連接的輸入輸出緩沖；復(fù)制積壓緩沖用于部分復(fù)制功能；AOF緩沖區(qū)用于在進(jìn)行AOF重寫時，保存最近的寫入命令。在了解相應(yīng)功能之前，不需要知道這些緩沖的細(xì)節(jié)；這部分內(nèi)存由jemalloc分配，因此會統(tǒng)計在used_memory中。

內(nèi)存碎片

內(nèi)存碎片是Redis在分配、回收物理內(nèi)存過程中產(chǎn)生的。例如，如果對數(shù)據(jù)的更改頻繁，而且數(shù)據(jù)之間的大小相差很大，可能導(dǎo)致redis釋放的空間在物理內(nèi)存中并沒有釋放，但redis又無法有效利用，這就形成了內(nèi)存碎片。內(nèi)存碎片不會統(tǒng)計在used_memory中。

18.Redis對象有5種類型

無論是哪種類型，Redis都不會直接存儲，而是通過redisObject對象進(jìn)行存儲。

19.Redis沒有直接使用C字符串

(即以空字符’\0’結(jié)尾的字符數(shù)組)作為默認(rèn)的字符串表示，而是使用了SDS。SDS是簡單動態(tài)字符串(Simple Dynamic String)的縮寫。

20.Reidis的SDS在C字符串的基礎(chǔ)上加入了free和len字段

21.Reids主從復(fù)制

復(fù)制是高可用Redis的基礎(chǔ)，哨兵和集群都是在復(fù)制基礎(chǔ)上實現(xiàn)高可用的。復(fù)制主要實現(xiàn)了數(shù)據(jù)的多機(jī)備份，以及對于讀操作的負(fù)載均衡和簡單的故障恢復(fù)。缺陷：故障恢復(fù)無法自動化；寫操作無法負(fù)載均衡；存儲能力受到單機(jī)的限制。

22.Redis哨兵

在復(fù)制的基礎(chǔ)上，哨兵實現(xiàn)了自動化的故障恢復(fù)。缺陷：寫操作無法負(fù)載均衡；存儲能力受到單機(jī)的限制。

23.Reids持久化觸發(fā)條件

RDB持久化的觸發(fā)分為手動觸發(fā)和自動觸發(fā)兩種。

24.Redis 開啟AOF

Redis服務(wù)器默認(rèn)開啟RDB，關(guān)閉AOF；要開啟AOF，需要在配置文件中配置：

appendonly yes

25.AOF常用配置總結(jié)

下面是AOF常用的配置項，以及默認(rèn)值；前面介紹過的這里不再詳細(xì)介紹。

• appendonly no：是否開啟AOF

• appendfilename "appendonly.aof"：AOF文件名

• dir ./：RDB文件和AOF文件所在目錄

• appendfsync everysec：fsync持久化策略

• no-appendfsync-on-rewrite no：AOF重寫期間是否禁止fsync；如果開啟該選項，可以減輕文件重寫時CPU和硬盤的負(fù)載（尤其是硬盤），但是可能會丟失AOF重寫期間的數(shù)據(jù)；需要在負(fù)載和安全性之間進(jìn)行平衡

• auto-aof-rewrite-percentage 100：文件重寫觸發(fā)條件之一

• auto-aof-rewrite-min-size 64mb：文件重寫觸發(fā)提交之一

• aof-load-truncated yes：如果AOF文件結(jié)尾損壞，Redis啟動時是否仍載入AOF文件

26.RDB和AOF的優(yōu)缺點

RDB持久化

優(yōu)點：RDB文件緊湊，體積小，網(wǎng)絡(luò)傳輸快，適合全量復(fù)制；恢復(fù)速度比AOF快很多。當(dāng)然，與AOF相比，RDB最重要的優(yōu)點之一是對性能的影響相對較小。

缺點：RDB文件的致命缺點在于其數(shù)據(jù)快照的持久化方式?jīng)Q定了必然做不到實時持久化，而在數(shù)據(jù)越來越重要的今天，數(shù)據(jù)的大量丟失很多時候是無法接受的，因此AOF持久化成為主流。此外，RDB文件需要滿足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。

AOF持久化

與RDB持久化相對應(yīng)，AOF的優(yōu)點在于支持秒級持久化、兼容性好，缺點是文件大、恢復(fù)速度慢、對性能影響大。

27.持久化策略選擇

（1）如果Redis中的數(shù)據(jù)完全丟棄也沒有關(guān)系（如Redis完全用作DB層數(shù)據(jù)的cache），那么無論是單機(jī)，還是主從架構(gòu)，都可以不進(jìn)行任何持久化。

（2）在單機(jī)環(huán)境下（對于個人開發(fā)者，這種情況可能比較常見），如果可以接受十幾分鐘或更多的數(shù)據(jù)丟失，選擇RDB對Redis的性能更加有利；如果只能接受秒級別的數(shù)據(jù)丟失，應(yīng)該選擇AOF。

（3）但在多數(shù)情況下，我們都會配置主從環(huán)境，slave的存在既可以實現(xiàn)數(shù)據(jù)的熱備，也可以進(jìn)行讀寫分離分擔(dān)Redis讀請求，以及在master宕掉后繼續(xù)提供服務(wù)。

28.redis緩存被擊穿處理機(jī)制

使用mutex。簡單地來說，就是在緩存失效的時候（判斷拿出來的值為空），不是立即去load db，而是先使用緩存工具的某些帶成功操作返回值的操作（比如Redis的SETNX或者M(jìn)emcache的ADD）去set一個mutex key，當(dāng)操作返回成功時，再進(jìn)行l(wèi)oad db的操作并回設(shè)緩存；否則，就重試整個get緩存的方法

29.Redis還提供的高級工具

像慢查詢分析、性能測試、Pipeline、事務(wù)、Lua自定義命令、Bitmaps、HyperLogLog、發(fā)布/訂閱、Geo等個性化功能。

30.Redis常用管理命令

# dbsize 返回當(dāng)前數(shù)據(jù)庫 key 的數(shù)量。
# info 返回當(dāng)前 redis 服務(wù)器狀態(tài)和一些統(tǒng)計信息。
# monitor 實時監(jiān)聽并返回redis服務(wù)器接收到的所有請求信息。
# shutdown 把數(shù)據(jù)同步保存到磁盤上，并關(guān)閉redis服務(wù)。
# config get parameter 獲取一個 redis 配置參數(shù)信息。（個別參數(shù)可能無法獲取）
# config set parameter value 設(shè)置一個 redis 配置參數(shù)信息。（個別參數(shù)可能無法獲取）
# config resetstat 重置 info 命令的統(tǒng)計信息。（重置包括：keyspace 命中數(shù)、
# keyspace 錯誤數(shù)、 處理命令數(shù)，接收連接數(shù)、過期 key 數(shù)）
# debug object key 獲取一個 key 的調(diào)試信息。
# debug segfault 制造一次服務(wù)器當(dāng)機(jī)。
# flushdb 刪除當(dāng)前數(shù)據(jù)庫中所有 key,此方法不會失敗。小心慎用
# flushall 刪除全部數(shù)據(jù)庫中所有 key，此方法不會失敗。小心慎用

31.Reids工具命令

#redis-server：Redis 服務(wù)器的 daemon 啟動程序
#redis-cli：Redis 命令行操作工具。當(dāng)然，你也可以用 telnet 根據(jù)其純文本協(xié)議來操作
#redis-benchmark：Redis 性能測試工具，測試 Redis 在你的系統(tǒng)及你的配置下的讀寫性能
$redis-benchmark -n 100000 –c 50
#模擬同時由 50 個客戶端發(fā)送 100000 個 SETs/GETs 查詢
#redis-check-aof：更新日志檢查
#redis-check-dump：本地數(shù)據(jù)庫檢查

32.為什么需要持久化？

由于Redis是一種內(nèi)存型數(shù)據(jù)庫，即服務(wù)器在運行時，系統(tǒng)為其分配了一部分內(nèi)存存儲數(shù)據(jù)，一旦服務(wù)器掛了，或者突然宕機(jī)了，那么數(shù)據(jù)庫里面的數(shù)據(jù)將會丟失，為了使服務(wù)器即使突然關(guān)機(jī)也能保存數(shù)據(jù)，必須通過持久化的方式將數(shù)據(jù)從內(nèi)存保存到磁盤中。

33.判斷key是否存在

exists key +key名字

34.刪除key

del key1 key2 ...

35.緩存和數(shù)據(jù)庫間數(shù)據(jù)一致性問題

分布式環(huán)境下（單機(jī)就不用說了）非常容易出現(xiàn)緩存和數(shù)據(jù)庫間的數(shù)據(jù)一致性問題，針對這一點的話，只能說，如果你的項目對緩存的要求是強(qiáng)一致性的，那么請不要使用緩存。我們只能采取合適的策略來降低緩存和數(shù)據(jù)庫間數(shù)據(jù)不一致的概率，而無法保證兩者間的強(qiáng)一致性。合適的策略包括 合適的緩存更新策略，更新數(shù)據(jù)庫后要及時更新緩存、緩存失敗時增加重試機(jī)制，例如MQ模式的消息隊列。

36.布隆過濾器

bloomfilter就類似于一個hash set，用于快速判某個元素是否存在于集合中，其典型的應(yīng)用場景就是快速判斷一個key是否存在于某容器，不存在就直接返回。布隆過濾器的關(guān)鍵就在于hash算法和容器大小

37.緩存雪崩問題

存在同一時間內(nèi)大量鍵過期（失效），接著來的一大波請求瞬間都落在了數(shù)據(jù)庫中導(dǎo)致連接異常。

解決方案：

1、也是像解決緩存穿透一樣加鎖排隊。

2、建立備份緩存，緩存A和緩存B，A設(shè)置超時時間，B不設(shè)值超時時間，先從A讀緩存，A沒有讀B，并且更新A緩存和B緩存;

38.緩存并發(fā)問題

這里的并發(fā)指的是多個redis的client同時set key引起的并發(fā)問題。比較有效的解決方案就是把redis.set操作放在隊列中使其串行化，必須的一個一個執(zhí)行，具體的代碼就不上了，當(dāng)然加鎖也是可以的，至于為什么不用redis中的事務(wù)，留給各位看官自己思考探究。

39.Redis分布式

redis支持主從的模式。原則：Master會將數(shù)據(jù)同步到slave，而slave不會將數(shù)據(jù)同步到master。Slave啟動時會連接master來同步數(shù)據(jù)。

這是一個典型的分布式讀寫分離模型。我們可以利用master來插入數(shù)據(jù)，slave提供檢索服務(wù)。這樣可以有效減少單個機(jī)器的并發(fā)訪問數(shù)量

40.讀寫分離模型

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

41.數(shù)據(jù)分片模型

為了解決讀寫分離模型的缺陷，可以將數(shù)據(jù)分片模型應(yīng)用進(jìn)來。

可以將每個節(jié)點看成都是獨立的master，然后通過業(yè)務(wù)實現(xiàn)數(shù)據(jù)分片。

結(jié)合上面兩種模型，可以將每個master設(shè)計成由一個master和多個slave組成的模型。

42. redis常見性能問題和解決方案：

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

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

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

盡量避免在壓力很大的主庫上增加從庫

43.redis通訊協(xié)議

RESP 是redis客戶端和服務(wù)端之前使用的一種通訊協(xié)議；RESP 的特點：實現(xiàn)簡單、快速解析、可讀性好

44.Redis分布式鎖實現(xiàn)

先拿setnx來爭搶鎖，搶到之后，再用expire給鎖加一個過期時間防止鎖忘記了釋放。**如果在setnx之后執(zhí)行expire之前進(jìn)程意外crash或者要重啟維護(hù)了，那會怎么樣？**set指令有非常復(fù)雜的參數(shù)，這個應(yīng)該是可以同時把setnx和expire合成一條指令來用的！

45.Redis做異步隊列

一般使用list結(jié)構(gòu)作為隊列，rpush生產(chǎn)消息，lpop消費消息。當(dāng)lpop沒有消息的時候，要適當(dāng)sleep一會再重試。缺點：在消費者下線的情況下，生產(chǎn)的消息會丟失，得使用專業(yè)的消息隊列如rabbitmq等。**能不能生產(chǎn)一次消費多次呢？**使用pub/sub主題訂閱者模式，可以實現(xiàn)1:N的消息隊列。

46.Redis中海量數(shù)據(jù)的正確操作方式

利用SCAN系列命令（SCAN、SSCAN、HSCAN、ZSCAN）完成數(shù)據(jù)迭代。

47.SCAN系列命令注意事項

• SCAN的參數(shù)沒有key，因為其迭代對象是DB內(nèi)數(shù)據(jù)；

• 返回值都是數(shù)組，第一個值都是下一次迭代游標(biāo)；

• 時間復(fù)雜度：每次請求都是O(1)，完成所有迭代需要O(N)，N是元素數(shù)量；

• 可用版本：version >= 2.8.0；

48.Redis 管道 Pipeline

在某些場景下我們在一次操作中可能需要執(zhí)行多個命令，而如果我們只是一個命令一個命令去執(zhí)行則會浪費很多網(wǎng)絡(luò)消耗時間，如果將命令一次性傳輸?shù)?Redis中去再執(zhí)行，則會減少很多開銷時間。但是需要注意的是 pipeline中的命令并不是原子性執(zhí)行的，也就是說管道中的命令到達(dá) Redis服務(wù)器的時候可能會被其他的命令穿插

49.事務(wù)不支持回滾

50.手寫一個 LRU 算法

class LRUCache<K, V> extends LinkedHashMap<K, V> {
private final int CACHE_SIZE;

/**
* 傳遞進(jìn)來最多能緩存多少數(shù)據(jù)
*
* @param cacheSize 緩存大小
*/
public LRUCache(int cacheSize) {
// true 表示讓 linkedHashMap 按照訪問順序來進(jìn)行排序，最近訪問的放在頭部，最老訪問的放在尾部。
super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
CACHE_SIZE = cacheSize;
}

@Override
protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
// 當(dāng) map中的數(shù)據(jù)量大于指定的緩存?zhèn)€數(shù)的時候，就自動刪除最老的數(shù)據(jù)。
return size() > CACHE_SIZE;
}
}

51.多節(jié)點 Redis 分布式鎖：Redlock 算法

獲取當(dāng)前時間（start）。

依次向 N 個 Redis節(jié)點請求鎖。請求鎖的方式與從單節(jié)點 Redis獲取鎖的方式一致。為了保證在某個 Redis節(jié)點不可用時該算法能夠繼續(xù)運行，獲取鎖的操作都需要設(shè)置超時時間，需要保證該超時時間遠(yuǎn)小于鎖的有效時間。這樣才能保證客戶端在向某個 Redis節(jié)點獲取鎖失敗之后，可以立刻嘗試下一個節(jié)點。

計算獲取鎖的過程總共消耗多長時間（consumeTime = end - start）。如果客戶端從大多數(shù) Redis節(jié)點（>= N/2 + 1) 成功獲取鎖，并且獲取鎖總時長沒有超過鎖的有效時間，這種情況下，客戶端會認(rèn)為獲取鎖成功，否則，獲取鎖失敗。

如果最終獲取鎖成功，鎖的有效時間應(yīng)該重新設(shè)置為鎖最初的有效時間減去 consumeTime。

如果最終獲取鎖失敗，客戶端應(yīng)該立刻向所有 Redis節(jié)點發(fā)起釋放鎖的請求。

52.Redis 中設(shè)置過期時間主要通過以下四種方式

• expire key seconds：設(shè)置 key 在 n 秒后過期；

• pexpire key milliseconds：設(shè)置 key 在 n 毫秒后過期；

• expireat key timestamp：設(shè)置 key 在某個時間戳（精確到秒）之后過期；

• pexpireat key millisecondsTimestamp：設(shè)置 key 在某個時間戳（精確到毫秒）之后過期；

53.Reids三種不同刪除策略

定時刪除：在設(shè)置鍵的過期時間的同時，創(chuàng)建一個定時任務(wù)，當(dāng)鍵達(dá)到過期時間時，立即執(zhí)行對鍵的刪除操作

惰性刪除：放任鍵過期不管，但在每次從鍵空間獲取鍵時，都檢查取得的鍵是否過期，如果過期的話，就刪除該鍵，如果沒有過期，就返回該鍵

定期刪除：每隔一點時間，程序就對數(shù)據(jù)庫進(jìn)行一次檢查，刪除里面的過期鍵，至于要刪除多少過期鍵，以及要檢查多少個數(shù)據(jù)庫，則由算法決定。

54.定時刪除

• **優(yōu)點：**對內(nèi)存友好，定時刪除策略可以保證過期鍵會盡可能快地被刪除，并釋放國期間所占用的內(nèi)存

• **缺點：**對cpu時間不友好，在過期鍵比較多時，刪除任務(wù)會占用很大一部分cpu時間，在內(nèi)存不緊張但cpu時間緊張的情況下，將cpu時間用在刪除和當(dāng)前任務(wù)無關(guān)的過期鍵上，影響服務(wù)器的響應(yīng)時間和吞吐量

55.定期刪除

由于定時刪除會占用太多cpu時間，影響服務(wù)器的響應(yīng)時間和吞吐量以及惰性刪除浪費太多內(nèi)存，有內(nèi)存泄露的危險，所以出現(xiàn)一種整合和折中這兩種策略的定期刪除策略。

定期刪除策略每隔一段時間執(zhí)行一次刪除過期鍵操作，并通過限制刪除操作執(zhí)行的時長和頻率來減少刪除操作對CPU時間的影響。

定時刪除策略有效地減少了因為過期鍵帶來的內(nèi)存浪費。

56.惰性刪除

• **優(yōu)點：**對cpu時間友好，在每次從鍵空間獲取鍵時進(jìn)行過期鍵檢查并是否刪除，刪除目標(biāo)也僅限當(dāng)前處理的鍵，這個策略不會在其他無關(guān)的刪除任務(wù)上花費任何cpu時間。

• **缺點：**對內(nèi)存不友好，過期鍵過期也可能不會被刪除，導(dǎo)致所占的內(nèi)存也不會釋放。甚至可能會出現(xiàn)內(nèi)存泄露的現(xiàn)象，當(dāng)存在很多過期鍵，而這些過期鍵又沒有被訪問到，這會可能導(dǎo)致它們會一直保存在內(nèi)存中，造成內(nèi)存泄露。

57.Reids 管理工具：Redis Manager 2.0

github地址

58.Redis常見的幾種緩存策略

• Cache-Aside

• Read-Through

• Write-Through

• Write-Behind

59.Redis Module 實現(xiàn)布隆過濾器

Redis module 是Redis 4.0 以后支持的新的特性，這里很多國外牛逼的大學(xué)和機(jī)構(gòu)提供了很多牛逼的Module 只要編譯引入到Redis 中就能輕松的實現(xiàn)我們某些需求的功能。在Redis 官方Module 中有一些我們常見的一些模塊，我們在這里就做一個簡單的使用。

• neural-redis 主要是神經(jīng)網(wǎng)絡(luò)的機(jī)器學(xué)，集成到redis 可以做一些機(jī)器訓(xùn)練感興趣的可以嘗試

• RedisSearch 主要支持一些富文本的的搜索

• RedisBloom 支持分布式環(huán)境下的Bloom 過濾器

60.Redis 到底是怎么實現(xiàn)“附近的人”

使用方式

GEOADD key longitude latitude member [longitude latitude member ...]

將給定的位置對象（緯度、經(jīng)度、名字）添加到指定的key。其中，key為集合名稱，member為該經(jīng)緯度所對應(yīng)的對象。在實際運用中，當(dāng)所需存儲的對象數(shù)量過多時，可通過設(shè)置多key(如一個省一個key)的方式對對象集合變相做sharding，避免單集合數(shù)量過多。

成功插入后的返回值：

(integer) N

其中N為成功插入的個數(shù)。

整理到這里我已經(jīng)要吐血了，點個贊轉(zhuǎn)個發(fā)?我在整理100個。

總結(jié)

以上是生活随笔為你收集整理的王炸吐血整理60个Redis面试题,全网最全了的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。