有了這篇你還說(shuō)你不會(huì)redis性能優(yōu)化、內(nèi)存分析及優(yōu)化

序

Redis 利用了多路 I/O 復(fù)用機(jī)制，處理客戶端請(qǐng)求時(shí)，不會(huì)阻塞主線程；Redis 單純執(zhí)行（大多數(shù)指令）一個(gè)指令不到 1 微秒，如此，單核 CPU 一秒就能處理 1 百萬(wàn)個(gè)指令（大概對(duì)應(yīng)著幾十萬(wàn)個(gè)請(qǐng)求吧），用不著實(shí)現(xiàn)多線程（網(wǎng)絡(luò)才是瓶頸）。

1. 優(yōu)化網(wǎng)絡(luò)延時(shí)

Redis 客戶端和服務(wù)器的通訊一般使用 TCP 長(zhǎng)鏈接。如果客戶端發(fā)送請(qǐng)求后需要等待 Redis 返回結(jié)果再發(fā)送下一個(gè)指令，客戶端和 Redis 的多個(gè)請(qǐng)求就構(gòu)成下面的關(guān)系：

?

（備注：如果不是你要發(fā)送的 key 特別長(zhǎng)，一個(gè) TCP 包完全能放下 Redis 指令，所以只畫了一個(gè) push 包）

?

這樣這兩次請(qǐng)求中，客戶端都需要經(jīng)歷一段網(wǎng)絡(luò)傳輸時(shí)間。

但如果有可能，完全可以使用 multi-key 類的指令來(lái)合并請(qǐng)求，比如兩個(gè) GET key 可以用 MGET key1 key2 合并。這樣在實(shí)際通訊中，請(qǐng)求數(shù)也減少了，延時(shí)自然得到好轉(zhuǎn)。

如果不能用 multi-key 指令來(lái)合并，比如一個(gè) SET，一個(gè) GET 無(wú)法合并。怎么辦？

Redis 中有至少這樣兩個(gè)方法能合并多個(gè)指令到一個(gè) request 中，一個(gè)是 MULTI/EXEC，一個(gè)是 script。前者本來(lái)是構(gòu)建 Redis 事務(wù)的方法，但確實(shí)可以合并多個(gè)指令為一個(gè) request，它到通訊過(guò)程如下。至于 script，最好利用緩存腳本的 sha1 hash key 來(lái)調(diào)起腳本，這樣通訊量更小。

這樣確實(shí)更能減少網(wǎng)絡(luò)傳輸時(shí)間，不是么？但如此以來(lái)，就必須要求這個(gè) transaction / script 中涉及的 key 在同一個(gè) node 上，所以要酌情考慮。

如果上面的方法我們都考慮過(guò)了，還是沒(méi)有辦法合并多個(gè)請(qǐng)求，我們還可以考慮合并多個(gè) responses。比如把 2 個(gè)回復(fù)信息合并：

這樣，理論上可以省去 1 次回復(fù)所用的網(wǎng)絡(luò)傳輸時(shí)間。這就是 pipeline 做的事情。不是任意多個(gè)回復(fù)信息都可以放進(jìn)一個(gè) TCP 包中，如果請(qǐng)求數(shù)太多，回復(fù)的數(shù)據(jù)很長(zhǎng)（比如 get 一個(gè)長(zhǎng)字符串），TCP 還是會(huì)分包傳輸，但使用 pipeline，依然可以減少傳輸次數(shù)。

pipeline 和上面的其他方法都不一樣的是，它不具有原子性。所以在 cluster 狀態(tài)下的集群上，實(shí)現(xiàn) pipeline 比那些原子性的方法更有可能。

小結(jié)一下：

• 使用 unix 進(jìn)程間通信，如果單機(jī)部署
• 使用 multi-key 指令合并多個(gè)指令，減少請(qǐng)求數(shù)，如果有可能的話
• 使用 transaction、script 合并 requests 以及 responses
• 使用 pipeline 合并 response

2. 警惕執(zhí)行時(shí)間長(zhǎng)的操作

在大數(shù)據(jù)量的情況下，有些操作的執(zhí)行時(shí)間會(huì)相對(duì)長(zhǎng)，比如 KEYS *，LRANGE mylist 0 -1，以及其他算法復(fù)雜度為 O(n) 的指令。因?yàn)?Redis 只用一個(gè)線程來(lái)做數(shù)據(jù)查詢，如果這些指令耗時(shí)很長(zhǎng)，就會(huì)阻塞 Redis，造成大量延時(shí)。

盡管官方文檔中說(shuō) KEYS * 的查詢挺快的，（在普通筆記本上）掃描 1 百萬(wàn)個(gè) key，只需 40 毫秒(參見(jiàn)：https://redis.io/commands/keys)，但幾十 ms 對(duì)于一個(gè)性能要求很高的系統(tǒng)來(lái)說(shuō)，已經(jīng)不短了，更何況如果有幾億個(gè) key（一臺(tái)機(jī)器完全可能存幾億個(gè) key，比如一個(gè) key 100字節(jié)，1 億個(gè) key 只有 10GB），時(shí)間更長(zhǎng)。Redis 中 transaction，script，因?yàn)榭梢院喜⒍鄠€(gè) commands 為一個(gè)具有原子性的執(zhí)行過(guò)程，所以也可能占用 Redis 很長(zhǎng)時(shí)間，需要注意。

如果你想找出生產(chǎn)環(huán)境使用的「慢指令」，那么可以利用 SLOWLOG GET count 來(lái)查看最近的 count 個(gè)執(zhí)行時(shí)間很長(zhǎng)的指令。至于多長(zhǎng)算長(zhǎng)，可以通過(guò)「在 redis.conf 中設(shè)置 slowlog-log-slower-than 來(lái)定義。」

注意

除此之外，在很多地方都沒(méi)有提到的一個(gè)可能的慢指令是 DEL，但 「redis.conf 文件的注釋[9]中」倒是說(shuō)了。長(zhǎng)話短說(shuō)就是 DEL 一個(gè)大的 object 時(shí)候，回收相應(yīng)的內(nèi)存可能會(huì)需要很長(zhǎng)時(shí)間（甚至幾秒），所以，建議用 DEL 的異步版本：UNLINK。后者會(huì)啟動(dòng)一個(gè)新的 thread 來(lái)刪除目標(biāo) key，而不阻塞原來(lái)的線程。

更進(jìn)一步，當(dāng)一個(gè) key 過(guò)期之后，Redis 一般也需要同步的把它刪除。其中一種刪除 keys 的方式是，每秒 10 次的檢查一次有設(shè)置過(guò)期時(shí)間的 keys，這些 keys 存儲(chǔ)在一個(gè)全局的 struct 中，可以用server.db->expires訪問(wèn)。檢查的方式是：

從中隨機(jī)取出 20 個(gè) keys,把過(guò)期的刪掉。

如果剛剛 20 個(gè) keys 中，有 25% 以上（也就是 5 個(gè)以上）都是過(guò)期的，Redis 認(rèn)為，過(guò)期的 keys 還挺多的，繼續(xù)重復(fù)步驟 1，直到滿足退出條件：某次取出的 keys 中沒(méi)有那么多過(guò)去的 keys。

這里對(duì)于性能的影響是，如果真的有很多的 keys 在同一時(shí)間過(guò)期，那么 Redis 真的會(huì)一直循環(huán)執(zhí)行刪除，占用主線程。

對(duì)此，Redis 作者的建議是「警惕 EXPIREAT」這個(gè)指令，因?yàn)樗菀桩a(chǎn)生 keys 同時(shí)過(guò)期的現(xiàn)象。我還見(jiàn)到過(guò)一些建議是給 keys 的過(guò)期時(shí)間設(shè)置一個(gè)隨機(jī)波動(dòng)量。

最后，redis.conf 中也給出了一個(gè)方法，把 keys 的過(guò)期刪除操作變?yōu)楫惒降?/code>，即，在 redis.conf 中設(shè)置 lazyfree-lazy-expire yes。

3. 優(yōu)化數(shù)據(jù)結(jié)構(gòu)、使用正確的算法

一種數(shù)據(jù)類型（比如 string，list）進(jìn)行增刪改查的效率是由其底層的存儲(chǔ)結(jié)構(gòu)決定的。

除了時(shí)間性能上的考慮，有時(shí)候我們還需要節(jié)省存儲(chǔ)空間。比如上面提到的 ziplist 結(jié)構(gòu)，就比 hashtable 結(jié)構(gòu)節(jié)省存儲(chǔ)空間

?

（Redis Essentials 的作者分別在 hashtable 和 ziplist 結(jié)構(gòu)的 Hash 中插入 500 個(gè) fields，每個(gè) field 和 value 都是一個(gè) 15 位左右的字符串，結(jié)果是 hashtable 結(jié)構(gòu)使用的空間是 ziplist 的 4 倍。）。

?

但節(jié)省空間的數(shù)據(jù)結(jié)構(gòu)，其算法的復(fù)雜度可能很高。所以，這里就需要在具體問(wèn)題面前做出權(quán)衡。

在使用一種數(shù)據(jù)類型時(shí)，可以適當(dāng)關(guān)注一下它底層的存儲(chǔ)結(jié)構(gòu)及其算法，避免使用復(fù)雜度太高的方法。舉兩個(gè)例子：

「ZADD 的時(shí)間復(fù)雜度是 O(log(N))，這比其他數(shù)據(jù)類型增加一個(gè)新元素的操作更復(fù)雜，所以要小心使用。」

若 Hash 類型的值的 fields 數(shù)量有限，它很有可能采用 ziplist 這種結(jié)構(gòu)做存儲(chǔ)，而 ziplist 的查詢效率可能沒(méi)有同等字段數(shù)量的 hashtable 效率高，在必要時(shí)，可以調(diào)整 Redis 的存儲(chǔ)結(jié)構(gòu)。

4. 考慮操作系統(tǒng)和硬件是否影響性能

Redis 運(yùn)行的外部環(huán)境，也就是操作系統(tǒng)和硬件顯然也會(huì)影響 Redis 的性能。

CPU

Intel 多種 CPU 都比 AMD 皓龍系列好

虛擬化

實(shí)體機(jī)比虛擬機(jī)好，主要是因?yàn)椴糠痔摂M機(jī)上，硬盤不是本地硬盤，監(jiān)控軟件導(dǎo)致 fork 指令的速度慢（持久化時(shí)會(huì)用到 fork），尤其是用 Xen 來(lái)做虛擬化時(shí)。

內(nèi)存管理

在 linux 操作系統(tǒng)中，為了讓 translation lookaside buffer，即 TLB，能夠管理更多內(nèi)存空間（TLB 只能緩存有限個(gè) page），操作系統(tǒng)把一些 memory page 變得更大，比如 2MB 或者 1GB，而不是通常的 4096 字節(jié)，這些大的內(nèi)存頁(yè)叫做 huge pages。

同時(shí)，為了方便程序員使用這些大的內(nèi)存 page，操作系統(tǒng)中實(shí)現(xiàn)了一個(gè) transparent huge pages（THP）機(jī)制，使得大內(nèi)存頁(yè)對(duì)他們來(lái)說(shuō)是透明的，可以像使用正常的內(nèi)存 page 一樣使用他們。但這種機(jī)制并不是數(shù)據(jù)庫(kù)所需要的，可能是因?yàn)?THP 會(huì)把內(nèi)存空間變得緊湊而連續(xù)吧，就像mongodb 的文檔[11]中明確說(shuō)的，數(shù)據(jù)庫(kù)需要的是稀疏的內(nèi)存空間，所以請(qǐng)禁掉 THP 功能。Redis 也不例外，但 Redis 官方博客上給出的理由是：使用大內(nèi)存 page 會(huì)使 bgsave 時(shí)，fork 的速度變慢；如果 fork 之后，這些內(nèi)存 page 在原進(jìn)程中被修改了，他們就需要被復(fù)制（即 copy on write），這樣的復(fù)制會(huì)消耗大量的內(nèi)存（畢竟，人家是 huge pages，復(fù)制一份消耗成本很大）。

所以，請(qǐng)禁止掉操作系統(tǒng)中的 transparent huge pages 功能。

交換空間：當(dāng)一些內(nèi)存 page 被存儲(chǔ)在交換空間文件上，而 Redis 又要請(qǐng)求那些數(shù)據(jù)，那么操作系統(tǒng)會(huì)阻塞 Redis 進(jìn)程，然后把想要的 page，從交換空間中拿出來(lái)，放進(jìn)內(nèi)存。這其中涉及整個(gè)進(jìn)程的阻塞，所以可能會(huì)造成延時(shí)問(wèn)題，一個(gè)解決方法是禁止使用交換空間（Redis Essentials 中如是建議，如果內(nèi)存空間不足，請(qǐng)用別的方法處理）。

5. 考慮持久化帶來(lái)的開(kāi)銷

5.1 RDB 全量持久化。

這種持久化方式把 Redis 中的全量數(shù)據(jù)打包成 rdb 文件放在硬盤上。但是執(zhí)行 RDB 持久化過(guò)程的是原進(jìn)程 fork 出來(lái)一個(gè)子進(jìn)程，而 fork 這個(gè)系統(tǒng)調(diào)用是需要時(shí)間的，根據(jù)Redis Lab 6 年前做的實(shí)驗(yàn)[12]，在一臺(tái)新型的 AWS EC2 m1.small^13 上，fork 一個(gè)內(nèi)存占用 1GB 的 Redis 進(jìn)程，需要 700+ 毫秒，而這段時(shí)間，redis 是無(wú)法處理請(qǐng)求的。

雖然現(xiàn)在的機(jī)器應(yīng)該都會(huì)比那個(gè)時(shí)候好，但是 fork 的開(kāi)銷也應(yīng)該考慮吧。為此，要使用合理的 RDB 持久化的時(shí)間間隔，不要太頻繁。

5.2 AOF 增量持久化。

這種持久化方式會(huì)把你發(fā)到 redis server 的指令以文本的形式保存下來(lái)（格式遵循 redis protocol），這個(gè)過(guò)程中，會(huì)調(diào)用兩個(gè)系統(tǒng)調(diào)用，一個(gè)是 write(2)，同步完成，一個(gè)是 fsync(2)，異步完成。

這兩部都可能是延時(shí)問(wèn)題的原因：

write 可能會(huì)因?yàn)檩敵龅?buffer 滿了，或者 kernal 正在把 buffer 中的數(shù)據(jù)同步到硬盤，就被阻塞了。fsync 的作用是確保 write 寫入到 aof 文件的數(shù)據(jù)落到了硬盤上，在一個(gè) 7200 轉(zhuǎn)/分的硬盤上可能要延時(shí) 20 毫秒左右，消耗還是挺大的。更重要的是，在 fsync 進(jìn)行的時(shí)候，write 可能會(huì)被阻塞。其中，write 的阻塞貌似只能接受，因?yàn)闆](méi)有更好的方法把數(shù)據(jù)寫到一個(gè)文件中了。但對(duì)于 fsync，Redis 允許三種配置，選用哪種取決于你對(duì)備份及時(shí)性和性能的平衡：always：當(dāng)把 appendfsync 設(shè)置為 always，fsync 會(huì)和客戶端的指令同步執(zhí)行，因此最可能造成延時(shí)問(wèn)題，但備份及時(shí)性最好。everysec：每秒鐘異步執(zhí)行一次 fsync，此時(shí) redis 的性能表現(xiàn)會(huì)更好，但是 fsync 依然可能阻塞 write，算是一個(gè)折中選擇。no：redis 不會(huì)主動(dòng)出發(fā) fsync （并不是永遠(yuǎn)不 fsync，那是不太可能的），而由 kernel 決定何時(shí) fsync。

6. 使用分布式架構(gòu) —— 讀寫分離、數(shù)據(jù)分片

把慢速的指令發(fā)到某些從庫(kù)中執(zhí)行 把持久化功能放在一個(gè)很少使用的從庫(kù)上 把某些大 list 分片 其中前兩條都是根據(jù) Redis 單線程的特性，用其他進(jìn)程（甚至機(jī)器）做性能補(bǔ)充的方法。

7. reids 內(nèi)存分析及使用優(yōu)化

redis內(nèi)存使用情況：info memory

7.1 內(nèi)存使用

redis的內(nèi)存使用分布：自身內(nèi)存，鍵值對(duì)象占用、緩沖區(qū)內(nèi)存占用及內(nèi)存碎片占用。redis 空進(jìn)程自身消耗非常的少，可以忽略不計(jì)，優(yōu)化內(nèi)存可以不考慮此處的因素。

7.1.1 對(duì)象內(nèi)存

對(duì)象內(nèi)存，也即真實(shí)存儲(chǔ)的數(shù)據(jù)所占用的內(nèi)存。redis k-v結(jié)構(gòu)存儲(chǔ)，對(duì)象占用可以簡(jiǎn)單的理解為 k-size + v-size。redis的鍵統(tǒng)一都為字符串類型，值包含多種類型：string、list、hash、set、zset五種基本類型及基于string的Bitmaps和HyperLogLog類型等。

在實(shí)際的應(yīng)用中，一定要做好kv的構(gòu)建形式及內(nèi)存使用預(yù)期。

7.1.2 緩沖內(nèi)存

緩沖內(nèi)存包括三部分：客戶端緩存、復(fù)制積壓緩存及AOF緩沖區(qū)。

1. 客戶端緩存：接入redis服務(wù)器的TCP連接輸入輸出緩沖內(nèi)存占用，TCP輸入緩沖占用是不受控制的，最大允許空間為1G。輸出緩沖占用可以通過(guò)client-output-buffer-limit參數(shù)配置。redis 客戶端主要分為從客戶端、訂閱客戶端和普通客戶端。

從客戶端連接占用：也就是我們所說(shuō)的slave，主節(jié)點(diǎn)會(huì)為每一個(gè)從節(jié)點(diǎn)建立一條連接用于命令復(fù)制，緩沖配置為：client-output-buffer-limit slave 256mb 64mb 60。主從之間的間絡(luò)延遲及掛載的從節(jié)點(diǎn)數(shù)量是影響內(nèi)存占用的主要因素。因此在涉及需要異地部署主從時(shí)要特別注意，另外，也要避免主節(jié)點(diǎn)上掛載過(guò)多的從節(jié)點(diǎn)（<=2）；

訂閱客戶端內(nèi)存占用：發(fā)布訂閱功能連接客戶端使用單獨(dú)的緩沖區(qū)，默認(rèn)配置：client-output-buffer-limit pubsub 32mb 8mb 60。當(dāng)消費(fèi)慢于生產(chǎn)時(shí)會(huì)造成緩沖區(qū)積壓，因此需要特別注意消費(fèi)者角色配比及生產(chǎn)、消費(fèi)速度的監(jiān)控。

普通客戶端內(nèi)存占用：除了上述之外的其它客戶端，如我們通常的應(yīng)用連接，默認(rèn)配置：client-output-buffer-limit normal 1000。可以看到，普通客戶端沒(méi)有配置緩沖區(qū)限制，通常一般的客戶端內(nèi)存消耗也可以忽略不計(jì)。

但是當(dāng)redis服務(wù)器響應(yīng)較慢時(shí)，容易造成大量的慢連接，主要表現(xiàn)為連接數(shù)的突增，如果不能及時(shí)處理，此時(shí)會(huì)嚴(yán)重影響redis服務(wù)節(jié)點(diǎn)的服務(wù)及恢復(fù)。公眾號(hào)搜索:[Java學(xué)習(xí)之道],回復(fù)'福利',3T資料等你來(lái)拿!

關(guān)于此，在實(shí)際應(yīng)用中需要注意幾點(diǎn)：

maxclients最大連接數(shù)配置必不可少。合理預(yù)估單次操作數(shù)據(jù)量（寫或讀）及網(wǎng)絡(luò)時(shí)延ttl。禁止線上大吞吐量命令操作，如keys等。高并發(fā)應(yīng)用情景下，redis內(nèi)存使用需要有實(shí)時(shí)的監(jiān)控預(yù)警機(jī)制，

2. 復(fù)制積壓緩沖區(qū) v2.8之后提供的一個(gè)可重用的固定大小緩沖區(qū)，用以實(shí)現(xiàn)向從節(jié)點(diǎn)的部分復(fù)制功能，避免全量復(fù)制。配置單數(shù)：repl-backlog-size，默認(rèn)1M。單個(gè)主節(jié)點(diǎn)配置一個(gè)復(fù)制積壓緩沖區(qū)。
3. AOF緩沖區(qū) AOF重寫期間增量的寫入命令保存，此部分緩存占用大小取決于AOF重寫時(shí)間及增量。

7.2 redis子進(jìn)程內(nèi)存消耗

子進(jìn)程即redis執(zhí)行持久化（RDB/AOF）時(shí)fork的子任務(wù)進(jìn)程。

1. 關(guān)于linux系統(tǒng)的寫時(shí)復(fù)制機(jī)制：父子進(jìn)程會(huì)共享相同的物理內(nèi)存頁(yè)，父進(jìn)程處理寫請(qǐng)求時(shí)會(huì)對(duì)需要修改的頁(yè)復(fù)制一份副本進(jìn)行修改，子進(jìn)程讀取的內(nèi)存則為fork時(shí)的父進(jìn)程內(nèi)存快照，因此，子進(jìn)程的內(nèi)存消耗由期間的寫操作增量決定。
2. 關(guān)于linux的透明大頁(yè)機(jī)制THP（Transparent Huge Page）：THP機(jī)制會(huì)降低fork子進(jìn)程的速度；寫時(shí)復(fù)制內(nèi)存頁(yè)由4KB增大至2M。高并發(fā)情境下，寫時(shí)復(fù)制內(nèi)存占用消耗影響會(huì)很大，因此需要選擇性關(guān)閉。
3. 關(guān)于linux配置：一般需要配置linux系統(tǒng) vm.overcommit_memory=1，以允許系統(tǒng)可以分配所有的物理內(nèi)存。防止fork任務(wù)因內(nèi)存而失敗。

7.3 redis內(nèi)存管理

redis的內(nèi)存管理主要分為兩方面：內(nèi)存上限控制及內(nèi)存回收管理。

7.3.1 內(nèi)存上限：maxmemory

目的：緩存應(yīng)用內(nèi)存回收機(jī)制觸發(fā) + 防止物理內(nèi)存用盡（redis 默認(rèn)無(wú)限使用服務(wù)器內(nèi)存） + 服務(wù)節(jié)點(diǎn)內(nèi)存隔離（單服務(wù)器上部署多個(gè)redis服務(wù)節(jié)點(diǎn)） 在進(jìn)行內(nèi)存分配及限制時(shí)要充分考慮內(nèi)存碎片占用影響。動(dòng)態(tài)調(diào)整，擴(kuò)展redis服務(wù)節(jié)點(diǎn)可用內(nèi)存：config set maxmemory {}。

7.3.2 內(nèi)存回收

「回收時(shí)機(jī)：鍵過(guò)期、內(nèi)存占用達(dá)到上限」

• 

1. 「過(guò)期鍵刪除：」redis 鍵過(guò)期時(shí)間保存在內(nèi)部的過(guò)期字典中，redis采用惰性刪除機(jī)制+定時(shí)任務(wù)刪除機(jī)制。惰性刪除：即讀時(shí)刪除，讀取帶有超時(shí)屬性的鍵時(shí)，如果鍵已過(guò)期，則刪除然后返回空值。這種方式存在問(wèn)題是，觸發(fā)時(shí)機(jī)，加入過(guò)期鍵長(zhǎng)時(shí)間未被讀取，那么它將會(huì)一直存在內(nèi)存中，造成內(nèi)存泄漏。

定時(shí)任務(wù)刪除：redis內(nèi)部維護(hù)了一個(gè)定時(shí)任務(wù)（默認(rèn)每秒10次，可配置），通過(guò)自適應(yīng)法進(jìn)行刪除。刪除邏輯如下：

需要說(shuō)明的一點(diǎn)是，快慢模式執(zhí)行的刪除邏輯相同，這是超時(shí)時(shí)間不同。

• 

2. 「內(nèi)存溢出控制」

當(dāng)內(nèi)存達(dá)到maxmemory，會(huì)觸發(fā)內(nèi)存回收策略，具體策略依據(jù)maxmemory-policy來(lái)執(zhí)行。

• noevication：默認(rèn)不回收，達(dá)到內(nèi)存上限，則不再接受寫操作，并返回錯(cuò)誤。
• volatile-lru：根據(jù)LRU算法刪除設(shè)置了過(guò)期時(shí)間的鍵，如果沒(méi)有則不執(zhí)行回收。
• allkeys-lru：根據(jù)LRU算法刪除鍵，針對(duì)所有鍵。
• allkeys-random：隨機(jī)刪除鍵。
• volatitle-random：速記刪除設(shè)置了過(guò)期時(shí)間的鍵。
• volatilte-ttl：根據(jù)鍵ttl，刪除最近過(guò)期的鍵，同樣如果沒(méi)有設(shè)置過(guò)期的鍵，則不執(zhí)行刪除。動(dòng)態(tài)配置：config set maxmemory-policy {} 在設(shè)置了maxmemory情況下，每次的redis操作都會(huì)檢查執(zhí)行內(nèi)存回收，因此對(duì)于線上環(huán)境，要確保所這只的maxmemory>used_memory。

另外，可以通過(guò)動(dòng)態(tài)配置maxmemory來(lái)主動(dòng)觸發(fā)內(nèi)存回收。