版本差異
DCS在創建(jian)實(shi)例時，Redis可(ke)選擇(ze)“版本(ben)號”、“實(shi)例類型”。
- 版本號
版本號共有3.0，4.0，5.0，6.0，它們的區別如下表。更多Redis 4.0和Redis 5.0的特性，請參考“Redis4.0支持的新特性說明”和“Redis 5.0支持的新特性說明”章節。
不(bu)同版本(ben)支持的特性(xing)、性(xing)能差(cha)異說明
| 比較項 | Redis 3.0 | Redis 4.0 & Redis 5.0 | Redis 6.0 |
|---|---|---|---|
| 兼容開源版本 | Redis 3.0兼容開源3.0.7版本 | Redis 4.0兼容開源4.0.14版本Redis 5.0最新版本兼容開源5.0.14版本。存量用戶可以參考查詢Redis原生版本進行查詢。 | Redis 6.0兼容開源6.2.7版本 |
| 實例部署模式 | 采用虛機部署 | 在物理機上容器化部署 | 在物理機上容器化部署 |
| CPU架構 | 支持x86和Arm | 支持x86和Arm | 支持x86 |
| 創建實例耗時 | 3-15分鐘，集群約10-30分鐘 | 約8秒 | 約8秒 |
| QPS | 單節點約10萬QPS | 單節點約10萬QPS | 單節點約15萬QPS |
| 可視化數據管理 | 不支持 | 提供Web CLI訪問Redis，管理數據 | 提供Web CLI訪問Redis，管理數據 |
| 實例類型 | 支持單機、主備、Proxy集群 | 支持單機、主備、Proxy集群、Cluster集群、讀寫分離 | 支持單機、主備 |
| 實例規格 | 提供2G、4G、8G直至1024G多種規格 | 提供2G、4G、8G直至1024G多種規格，同時單機主備還支持128MB、256MB、512MB、1GB四種小規格實例 | 提供4G、8G、16G、32G、64G多種規格，同時單機主備還支持128MB、256MB、512MB、1GB四種小規格實例 |
| 擴容/縮容 | 支持在線擴容和縮容 | 支持在線擴容和縮容 | 支持在線擴容和縮容 |
| 備份恢復 | 主備和集群實例支持 | 主備、讀寫分離、集群實例支持 | 主備 |
說明由于(yu)Redis不同版(ban)本(ben)(ben)的底層架(jia)構不一樣(yang)，在創建Redis實例時，確(que)定Redis版(ban)本(ben)(ben)后(hou)，將不能修改(gai)，如(ru)Redis 3.0暫不支持升級到(dao)Redis 4.0或者(zhe)Redis 5.0。如(ru)果需要由低版(ban)本(ben)(ben)升級到(dao)高版(ban)本(ben)(ben)，建議重新創建高版(ban)本(ben)(ben)實例，然后(hou)進行數據遷移。
- 實例類型
Redis實例類(lei)型分(fen)為單機、主備(bei)、讀寫分(fen)離(li)、Proxy集群、Cluster集群，它們的架(jia)構與應用場景，請參考“實例類(lei)型”章節。
Redis4.0支持的新特性說明
與(yu)Redis 3.0版(ban)本相比(bi)，Redis 4.0及以上版(ban)本，除了開源Redis增(zeng)加(jia)的(de)特(te)性之外，創建(jian)耗(hao)時(shi)也相應縮(suo)短。
實例(li)由虛機方式(shi)改成(cheng)了(le)物理機容器化部署，創建實例(li)只需要8~10秒時間完成(cheng)。
Redis 4.0版(ban)本更(geng)新的特性(xing)，主要涉(she)及三(san)個方面：
- 新命令的增加，如MEMORY、SWAPDB。
- Lazyfree機制，延遲刪除大key，降低刪除操作對系統資源的占用影響。
- 內存性能優化，即主動碎片整理。
MEMORY命令
在Redis 3.0及之前，只能(neng)通過(guo)info memory命令(ling)了解有(you)限的幾(ji)個內存(cun)統計(ji)信息。Redis 4.0引(yin)入(ru)新的命令(ling)memory，讓您能(neng)夠更深入(ru)了解Redis的內存(cun)使用情況。
127.0.0.1:6379[8]> memory help
1) MEMORY <subcommand> arg arg ... arg. Subcommands are:
2) DOCTOR - Return memory problems reports.
3) MALLOC-STATS -- Return internal statistics report from the memory allocator.
4) PURGE -- Attempt to purge dirty pages for reclamation by the allocator.
5) STATS -- Return information about the memory usage of the server.
6) USAGE <key> [SAMPLES <count>] -- Return memory in bytes used by <key> and its value. Nested values are sampled up to <count
> times (default: 5).
127.0.0.1:6379[8]>
usage
輸入 memory usage [key] ，如果(guo)當前(qian)key存在，則(ze)返(fan)回(hui)key的value實際使用內存估算值；如果(guo)key不存在，則(ze)返(fan)回(hui)nil。
127.0.0.1:6379[8]> set dcs "DCS is an online, distributed, in-memory cache service compatible with Redis, and Memcached."
OK
127.0.0.1:6379[8]> memory usage dcs
(integer) 141
127.0.0.1:6379[8]>
說明
- usage統計value內存占用，以及key自身的內存占用，不包含key的Expire內存占用。
//以下(xia)內容(rong)基于Redis 5.0.2版(ban)本驗證，不同(tong)Redis版(ban)本，統計(ji)結(jie)果可能(neng)有差異。
192.168.0.66:6379> set a "Hello, world!"
OK
192.168.0.66:6379> memory usage a
(integer) 58
192.168.0.66:6379> set abc "Hello, world!"
OK
192.168.0.66:6379> memory usage abc
(integer) 60 //key名稱長度(du)變(bian)化后，內(nei)存(cun)占用(yong)也有變(bian)化，說(shuo)明usage統(tong)計包含了key自身的占用(yong)
192.168.0.66:6379> expire abc 1000000
(integer) 1
192.168.0.66:6379> memory usage abc
(integer) 60 //加了過期時間后，內存占用(yong)沒(mei)有(you)改變，說(shuo)明usage統計(ji)不包含(han)expire內存占用(yong)
192.168.0.66:6379>
- 對hash、list、set、sorted set等數據類型，usage命令會抽樣統計，提供內存占用的估算值。
使用方式：**memory usage **keyset **samples **1000
其中keyset表示一個集合(he)數(shu)據類型的key，1000表示抽樣個數(shu)。
stats
返回當前實例內存使(shi)用細(xi)節。
使用方法：memory stats
127.0.0.1:6379[8]> memory stats
1) "peak.allocated"
2) (integer) 2412408
3) "total.allocated"
4) (integer) 2084720
5) "startup.allocated"
6) (integer) 824928
7) "replication.backlog"
... ...
以下給出部分(fen)數據返回項的具體含義
memory stats
| 數據返回項 | 說明 |
|---|---|
| peak.allocated | Redis實例運行過程中，allocator分配的內存峰值。同info memory的used_memory_peak |
| total.allocated | allocator當前分配的內存字節數。同info memory的used_memory |
| startup.allocated | Redis啟動占用的內存字節數 |
| replication.backlog | Redis復制積壓緩沖區（replication backlog）內存使用字節數，通過repl-backlog-size參數設置，默認1M |
| clients.slaves | 在master側，所有slave clients消耗的內存字節數 |
| clients.normal | Redis所有常規客戶端消耗內存字節數 |
| overhead.total | Redis額外的總開銷內存字節數； 即分配器分配的總內存total.allocated，減去數據實際存儲使用內存。 |
| keys.count | Redis實例中key的數量 |
| keys.bytes-per-key | 每個key平均占用字節數。注意，overhead也會均攤到每個key上，因此不能以此值來表示業務實際的key平均長度。 |
| dataset.bytes | 表示Redis數據占用的內存容量。即分配的內存總量，減去總的額外開銷內存量。 |
| dataset.percentage | 表示Redis數據占用內存占總內存分配的百分比 |
| peak.percentage | 當前內存使用量與峰值時的占比 |
| fragmentation | 表示Redis的內存碎片率 |
doctor
使用(yong)方(fang)法： memory doctor
used_memory（total.allocated）小于5M，doctor認為內(nei)存使用量過小，不做進一(yi)步診(zhen)斷。當滿(man)足以下(xia)某一(yi)點，Redis會給出診(zhen)斷結果和(he)建議：
- peak分配內存大于當前total_allocated的1.5倍，即peak.allocated/total.allocated > 1.5，說明內存碎片率高，RSS遠大于used_memory
- High fragmentation/fragmentation大于1.4，說明內存碎片率高
- 每個Normal Client平均使用內存大于200KB，說明pipeline可能使用不當，或Pub/Sub客戶端處理消息不及時
- 每個Slave Client平均使用內存大于10MB，說明master的寫入流量過高
purge
使用方法：memory purge
用(yong)途：通(tong)過調用(yong)jemalloc內(nei)部命令(ling)，進行內(nei)存釋放。釋放對(dui)象包括Redis進程(cheng)占用(yong)但(dan)未有效使(shi)用(yong)的內(nei)存，即常說的內(nei)存碎(sui)片。
說明memory purge只適用于(yu)使用jemalloc作為allocator的(de)Redis實例。
Lazy free機制
解決的痛點/問題
Redis是單(dan)線程程序，當運行一個耗時較大的(de)(de)請求(qiu)時，會導致所有請求(qiu)排隊(dui)等待，在請求(qiu)處理完成前，Redis不能(neng)(neng)響應其他請求(qiu)，因此容易引(yin)發性能(neng)(neng)問題(ti)。而Redis刪除大的(de)(de)集(ji)合鍵時，就屬(shu)于(yu)一種比較耗時的(de)(de)請求(qiu)。
原理
Redis 4.0提供的一種(zhong)惰性(xing)刪除(chu)或者說延遲釋(shi)放機制，主要用(yong)于解決(jue)刪除(chu)大key對Redis進程的阻(zu)塞(sai)，從而(er)避免帶來性(xing)能與可用(yong)性(xing)問題。
刪除(chu)key時(shi)，Redis異步(bu)延時(shi)釋放key的內存(cun)，把key釋放操作放在(zai)bio(Background I/O)單獨(du)的子(zi)線程(cheng)處理中。
使用方法
- 主動刪除
- unlink
unlink與(yu)del命令目的(de)(de)一樣(yang)，刪(shan)(shan)(shan)除某個(ge)key。unlink在(zai)刪(shan)(shan)(shan)除集合(he)類(lei)鍵時，如果集合(he)鍵的(de)(de)元素個(ge)數大(da)于64個(ge)，會把內存釋(shi)放操(cao)作，給單獨的(de)(de)bio(Background I/O)線(xian)程來執行。因(yin)此unlink刪(shan)(shan)(shan)除操(cao)作能在(zai)非常短的(de)(de)時間內完(wan)成包含上百萬個(ge)元素的(de)(de)大(da)key刪(shan)(shan)(shan)除。
- flushall /flushdb
通過對flushall/flushdb添加(jia)ASYNC異(yi)步(bu)清理(li)選項，Redis在清理(li)整(zheng)個(ge)實例或(huo)單(dan)個(ge)DB時(shi)，操作都是異(yi)步(bu)的。
- 過期key刪除、大key驅逐刪除
被動刪除(chu)有(you)四種場景(jing)，每種場景(jing)對應(ying)一(yi)個配置(zhi)參數，默認(ren)都是(shi)關閉：
lazyfree-lazy-eviction no //針對redis內存使用達到maxmeory，并設置有淘汰策略時，是否采用lazy free機制
lazyfree-lazy-expire no //針對設置有TTL的鍵，過期后，被redis清理刪除時是否采用lazy free機制
lazyfree-lazy-server-del no //針對有些指令在處理已存在的鍵時，會帶有一個隱式的DEL鍵的操作
slave-lazy-flush no //針對slave進行全量數據同步，slave在加載master的RDB文件前，會運行flushall來清理自己的數據場景
說明以上(shang)配置如需(xu)使用，請(qing)咨詢技(ji)術(shu)服務人(ren)員。
其他新增命令
- swapdb
用(yong)途：交換同(tong)一Redis實例內2個(ge)db的數據。
用法：swapdb dbindex1 dbindex2
- zlexcount
用途：在有序集合(he)中(zhong)，返(fan)回符合(he)條件(jian)的元素(su)個數。
用法：zlexcount key min max
內存使用和性能改進
- 使用更少的內存來存儲相同數量的數據
- 可以對使用的內存進行碎片整理，并逐漸回收
Redis5.0支持的新特性說明
DCS的(de)(de)Redis 5.0版(ban)本(ben)繼承了Redis 4.0版(ban)本(ben)的(de)(de)所有功(gong)能增(zeng)(zeng)強(qiang)以及(ji)新的(de)(de)命令，同時還(huan)兼容開(kai)源Redis 5.0版(ban)本(ben)的(de)(de)新增(zeng)(zeng)特性(xing)。
Stream數據結構
Stream是Redis 5.0引入的(de)(de)一種新數(shu)據類型，它是一個(ge)全(quan)新的(de)(de)支持多播的(de)(de)可持久化消息隊(dui)列。
Redis Stream的(de)結構(gou)示(shi)意(yi)圖如下(xia)圖所(suo)示(shi)，它(ta)是一個可持久化的(de)數據結構(gou)，用一個消(xiao)息(xi)鏈(lian)表(biao)，將所(suo)有加(jia)入進來(lai)的(de)消(xiao)息(xi)都串起來(lai)。
Stream數據結構具有以下特性 ：
- Stream中可以有多個消費者組。
- 每個消費組都含有一個Last_delivered_id，指向消費組當前已消費的最后一個元素（消息）。
- 每個消費組可以含有多個消費者對象，消費者共享消費組中的Last_delivered_id，相同消費組內的消費者存在競爭關系，即一個元素只能被其中一個消費者進行消費。
- 消費者對象內還維持了一個Pending_ids，Pending_ids記錄已發送給客戶端，但是還沒完成ACK（消費確認）的元素id。
- Stream與Redis其他數據結構的比較，見下表。
Stream數據結(jie)構示意圖
Stream與Redis現有數(shu)據結構比較
| 比較項 | Stream | List、Pub/Sub、Zset |
|---|---|---|
| 復雜度 | 獲取元素高效，復雜度為O(logN) | List獲取元素的復雜度為O(N) |
| offset | 支持offset，每個消息元素有唯一id。不會因為新元素加入或者其他元素淘汰而改變id。 | List沒有offset概念，如果有元素被逐出，無法確定最新的元素 |
| 持久化 | 支持消息元素持久化，可以保存到AOF和RDB中。 | Pub/Sub不支持持久化消息。 |
| 消費分組 | 支持消費分組 | Pub/Sub不支持消費分組 |
| 消息確認 | 支持ACK（消費確認） | Pub/Sub不支持 |
| 性能 | Stream性能與消費者數量無明顯關系 | Pub/Sub性能與客戶端數量正相關 |
| 逐出 | 允許按時間線逐出歷史數據，支持block，給予radix tree和listpack，內存開銷少。 | Zset不能重復添加相同元素，不支持逐出和block，內存開銷大。 |
| 刪除元素 | 不能從中間刪除消息元素。 | Zset支持刪除任意元素 |
Stream相關命令介紹
接下來按照使用流程中出現的順序介紹 Stream相關命令 。詳細命令見下表
- 首先使用XADD添加流元素，即創建Stream，添加流元素時可指定消息數量最大保存范圍。
- 然后通過XGROUP創建消費者組。
- 消費者使用XREADGROUP指令進行消費。
- 客戶端消費完畢后使用XACK命令確認消息已消費成功。
Stream相(xiang)關命令介紹
Stream的詳細命令
| 命令 | 說明 | 語法 |
|---|---|---|
| XACK | 從流的消費者組的待處理條目列表 （簡稱PEL）中刪除一條或多條消息。 | XACK key group ID [ID ...] |
| XADD | 將指定的流條目追加到指定key的流中。 如果key不存在，作為運行這個命令的副作用，將使用流的條目自動創建key。 | XADD key ID field string [field string ...] |
| XCLAIM | 在流的消費者組上下文中，此命令改變待處理消息的所有權，因此新的所有者是在命令參數中指定的消費者。 | XCLAIM key group consumer min-idle-time ID [ID ...] [IDLE ms] [TIME ms-unix-time] [RETRYCOUNT count] [FORCE] [JUSTID] |
| XDEL | 從指定流中移除指定的條目，并返回成功刪除的條目的數量，在傳遞的ID不存在的情況下， 返回的數量可能與傳遞的ID數量不同。 | XDEL key ID [ID ...] |
| XGROUP | 該命令用于管理流數據結構關聯的消費者組。使用XGROUP你可以：l 創建與流關聯的新消費者組。l 銷毀一個消費者組。l 從消費者組中移除指定的消費者。l 將消費者組的最后交付ID設置為其他內容。 | XGROUP [CREATE key groupname id-or-] [SETID key id-or- ] [DESTROY key groupname] [DELCONSUMER key groupname consumername] |
| XINFO | 檢索關于流和關聯的消費者組的不同的信息。 | XINFO [CONSUMERS key groupname] key key [HELP] |
| XLEN | 返回流中的條目數。如果指定的key不存在，則此命令返回0，就好像該流為空。 | XLEN key |
| XPENDING | 通過消費者組從流中獲取數據。檢查待處理消息列表的接口，用于觀察和了解消費者組中哪些客戶端是活躍的，哪些消息在等待消費，或者查看是否有空閑的消息。 | XPENDING key group [start end count] [consumer] |
| XRANGE | 返回流中滿足給定ID范圍的條目。 | XRANGE key start end [COUNT count] |
| XREAD | 從一個或者多個流中讀取數據，僅返回ID大于調用者報告的最后接收ID的條目。 | XREAD [COUNT count] [BLOCK milliseconds] STREAMS key [key ...] ID [ID ...] |
| XREADGROUP | XREAD命令的特殊版本，指定消費者組進行讀取。 | XREADGROUP GROUP group consumer [COUNT count] [BLOCK milliseconds] STREAMS key [key ...] ID [ID ...] |
| XREVRANGE | 與XRANGE相同，但顯著的區別是以相反的順序返回條目，并以相反的順序獲取開始-結束參數 | XREVRANGE key end start [COUNT count] |
| XTRIM | XTRIM將流裁剪為指定數量的項目，如有需要，將驅逐舊的項目（ID較小的項目）。 | XTRIM key MAXLEN [~] count |
消息（流元素）消費確認
Stream與相比Pub/Sub，不僅增(zeng)加消費(fei)分組(zu)模式，還支持(chi)消息消費(fei)確認。
當一條消息被某個消費者調用XREADGROUP命令讀取或調用XCLAIM命令接管的時候， 服務器尚不確定它是否至少被處理了一次。 因此， 一旦消費者成功處理完一條消息，它應該調用XACK知會Stream，這樣這個消息就不會被再次處理， 同時關于此消息的PEL（pending_ids）條目也會被清除，從Redis服務器釋放內存 。
某些情況下，因為(wei)網絡問題等，客(ke)戶端消(xiao)(xiao)費(fei)完畢后(hou)沒有(you)調用XACK，這(zhe)時候PEL內會保留對應的(de)元素ID。待客(ke)戶端重(zhong)(zhong)新(xin)連上后(hou)，XREADGROUP的(de)起始消(xiao)(xiao)息(xi)(xi)ID建議(yi)設置(zhi)為(wei)0-0，表示(shi)讀取(qu)所有(you)的(de)PEL消(xiao)(xiao)息(xi)(xi)及自last_id之后(hou)的(de)消(xiao)(xiao)息(xi)(xi)。同時，消(xiao)(xiao)費(fei)者消(xiao)(xiao)費(fei)消(xiao)(xiao)息(xi)(xi)時需要能(neng)夠支(zhi)持消(xiao)(xiao)息(xi)(xi)重(zhong)(zhong)復傳遞。
ACK機制解讀
內存使用優化
Redis 5.0在上(shang)(shang)一(yi)版本(ben)基礎上(shang)(shang)，在內存使(shi)用上(shang)(shang)做(zuo)了(le)進(jin)一(yi)步優化。
- 主動碎片整理
當key被頻繁修(xiu)改(gai)，value長度不斷變化時，Redis會為(wei)key分配(pei)新的(de)內(nei)(nei)存(cun)空間。由于(yu)Redis追求高性(xing)能，實(shi)現了自己的(de)內(nei)(nei)存(cun)分配(pei)器來管理內(nei)(nei)存(cun)，因此并不會將(jiang)原有內(nei)(nei)存(cun)釋放給OS，從而導致出現內(nei)(nei)存(cun)碎片。當used_memory_rss/used_memory高于(yu)1.5，一般認為(wei)內(nei)(nei)存(cun)碎片占比過高，內(nei)(nei)存(cun)利用率低。
因此(ci)，合理規劃和(he)使用緩(huan)存數據，規范數據寫入，有助于減少內存碎(sui)片的(de)產生。
Redis 3.0及以下：可以通(tong)過(guo)定期(qi)重啟服務解決內(nei)存(cun)碎片問題。建(jian)議實際緩存(cun)數據不(bu)超過(guo)配置可用內(nei)存(cun)的50%。
Redis 4.0：支(zhi)持主動整理(li)內(nei)(nei)存(cun)(cun)碎片(pian)，服務在(zai)運行期間進行自動內(nei)(nei)存(cun)(cun)碎片(pian)清理(li)。同時(shi)Redis 4.0支(zhi)持通過memory purge命令(ling)手動清理(li)內(nei)(nei)存(cun)(cun)碎片(pian)。
Redis 5.0：增強版主動碎(sui)片(pian)整理，配合Jemalloc版本更新，更快(kuai)更智能，延時(shi)更低(di)。
- HyperLogLog算法優化
HyperLogLog是一種基數計(ji)(ji)數方法，使用少(shao)量(liang)的(de)內存(cun)空間(jian)完(wan)成海量(liang)數據(ju)的(de)計(ji)(ji)數統計(ji)(ji)，在Redis 5.0中，HyperLogLog算法得到改(gai)進，優化了計(ji)(ji)數統計(ji)(ji)時(shi)的(de)內存(cun)使用效率。
舉(ju)個例子(zi)：B樹計數效率非(fei)常(chang)高，但是內存(cun)消(xiao)耗也(ye)比較多。而HyperLogLog可節省大量存(cun)儲空間。當B樹需要1M內存(cun)統計，HyperLogLog只需要1kb。
- 內存信息統計報告能力增強
INFO命令返回信息更(geng)加詳(xiang)實(shi)。
命令新增和優化
- 客戶端管理增強
- Redis-cli支持集群管理
在Redis 4.0以及之前(qian)版本，需要安裝(zhuang)redis-trib模塊，管理集群。
Redis 5.0對Redis-cli做了優化，集成了集群的所有管理功能。具體使用可以通過命令redis-cli --cluster help查看幫助信息。
- 優化客戶端在頻繁連接與中斷場景下的性能
當您的應(ying)用(yong)需要使用(yong)短(duan)連接(jie)時，這(zhe)個優化價(jia)值凸(tu)顯。
2.有序集合使用更簡單
有序集合新增(zeng)兩個命令：ZPOPMIN和(he)ZPOPMAX。
- ZPOPMIN key [count]
刪除并返回有序集合key中的(de)最(zui)多count個具有最(zui)低(di)得(de)分(fen)的(de)成員。如(ru)果(guo)返回多個成員，也會按照得(de)分(fen)高(gao)低(di)（value值比較），從低(di)到(dao)高(gao)排列。
- ZPOPMAX key [count]
刪除并返回有序集(ji)合key中的最多count個具有最高得分(fen)的成員(yuan)。如果返回多個成員(yuan)，也會(hui)按照得分(fen)高低（value值比較），從(cong)高到低排列。
3.help增加更多子命令說明
支持(chi)help直接(jie)查(cha)看快速(su)使(shi)(shi)用攻(gong)略(lve)，你不(bu)再(zai)需要每次登錄redis.io去查(cha)找。例如，命(ming)令行(xing)輸入stream使(shi)(shi)用攻(gong)略(lve)：xinfo help
127.0.0.1:6379> xinfo help
1) XINFO <subcommand> arg arg ... arg. Subcommands are:
2) CONSUMERS <key> <groupname> -- Show consumer groups of group <groupname>.
3) GROUPS <key> -- Show the stream consumer groups.
4) STREAM <key> -- Show information about the stream.
5) HELP -- Print this help.
127.0.0.1:6379>
4.Redis-cli命令輸入提示
Redis-cli在(zai)輸入完整的(de)命(ming)(ming)令(ling)后，會展示參數提醒，幫(bang)助用戶記憶(yi)命(ming)(ming)令(ling)語(yu)法格式。
如下圖所示，輸入zadd命(ming)令(ling)，Redis-cli使(shi)用淺顏(yan)色字(zi)體顯示zadd的語法。
RDB支持存儲LFU、LRU
Redis 5.0開始，RDB快照文件中增加存儲key逐出策略LRU和 LFU ：
- FIFO：先進先出。最早存儲的數據，優先被淘汰。
- LRU：最近最少使用。長期未使用的數據，優先被淘汰。
LFU：最不(bu)經常使用。在一段時間內，使用次數最少的(de)數據，優先被淘汰。
說明Redis 5.0的RDB文(wen)件格式有(you)變化，向下兼(jian)容。因此如(ru)果使用快照(zhao)的方式遷移(yi)，可(ke)以(yi)從Redis低版(ban)本遷移(yi)到(dao)Redis 5.0，但不能從Redis 5.0遷移(yi)到(dao)低版(ban)本。
DCS實例的CPU規格是怎么樣的
使(shi)用DCS實例的(de)用戶無需關(guan)心(xin)CPU規格(ge)的(de)指標，僅需關(guan)心(xin)QPS，帶寬，內存大小等核心(xin)指標。
Redis實例基(ji)于開源Redis構造(zao)，開源Redis只能使用(yong)單個(ge)(ge)主線程處理(li)命令，因此只能利(li)用(yong)一個(ge)(ge)核(he)(he)的CPU，用(yong)戶只需認為單個(ge)(ge)Redis節點(dian)使用(yong)1核(he)(he)CPU即可。
Redis由于社區版單線(xian)程處(chu)理(li)模(mo)型的(de)限制(zhi)，如(ru)需增加(jia)實(shi)例(li)(li)CPU處(chu)理(li)性(xing)能(neng)，則需要使用集(ji)群類型的(de)Redis實(shi)例(li)(li)，通過增加(jia)分片的(de)方式，來增加(jia)整(zheng)個集(ji)群的(de)處(chu)理(li)性(xing)能(neng)。集(ji)群實(shi)例(li)(li)每個節(jie)點(dian)默認分配1核CPU進行處(chu)理(li)。
如何查詢Redis實例的原生版本
連接需要查詢(xun)的(de)實(shi)例，執行info命(ming)令：
查詢實例信息
