這篇文章我想和你聊一聊 Redis 的最佳實踐，
你的專案或許已經使用 Redis 很長時間了，但在使用程序中，你可能還會或多或少地遇到以下問題：
- 我的 Redis 記憶體為什么增長這么快？
- 為什么我的 Redis 操作延遲變大了？
- 如何降低 Redis 故障發生的頻率？
- 日常運維 Redis 需要注意什么？
- 部署 Redis 時，如何做好資源規劃？
- Redis 監控重點要關注哪些指標？
尤其是當你的專案越來越依賴 Redis 時，這些問題就變得尤為重要，
此時，你迫切需要一份「」，
這篇文章，我將從以下七個維度，帶你「全面」分析 Redis 的最佳實踐優化：
- 記憶體
- 性能
- 高可靠
- 日常運維
- 資源規劃
- 監控
- 安全
在文章的最后，我還會給你一個完整的最佳實踐清單，不管你是業務開發人員，還是 DBA 運維人員，這個清單將會幫助你更加「優雅」地用好 Redis，
這篇文章干貨很多，希望你可以耐心讀完，
一、如何使用 Redis 更節省記憶體？
首先，我們來看一下 Redis 記憶體方面的優化，
眾所周知，Redis 的性能之所以如此之高，原因就在于它的資料都存盤在「記憶體」中，所以訪問 Redis 中的資料速度極快，
但從資源利用率層面來說，機器的記憶體資源相比于磁盤，還是比較昂貴的，
當你的業務應用在 Redis 中存盤資料很少時，你可能并不太關心記憶體資源的使用情況，但隨著業務的發展，你的業務存盤在 Redis 中的資料就會越來越多，
如果沒有提前制定好記憶體優化策略，那么等業務開始增長時，Redis 占用的記憶體也會開始膨脹，
所以，提前制定合理的記憶體優化策略，對于資源利用率的提升是很有必要的，
那在使用 Redis 時，怎樣做才能更節省記憶體呢？這里我給你總結了 6 點建議，我們依次來看：
1、控制 key 的長度
最簡單直接的記憶體優化，就是控制 key 的長度，
在開發業務時，你需要提前預估整個 Redis 中寫入 key 的數量，如果 key 數量達到了百萬級別，那么，過長的 key 名也會占用過多的記憶體空間，
所以，你需要保證 key 在簡單、清晰的前提下，盡可能把 key 定義得短一些，
例如，原有的 key 為 user:book:123，則可以優化為 u:bk:123，
這樣一來，你的 Redis 就可以節省大量的記憶體，這個方案對記憶體的優化非常直接和高效，
2、避免存盤 bigkey
除了控制 key 的長度之外，你同樣需要關注 value 的大小，如果大量存盤 bigkey，也會導致 Redis 記憶體增長過快，
除此之外，客戶端在讀寫 bigkey 時，還有產生性能問題（下文會具體詳述），
所以，你要避免在 Redis 中存盤 bigkey，我給你的建議是：
- String：大小控制在 10KB 以下
- List/Hash/Set/ZSet：元素數量控制在 1 萬以下
3、選擇合適的資料型別
Redis 提供了豐富的資料型別，這些資料型別在實作上，也對記憶體使用做了優化，具體來說就是，一種資料型別對應多種資料結構來實作：
例如，String、Set 在存盤 int 資料時，會采用整數編碼存盤，Hash、ZSet 在元素數量比較少時（可配置），會采用壓縮串列（ziplist）存盤，在存盤比較多的資料時，才會轉換為哈希表和跳表，
作者這么設計的原因，就是為了進一步節約記憶體資源，
那么你在存盤資料時，就可以利用這些特性來優化 Redis 的記憶體，這里我給你的建議如下：
- String、Set：盡可能存盤 int 型別資料
- Hash、ZSet：存盤的元素數量控制在轉換閾值之下，以壓縮串列存盤，節約記憶體
4、把 Redis 當作快取使用
Redis 資料存盤在記憶體中，這也意味著其資源是有限的，你在使用 Redis 時，要把它當做快取來使用，而不是資料庫，
所以，你的應用寫入到 Redis 中的資料，盡可能地都設定「過期時間」，
業務應用在 Redis 中查不到資料時，再從后端資料庫中加載到 Redis 中，
采用這種方案，可以讓 Redis 中只保留經常訪問的「熱資料」，記憶體利用率也會比較高，
5、實體設定 maxmemory + 淘汰策略
雖然你的 Redis key 都設定了過期時間，但如果你的業務應用寫入量很大，并且過期時間設定得比較久，那么短期間內 Redis 的記憶體依舊會快速增長，
如果不控制 Redis 的記憶體上限，也會導致使用過多的記憶體資源，
對于這種場景，你需要提前預估業務資料量，然后給這個實體設定 maxmemory 控制實體的記憶體上限，這樣可以避免 Redis 的記憶體持續膨脹，
配置了 maxmemory，此時你還要設定資料淘汰策略，而淘汰策略如何選擇，你需要結合你的業務特點來決定：
- volatile-lru / allkeys-lru：優先保留最近訪問過的資料
- volatile-lfu / allkeys-lfu：優先保留訪問次數最頻繁的資料（4.0+版本支持）
- volatile-ttl ：優先淘汰即將過期的資料
- volatile-random / allkeys-random：隨機淘汰資料
6、資料壓縮后寫入 Redis
以上方案基本涵蓋了 Redis 記憶體優化的各個方面，
如果你還想進一步優化 Redis 記憶體，你還可以在業務應用中先將資料壓縮，再寫入到 Redis 中（例如采用 snappy、gzip 等壓縮演算法），
當然，壓縮存盤的資料，客戶端在讀取時還需要解壓縮，在這期間會消耗更多 CPU 資源，你需要根據實際情況進行權衡，
以上就是「節省記憶體資源」方面的實踐優化，是不是都比較簡單？
下面我們來看「性能」方面的優化，
二、如何持續發揮 Redis 的高性能？
當你的系統決定引入 Redis 時，想必看中它最關鍵的一點就是：性能，
我們知道，一個單機版 Redis 就可以達到 10W QPS，這么高的性能，也意味著如果在使用程序中發生延遲情況，就會與我們的預期不符，
所以，在使用 Redis 時，如何持續發揮它的高性能，避免操作延遲的情況發生，也是我們的關注焦點，
在這方面，我給你總結了 13 條建議：
1、避免存盤 bigkey
存盤 bigkey 除了前面講到的使用過多記憶體之外，對 Redis 性能也會有很大影響，
由于 Redis 處理請求是單執行緒的，當你的應用在寫入一個 bigkey 時，更多時間將消耗在「記憶體分配」上，這時操作延遲就會增加，同樣地，洗掉一個 bigkey 在「釋放記憶體」時，也會發生耗時，
而且，當你在讀取這個 bigkey 時，也會在「網路資料傳輸」上花費更多時間，此時后面待執行的請求就會發生排隊，Redis 性能下降，
所以，你的業務應用盡量不要存盤 bigkey，避免操作延遲發生，
如果你確實有存盤 bigkey 的需求，你可以把 bigkey 拆分為多個小 key 存盤，
2、開啟 lazy-free 機制
如果你無法避免存盤 bigkey，那么我建議你開啟 Redis 的 lazy-free 機制，（4.0+版本支持）
當開啟這個機制后，Redis 在洗掉一個 bigkey 時，釋放記憶體的耗時操作，將會放到后臺執行緒中去執行，這樣可以在最大程度上，避免對主執行緒的影響，
3、不使用復雜度過高的命令
Redis 是單執行緒模型處理請求，除了操作 bigkey 會導致后面請求發生排隊之外，在執行復雜度過高的命令時，也會發生這種情況，
因為執行復雜度過高的命令，會消耗更多的 CPU 資源，主執行緒中的其它請求只能等待，這時也會發生排隊延遲，
所以，你需要避免執行例如 SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE 等聚合類命令，
對于這種聚合類操作，我建議你把它放到客戶端來執行，不要讓 Redis 承擔太多的計算作業，
4、執行 O(N) 命令時，關注 N 的大小
規避使用復雜度過高的命令，就可以高枕無憂了么？
答案是否定的，
當你在執行 O(N) 命令時，同樣需要注意 N 的大小，
如果一次性查詢過多的資料，也會在網路傳輸程序中耗時過長，操作延遲變大，
所以，對于容器型別（List/Hash/Set/ZSet），在元素數量未知的情況下，一定不要無腦執行 LRANGE key 0 -1 / HGETALL / SMEMBERS / ZRANGE key 0 -1，
在查詢資料時，你要遵循以下原則：
- 先查詢資料元素的數量（LLEN/HLEN/SCARD/ZCARD）
- 元素數量較少，可一次性查詢全量資料
- 元素數量非常多，分批查詢資料（LRANGE/HASCAN/SSCAN/ZSCAN）
5、關注 DEL 時間復雜度
你沒看錯，在洗掉一個 key 時，如果姿勢不對，也有可能影響到 Redis 性能，
洗掉一個 key，我們通常使用的是 DEL 命令，回想一下，你覺得 DEL 的時間復雜度是多少？
O(1) ？其實不一定，
當你洗掉的是一個 String 型別 key 時，時間復雜度確實是 O(1)，
但當你要洗掉的 key 是 List/Hash/Set/ZSet 型別，它的復雜度其實為 O(N)，N 代表元素個數，
也就是說，洗掉一個 key，其元素數量越多，執行 DEL 也就越慢！
原因在于，洗掉大量元素時，需要依次回收每個元素的記憶體，元素越多，花費的時間也就越久！
而且，這個程序默認是在主執行緒中執行的，這勢必會阻塞主執行緒，產生性能問題，
那洗掉這種元素比較多的 key，如何處理呢？
我給你的建議是，分批洗掉：
- List型別：執行多次 LPOP/RPOP，直到所有元素都洗掉完成
- Hash/Set/ZSet型別：先執行 HSCAN/SSCAN/SCAN 查詢元素，再執行 HDEL/SREM/ZREM 依次洗掉每個元素
- 沒想到吧？一個小小的洗掉操作，稍微不小心，也有可能引發性能問題，你在操作時需要格外注意，
6、批量命令代替單個命令
當你需要一次性操作多個 key 時，你應該使用批量命令來處理，
批量操作相比于多次單個操作的優勢在于，可以顯著減少客戶端、服務端的來回網路 IO 次數，
所以我給你的建議是：
- String / Hash 使用 MGET/MSET 替代 GET/SET，HMGET/HMSET 替代 HGET/HSET
- 其它資料型別使用 Pipeline，打包一次性發送多個命令到服務端執行
7、避免集中過期 key
Redis 清理過期 key 是采用定時 + 懶惰的方式來做的，而且這個程序都是在主執行緒中執行，
如果你的業務存在大量 key 集中過期的情況，那么 Redis 在清理過期 key 時，也會有阻塞主執行緒的風險，
想要避免這種情況發生，你可以在設定過期時間時，增加一個隨機時間，把這些 key 的過期時間打散，從而降低集中過期對主執行緒的影響，
8、使用長連接操作 Redis，合理配置連接池
你的業務應該使用長連接操作 Redis，避免短連接，
當使用短連接操作 Redis 時，每次都需要經過 TCP 三次握手、四次揮手，這個程序也會增加操作耗時，
同時，你的客戶端應該使用連接池的方式訪問 Redis，并設定合理的引數，長時間不操作 Redis 時，需及時釋放連接資源，
9、只使用 db0
盡管 Redis 提供了 16 個 db，但我只建議你使用 db0，
為什么呢？我總結了以下 3 點原因：
- 在一個連接上操作多個 db 資料時，每次都需要先執行 SELECT，這會給 Redis 帶來額外的壓力
- 使用多個 db 的目的是，按不同業務線存盤資料，那為何不拆分多個實體存盤呢？拆分多個實體部署，多個業務線不會互相影響，還能提高 Redis 的訪問性能
- Redis Cluster 只支持 db0，如果后期你想要遷移到 Redis Cluster，遷移成本高
10、使用讀寫分離 + 分片集群
如果你的業務讀請求量很大，那么可以采用部署多個從庫的方式，實作讀寫分離，讓 Redis 的從庫分擔讀壓力，進而提升性能，
如果你的業務寫請求量很大，單個 Redis 實體已無法支撐這么大的寫流量，那么此時你需要使用分片集群，分擔寫壓力，
11、不開啟 AOF 或 AOF 配置為每秒刷盤
如果對于丟失資料不敏感的業務，我建議你不開啟 AOF，避免 AOF 寫磁盤拖慢 Redis 的性能，
如果確實需要開啟 AOF，那么我建議你配置為 appendfsync everysec，把資料持久化的刷盤操作，放到后臺執行緒中去執行，盡量降低 Redis 寫磁盤對性能的影響，
12、使用物理機部署 Redis
Redis 在做資料持久化時，采用創建子行程的方式進行，
而創建子行程會呼叫作業系統的 fork 系統呼叫，這個系統呼叫的執行耗時，與系統環境有關，
虛擬機環境執行 fork 的耗時，要比物理機慢得多，所以你的 Redis 應該盡可能部署在物理機上，
13、關閉作業系統記憶體大頁機制
Linux 作業系統提供了記憶體大頁機制，其特點在于，每次應用程式向作業系統申請記憶體時，申請單位由之前的 4KB 變為了 2MB，
這會導致什么問題呢？
當 Redis 在做資料持久化時，會先 fork 一個子行程，此時主行程和子行程共享相同的記憶體地址空間，
當主行程需要修改現有資料時，會采用寫時復制（Copy On Write）的方式進行操作，在這個程序中，需要重新申請記憶體，
如果申請記憶體單位變為了 2MB，那么勢必會增加記憶體申請的耗時，如果此時主行程有大量寫操作，需要修改原有的資料，那么在此期間，操作延遲就會變大，
所以，為了避免出現這種問題，你需要在作業系統上關閉記憶體大頁機制，
好了，以上這些就是 Redis 「高性能」方面的實踐優化，如果你非常關心 Redis 的性能問題，可以結合這些方面針對性優化，
我們再來看 Redis 「可靠性」如何保證，
三、如何保證 Redis 的可靠性？
這里我想提醒你的是，保證 Redis 可靠性其實并不難，但難的是如何做到「持續穩定」，
下面我會從「資源隔離」、「多副本」、「故障恢復」這三大維度，帶你分析保障 Redis 可靠性的最佳實踐，
1、按業務線部署實體
提升可靠性的第一步，就是「資源隔離」，
你最好按不同的業務線來部署 Redis 實體，這樣當其中一個實體發生故障時，不會影響到其它業務，
這種資源隔離的方案，實施成本是最低的，但成效卻是非常大的，
2、部署主從集群
如果你只使用單機版 Redis，那么就會存在機器宕機服務不可用的風險，
所以，你需要部署「多副本」實體，即主從集群，這樣當主庫宕機后，依舊有從庫可以使用，避免了資料丟失的風險，也降低了服務不可用的時間，
在部署主從集群時，你還需要注意，主從庫需要分布在不同機器上，避免交叉部署，
這么做的原因在于，通常情況下，Redis 的主庫會承擔所有的讀寫流量，所以我們一定要優先保證主庫的穩定性，即使從庫機器例外，也不要對主庫造成影響，
而且，有時我們需要對 Redis 做日常維護，例如資料定時備份等操作，這時你就可以只在從庫上進行，這只會消耗從庫機器的資源，也避免了對主庫的影響，
3、合理配置主從復制引數
在部署主從集群時，如果引數配置不合理，也有可能導致主從復制發生問題：
- 主從復制中斷
- 從庫發起全量復制，主庫性能受到影響
在這方面我給你的建議有以下 2 點：
- 設定合理的 repl-backlog 引數：過小的 repl-backlog 在寫流量比較大的場景下，主從復制中斷會引發全量復制資料的風險
- 設定合理的 slave client-output-buffer-limit：當從庫復制發生問題時，過小的 buffer 會導致從庫緩沖區溢位，從而導致復制中斷
4、部署哨兵集群，實作故障自動切換
只部署了主從節點，但故障發生時是無法自動切換的，所以，你還需要部署哨兵集群，實作故障的「自動切換」，
而且，多個哨兵節點需要分布在不同機器上，實體為奇數個，防止哨兵選舉失敗，影響切換時間，
以上這些就是保障 Redis「高可靠」實踐優化，你應該也發現了，這些都是部署和運維層的優化，
除此之外，你可能還會對 Redis 做一些「日常運維」作業，這時你要注意哪些問題呢？
四、日常運維 Redis 需要注意什么？
如果你是 DBA 運維人員，在平時運維 Redis 時，也需要注意以下 6 個方面，
1、禁止使用 KEYS/FLUSHALL/FLUSHDB 命令
執行這些命令，會長時間阻塞 Redis 主執行緒，危害極大，所以你必須禁止使用它，
如果確實想使用這些命令，我給你的建議是：
- SCAN 替換 KEYS
- 4.0+版本可使用 FLUSHALL/FLUSHDB ASYNC，清空資料的操作放在后臺執行緒執行
2、掃描線上實體時，設定休眠時間
不管你是使用 SCAN 掃描線上實體，還是對實體做 bigkey 統計分析，我建議你在掃描時一定記得設定休眠時間，
防止在掃描程序中，實體 OPS 過高對 Redis 產生性能抖動，
3、慎用 MONITOR 命令
有時在排查 Redis 問題時，你會使用 MONITOR 查看 Redis 正在執行的命令，
但如果你的 Redis OPS 比較高，那么在執行 MONITOR 會導致 Redis 輸出緩沖區的記憶體持續增長，這會嚴重消耗 Redis 的記憶體資源，甚至會導致實體記憶體超過 maxmemory，引發資料淘汰，這種情況你需要格外注意，
所以你在執行 MONITOR 命令時，一定要謹慎，盡量少用，
4、從庫必須設定為 slave-read-only
你的從庫必須設定為 slave-read-only 狀態，避免從庫寫入資料，導致主從資料不一致，
除此之外，從庫如果是非 read-only 狀態，如果你使用的是 4.0 以下的 Redis，它存在這樣的 Bug：
從庫寫入了有過期時間的資料，不會做定時清理和釋放記憶體，
這會造成從庫的記憶體泄露！這個問題直到 4.0 版本才修復，你在配置從庫時需要格外注意，
5、合理配置 timeout 和 tcp-keepalive 引數
如果因為網路原因，導致你的大量客戶端連接與 Redis 意外中斷，恰好你的 Redis 配置的 maxclients 引數比較小，此時有可能導致客戶端無法與服務端建立新的連接（服務端認為超過了 maxclients），
造成這個問題原因在于，客戶端與服務端每建立一個連接，Redis 都會給這個客戶端分配了一個 client fd，
當客戶端與服務端網路發生問題時，服務端并不會立即釋放這個 client fd，
什么時候釋放呢？
Redis 內部有一個定時任務，會定時檢測所有 client 的空閑時間是否超過配置的 timeout 值，
如果 Redis 沒有開啟 tcp-keepalive 的話，服務端直到配置的 timeout 時間后，才會清理釋放這個 client fd，
在沒有清理之前，如果還有大量新連接進來，就有可能導致 Redis 服務端內部持有的 client fd 超過了 maxclients，這時新連接就會被拒絕，
針對這種情況，我給你的優化建議是：
- 不要配置過高的 timeout：讓服務端盡快把無效的 client fd 清理掉
- Redis 開啟 tcp-keepalive：這樣服務端會定時給客戶端發送 TCP 心跳包，檢測連接連通性，當網路例外時，可以盡快清理僵尸 client fd
6、調整 maxmemory 時，注意主從庫的調整順序
Redis 5.0 以下版本存在這樣一個問題：從庫記憶體如果超過了 maxmemory，也會觸發資料淘汰，
在某些場景下，從庫是可能優先主庫達到 maxmemory 的（例如在從庫執行 MONITOR 命令，輸出緩沖區占用大量記憶體），那么此時從庫開始淘汰資料，主從庫就會產生不一致，
要想避免此問題，在調整 maxmemory 時，一定要注意主從庫的修改順序：
- 調大 maxmemory：先修改從庫，再修改主庫
- 調小 maxmemory：先修改主庫，再修改從庫
直到 Redis 5.0，Redis 才增加了一個配置 replica-ignore-maxmemory，默認從庫超過 maxmemory 不會淘汰資料，才解決了此問題，
好了，以上這些就是「日常運維」Redis 需要注意的，你可以對各個配置項查漏補缺，看有哪些是需要優化的，
接下來，我們來看一下，保障 Redis「安全」都需要注意哪些問題，
五、Redis 安全如何保證？
無論如何，在互聯網時代，安全問題一定是我們需要隨時警戒的，
你可能聽說過 Redis 被注入可執行腳本，然后拿到機器 root 權限的安全問題，都是因為在部署 Redis 時，沒有把安全風險注意起來，
針對這方面，我給你的建議是：
- 不要把 Redis 部署在公網可訪問的服務器上
- 部署時不使用默認埠 6379
- 以普通用戶啟動 Redis 行程，禁止 root 用戶啟動
- 限制 Redis 組態檔的目錄訪問權限
- 推薦開啟密碼認證
- 禁用/重命名危險命令（KEYS/FLUSHALL/FLUSHDB/CONFIG/EVAL）
只要你把這些做到位，基本上就可以保證 Redis 的安全風險在可控范圍內，
至此，我們分析了 Redis 在記憶體、性能、可靠性、日常運維方面的最佳實踐優化，
除了以上這些，你還需要做到提前「預防」，
六、如何預防 Redis 問題？
要想提前預防 Redis 問題，你需要做好以下兩個方面：
- 合理的資源規劃
- 完善的監控預警
先來順澩規劃，
在部署 Redis 時，如果你可以提前做好資源規劃，可以避免很多因為資源不足產生的問題，這方面我給你的建議有以下 3 點：
- 保證機器有足夠的 CPU、記憶體、帶寬、磁盤資源
- 提前做好容量規劃，主庫機器預留一半記憶體資源，防止主從機器網路故障，引發大面積全量同步，導致主庫機器記憶體不足的問題
- 單個實體記憶體建議控制在 10G 以下，大實體在主從全量同步、RDB 備份時有阻塞風險
再來看監控如何做，
監控預警是提高穩定性的重要環節，完善的監控預警，可以把問題提前暴露出來，這樣我們才可以快速反應，把問題最小化，
這方面我給你的建議是：
- 做好機器 CPU、記憶體、帶寬、磁盤監控，資源不足時及時報警，任意資源不足都會影響 Redis 性能
- 設定合理的 slowlog 閾值，并對其進行監控，slowlog 過多及時報警
- 監控組件采集 Redis INFO 資訊時，采用長連接，避免頻繁的短連接
- 做好實體運行時監控，重點關注 expired_keys、evicted_keys、latest_fork_usec 指標，這些指標短時突增可能會有阻塞風險
總結
好了，總結一下，這篇文章我帶你全面分析了 Redis 最佳實踐的優化路徑，其中包括記憶體資源、高性能、高可靠、日常運維、資源規劃、監控、安全 7 個維度，
這里我畫成了思維導圖，方便你在實踐時做參考，
我還把這些實踐優化，按照「業務開發」和「運維」兩個維度，進一步做了劃分，
并且以「強制」、「推薦」、「參考」3 個級別做了標注，這樣你在實踐優化時，就會更明確哪些該做，哪些需要結合實際的業務場景進一步分析，
這些級別的實施規則如下：
- 強制：需嚴格遵守，否則危害極大
- 推薦：推薦遵守，可提升性能、降低記憶體、便于運維
- 參考：根據業務特點參考實施
如果你是業務開發人員，你需要了解 Redis 的運行機制，例如各個命令的執行時間復雜度、資料過期策略、資料淘汰策略等，使用合理的命令，并結合業務場景進行優化，
如果你是 DBA 運維人員，你需要在資源規劃、運維、監控、安全層面做到位，做到未雨綢繆，
后記
如果你能耐心地讀到這里，應該對如何「用好」Redis 有了新的認識，
這篇文章我們主要講的是 Redis 最佳實踐，對于「最佳實踐」這個話題，我想再和你多聊幾句，
如果你面對的不是 Redis，而是其它中間件，例如 MySQL、Kafka，你在使用這些組件時，會有什么優化思路嗎？
你也可以沿用這篇文章的這幾個維度來分析：
- 性能
- 可靠性
- 資源
- 運維
- 監控
- 安全
你可以思考一下，MySQL 和 Kafka 在這幾個維度，需要注意哪些問題，
另外，從學習技能的角度來講，我們在軟體開發程序中，要盡可能地去思考和探索「最佳實踐」的方式，
因為只有這樣，我們才會不斷督促自己去思考，對自己提出更高的要求，做到持續進步，
作者丨Magic Kaito
來源丨公眾號：水滴與銀彈（ID：waterdrop_bullet）
本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Redis_Best_Practices_Guide.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/413173.html
標籤：NoSQL