Redis最佳實踐與實戰(zhàn)指南

RedisRedis訓(xùn)練營電子書C-阿里云數(shù)據(jù)庫Redis最佳實踐源碼核心貢獻者帶你學(xué)習(xí)Redis關(guān)鍵技術(shù)1Redis訓(xùn)練營電子書Redis訓(xùn)練營3Redis架構(gòu)與介質(zhì)選擇指引14Redis的開發(fā)規(guī)范和常見問題32Redis的運維實戰(zhàn)46Redis的高并發(fā)實戰(zhàn)：搶購系統(tǒng)60Redis生態(tài)73Redis開發(fā)實操之春運遷徙頁面阿里云Redis官網(wǎng)GitHub-Alibaba/TairStringGitHub-Alibaba/GitHub-Alibaba/TairHashRedis實戰(zhàn)課程微信關(guān)注公眾號：阿里云數(shù)據(jù)庫第一時間，獲取更多技術(shù)干貨阿里云開發(fā)者“藏經(jīng)閣”海量免費電子書下載3Redis訓(xùn)練營電子書4Redis架構(gòu)與介質(zhì)選擇指引Redis集群架構(gòu)Redis集群版標(biāo)準(zhǔn)版集群版雙副本讀寫分離代理模式直連模式單副本雙副本讀寫分離代理模式直連模式雙副本單副本如上圖所示，Redis集群架構(gòu)分為兩大類：標(biāo)準(zhǔn)版與集群版。標(biāo)準(zhǔn)版是最原始的Redis單進程模式，標(biāo)準(zhǔn)版細(xì)分為雙副本、單副本、讀寫分離三個類別。集群版分為代理模式與直連模式。業(yè)務(wù)從標(biāo)準(zhǔn)版遷移到集群版時的可能存在Redis命令不兼容，代理模式可以通過Proxy幫業(yè)務(wù)解決這方面問題。直連模式中，RedisClient通過RedisCluster模式直連RedisDB節(jié)點，做到減少網(wǎng)絡(luò)時延，提（一）標(biāo)準(zhǔn)版ECSECSECSSLB:Classic/VPCSLB:Classic/VPCSLB:Classic/VPC進程BReplicaProcessA進程BReplicaProcessAMasterProcessB故障遷移Failover故障遷移HAHAHA如上圖所示，標(biāo)準(zhǔn)版的拓?fù)浣Y(jié)構(gòu)是業(yè)務(wù)在ECS直接通過SLB連接到后端的Redis節(jié)點。這里Redis節(jié)點會有兩種情況，第一種情況是左圖的一組一備，進程B是一個熱備，主備之間數(shù)據(jù)直接進行同步。第二種情況是右圖的冷備，只有在主節(jié)點·使用場景：2.單個Redis性能壓力可控的場景；3.Redis命令相對簡單，排序和計算之類的命令較少的場景。1.標(biāo)準(zhǔn)版-雙副本ECSSLB:Classic/VPC進程AMaster進程BReplica進程AMaster故障遷移HA標(biāo)準(zhǔn)版-雙副本模式采用主從（Master-Replica）模式搭建。主節(jié)點提供日常服務(wù)訪問，備節(jié)點提供HA高可用，當(dāng)主節(jié)點發(fā)生故障，系統(tǒng)會自動在30秒內(nèi)切換至備節(jié)點·特點：1.可靠性：采用雙機主從（Master-Replica）架構(gòu)，主從節(jié)點位于不同物理機。主節(jié)點對外提供訪問，用戶可通過Redis命令行和通用客戶端進行數(shù)據(jù)的增刪改查操作。當(dāng)主節(jié)點出現(xiàn)故障，自研的HA系統(tǒng)會自動進行主從切換，保證2.數(shù)據(jù)可靠：默認(rèn)開啟數(shù)據(jù)持久化功能，數(shù)據(jù)全部落盤。支持?jǐn)?shù)據(jù)備份功能，用戶可以針對備份集回滾實例或者克隆實例，有效地解決數(shù)據(jù)誤操作等問題。同時，在支持容災(zāi)的可用區(qū)（例如杭州可用區(qū)H+I）創(chuàng)建的實例，還具備同城兩個副本之間的數(shù)據(jù)實時異步同步，切換主備時可能存在延遲情況。當(dāng)主節(jié)點宕機的時候，可能存在一部分?jǐn)?shù)據(jù)沒有同步到B進程（即備節(jié)點）上，此時如果進行主備切換，B進程相對于A進程有同步延遲，可能存在部分?jǐn)?shù)據(jù)此外，在雙副本中可以做數(shù)據(jù)的克隆，即備份機，備份到另一個地方做數(shù)據(jù)持久化。當(dāng)業(yè)務(wù)需要做數(shù)據(jù)回滾時，可以從備5Redis訓(xùn)練營電子書62.標(biāo)準(zhǔn)版-單副本ECSSLB:Classic/VPCProcessBProcessAMasterProcessBFailoverHA標(biāo)準(zhǔn)版-單副本采用單個數(shù)據(jù)庫節(jié)點部署架構(gòu)，沒有可實時同步數(shù)據(jù)的備用節(jié)點，不提供數(shù)據(jù)持久化和備份策略，使用于·特點：2.阿里云自研HA高可用系統(tǒng)，異常30秒自動切換。單副本在使用時需要注意，當(dāng)高可用節(jié)點A宕機后，需要先對B節(jié)點進行緩存的預(yù)熱，避免切換后發(fā)現(xiàn)B節(jié)點無數(shù)據(jù)可用。3.讀寫分離Proxy節(jié)點ECS實例讀請求讀請求讀請求讀請求讀請求讀請求數(shù)據(jù)分片…同步數(shù)據(jù)主節(jié)點只讀節(jié)點1同步數(shù)據(jù)主節(jié)點只讀節(jié)點1只讀節(jié)點2高可用系統(tǒng)監(jiān)控所有節(jié)點主節(jié)點針對讀多寫少的業(yè)務(wù)場景，云數(shù)據(jù)庫Redis推出了讀寫分離版的產(chǎn)品形態(tài)，提供高可用、高性能、靈活的讀寫分離服務(wù)，ECS實例通過Proxy節(jié)點，可以將讀寫請求分發(fā)到主節(jié)點數(shù)據(jù)分片，并將部分讀請求分發(fā)到其他只讀節(jié)點?！な褂脠鼍埃?.讀取請求QPS壓力較大：適合讀多寫少型業(yè)務(wù)；2.對Redis協(xié)議兼容要求較高的業(yè)務(wù)。·建議與使用須知：1.非特殊需求不建議使用，QPS壓力大的業(yè)務(wù)建議使用集群版；2.當(dāng)一個只讀節(jié)點發(fā)生故障時，請求會轉(zhuǎn)發(fā)到其他節(jié)點；如果所有只讀節(jié)點均不可用，請求會全部轉(zhuǎn)發(fā)到主節(jié)點，導(dǎo)4.只讀節(jié)點數(shù)據(jù)舊于主節(jié)點且落后時間可能很（二）集群版ECSECSECSSLB:Classic/VPCSLB:Classic/VPCSLB:Classic/VPCConfigProxyProxy…………ConfigServersServerServersServerConfigProxyProxy…………ConfigServersServerMaster2MasterNMaster2Master1Master1MasterNMaster2MasterNMaster2Master1Master1HAHA……HAHAHA……Replica2Replica1ReplicaNReplica2Replica1·使用場景：2.QPS壓力較大的場景；7Redis訓(xùn)練營電子書81.集群版-雙副本ECSSLB:Classic/VPCProxy……ServersServerConfigProxy……ServersServerMaster2Master1MasterNMaster2Master1HAHA……HAHAHA……Replica2Replica1ReplicaNReplica2Replica1Proxy代理模式云數(shù)據(jù)庫Redis版提供雙副本集群版實例，可輕松突破Redis自身單線程瓶頸，滿足大容量、高性能的業(yè)務(wù)需求。集群版支·使用場景：2.QPS壓力較大：標(biāo)準(zhǔn)版Redis無法支撐較大的QPS，需要采用多分片的部署方式來突破Redis單線程的性能瓶頸；3.吞吐密集型應(yīng)用：相比Redis標(biāo)準(zhǔn)版，集群版的內(nèi)網(wǎng)吞吐限制相對較低，可以更好地支持熱點數(shù)據(jù)讀取、大吞吐類4.對Redis協(xié)議兼容性不敏感的應(yīng)用：集群版對Redis協(xié)議支持上相比標(biāo)準(zhǔn)版本有一定的限制。FirsttimeECSSLBFirsttimeECSRedisClusterProtocolRedisClusterProtocolVIPVIPVIPVIPVIPVIPMaster1Master2MasterMaster1Master2HAHA……HAHAHA……Replica1Replica2ReplicaNReplica1Replica2·特點：代理模式因所有請求都需要通過代理服務(wù)器轉(zhuǎn)發(fā)，代理模式在降低業(yè)務(wù)開發(fā)難度的同時也會小幅度影響Redis服務(wù)的響應(yīng)速度，如果業(yè)務(wù)響應(yīng)速度的要求非常高，可以選擇直連模式，繞過代理服務(wù)器直連后端數(shù)據(jù)分片，從而降低網(wǎng)絡(luò)開銷和服2.集群版-命令限制·不支持命令1.SWAPDB2.CLIENTID3.SORT(BY和GET)·受限命令在集群模式下如果需要執(zhí)行受限制的命令，需要使用HashTag確保所要操作的Key在同個HashSlot中，HashTag的詳細(xì)用法參見Redis官方文檔。PFMERGE,PFCOUNTRENAME,RENAMENX,SORTPFMERGE,PFCOUNTRENAME,RENAMENX,SORTRPOPLPUSH,BRPOP,BLPOP,BRPOPLPUSHEVAL,EVALSHA,SCRIPTEXISTS,SCRIPTFLUSH,SCRIPTKILL,SCRIPTLOADMSETNXDISCARD,EXEC,MULTI,UNWATCH,WATCHKeysListsScriptingStringsTransaction因為集群版會根據(jù)數(shù)據(jù)的Key做一次性Hash，分散到不同的數(shù)據(jù)節(jié)點上，這些涉及到多Key的命令，key經(jīng)過Hash后如果分布在不同的節(jié)點上，命令就不能在一個單數(shù)據(jù)節(jié)點被Hash到同一個Slot上，在同一個Slot中，這些受限的命令就可以支持?！ua腳本使用限制：1.所有Key都應(yīng)該由KEYS數(shù)組來傳遞；5.不支持UNPACK函數(shù)；6.其他詳細(xì)限制參見Redis官方文檔。9Redis訓(xùn)練營電子書103.集群模式如何選型·選型時應(yīng)注意以下兩點：1.評估QPS和容量時一定要為未來留有余量；StartStart高低高低QPSQPS高低高標(biāo)準(zhǔn)版標(biāo)準(zhǔn)版如上圖所示，簡言之，如果業(yè)務(wù)qps低且容量低（小于32GB）選擇標(biāo)準(zhǔn)版，否則選擇集群版。標(biāo)準(zhǔn)版標(biāo)準(zhǔn)版低高低高是否可靠性是否可靠性讀多寫少讀多寫少單副本讀寫分離雙副本單副本讀寫分離雙副本如果業(yè)務(wù)數(shù)據(jù)單純作為緩存加速或數(shù)據(jù)可丟，可以選擇單副本，減少一半的成本。如果要求數(shù)據(jù)在異常情況下不能全部丟如果讀寫情況沒有明顯差異，可以選擇雙副本，如果讀請求數(shù)量遠(yuǎn)大于寫請求，可以選擇讀寫分離。但是除去特殊情況，讀寫分離有諸多限制，大多數(shù)情況下不是一個很好的集群版高低高兼容性代理模式直連模式代理模式低高低可靠性單副本雙副本單副本如果用戶原本使用標(biāo)準(zhǔn)版，隨著業(yè)務(wù)的發(fā)展QPS容量上升，需要由標(biāo)準(zhǔn)版切換成集群版，根據(jù)命令兼容性可選擇不同如果用戶業(yè)務(wù)代碼有太多需要修改，或者不想修改代碼，對命令兼容性要求較高，可以選擇代理模式，兼容性問題由阿里云提供的Proxy解決。如果業(yè)務(wù)對兼容性要求較低，或者新業(yè)務(wù)在開發(fā)時本就是按照集群版標(biāo)準(zhǔn)進行，則可選擇直連模式選擇完之后，可根據(jù)業(yè)務(wù)對數(shù)據(jù)可靠性的要求，進一步選擇單副本或雙副本。此處的單雙副本使用注意事項，與標(biāo)準(zhǔn)Redis存儲介質(zhì)RedisRedis持久內(nèi)存型混合存儲型持久內(nèi)存型混合存儲型容量存儲型容量存儲型（一）持久內(nèi)存型MemoryHierarchySize:1xLatency:1xProcessingSize:1xLatency:1xProcessingCPUSize:10xLatency:100xDRAMNVDIMMSize:10xLatency:100xDRAMNVDIMMSize:100xLatency:1,000xSCMSize:100xLatency:100,000xSSDSize:10,000xHDDMemoryStorageSize:100xLatency:1,000xSCMSize:100xLatency:100,000xSSDSize:10,000xHDDMemoryStorageLatency:10,000,000xLatency:10,000,000xRedis企業(yè)版持久內(nèi)存型（簡稱持久內(nèi)存型）基于Intel傲騰TM數(shù)據(jù)中心級持久內(nèi)存（AEP），為用戶提供大容量、兼容Redis的內(nèi)存數(shù)據(jù)庫產(chǎn)品。單實例成本對比Redis社區(qū)版最高可降低30%，且數(shù)據(jù)持久化不依賴傳統(tǒng)磁盤，保證每個操作持·特點：11Redis訓(xùn)練營電子書12（二）容量存儲型Redis企業(yè)版容量存儲型（簡稱容量存儲型）基于云盤ESSD研發(fā)，兼容Redis核心數(shù)據(jù)結(jié)構(gòu)與接口，可提供大容量、低成本、強持久化的數(shù)據(jù)庫服務(wù)。容量存儲型在降低成本和提升數(shù)據(jù)·特點：開源版Redis阿里云Redis開源版Redis阿里云Redis大Key遷移影響服務(wù)RT，嚴(yán)重時觸發(fā)HALua腳本丟失遷移期間多key命令失敗高集群模式有額外內(nèi)存開銷，大key小value故障切換時間平均8秒，SLA15秒低阿里云Redis與開源版Redis集群能力對比（二）開源Redis集群實現(xiàn)GossipGossipClientAClientCClientAClientCClientBClientB·實現(xiàn)細(xì)節(jié)：·優(yōu)點：·缺點：（三）阿里云Redis集群實現(xiàn)RaftRaftClientCClientAClientBClientCClientAClientB·實現(xiàn)細(xì)節(jié)：·優(yōu)點：13Redis訓(xùn)練營電子書143.擴縮容業(yè)務(wù)無感知（大Key，多keRedis的開發(fā)規(guī)范和常見問題Redis-從問題說起（一）Run-to-Completioninasolothread-Redis最大的問題Redis最大的問題是后臺主要線程是一個單線程，如下圖所示，用戶所有的來自不同client的請求，實際上在每個event到來后，交由后端單線程執(zhí)行。等每個event處理完成后，才處理下一個；單線程run-to-completion就是沒有dispatcher，沒有后端的multi-worker。所以如果慢查詢，諸如單機版的keys、lrange1、用戶所有的來自不同client的請求，實際上在每個event到來后，交由后端單線程執(zhí)行。等每個event處理完成后，才處理下一個。2、單線程run-to-completion就是沒有dispatcher，沒有后端的multi-workerRedisClient1、SETkey1value1RedisClient3、UNLINKKey3TCPrecv()ProcessTCPrecv()ProcessTCPsend()1232、SADDSkeyPkey1RedisClient如果慢查詢諸如單機版的keys，和 trange，hgetall等拖慢了一次查詢，那么后面的請求就會被拖慢·DuplexFailure：sentinel由于慢查詢切備（備變主）再遇到慢查詢，Redis將出現(xiàn)OOS。既然一個Redis進程不行，采用分布式方案擴展成集群版可以嗎？集群板確實能解決一部分問題，常見的請求是可以分散到不同DB上的。但是，集群版也還是解決不了單個DB被卡住的問題，因為Redis的keyhash規(guī)則是按照外面的一層PK來做的，沒有按照里面的子key或者是field的來做，如果用戶調(diào)用了跨分片的命令，如mget，訪問到出問題的db，仍會block住，問題還是會15Redis訓(xùn)練營電子書161、同樣的，集群版解決不了單個DB被卡住的問題2、查詢空洞：如果用戶調(diào)用了跨分片的命令，如mget1、同樣的，集群版解決不了單個DB被卡住的問題2、查詢空洞：如果用戶調(diào)用了跨分片的命令，如mget，訪問到出問題的db，仍會block住TCPrecv()ProcessTCPsend()epoll__wait 3epoll__wait 38:9999 2 DatasetDatasetTCPrecv()TCPrecv()ProcessTCPsend()epoll__wait 38:10000 2ProxyDatasetDataset…ProxyProxy…ProxyProxyTCPrecv()ProcessTCPsend()epoll__wait 3epoll__wait 30:9999 2DatasetDataset（三）Protocol問題-大量客戶端與引擎Fully-Meshed問題采用Redis協(xié)議（RESP）的問題:·擴展性太差：基于Question-Answer模式，由于在Question/Answer里面沒有對應(yīng)的Sequence的存在，(如果不做復(fù)雜的轉(zhuǎn)換wrapper層)存儲引擎端沒法match請求和響應(yīng)，只能采用Run-To-Completion來掛住鏈接;setkva*3\r\n$3\r\nSET\r\n$1\r\nk\r\n$2\r\nva\r\n1、RESP協(xié)議使用‘\r\n’作為行結(jié)尾（EOL）1、‘*3’代表Array1、RESP協(xié)議使用‘\r\n’作為行結(jié)尾（EOL）2、每一個子串，‘$n’代表這個串內(nèi)結(jié)構(gòu)有多長大鏈接（active）平均響應(yīng)時間（ms）2.521.510.50NormalC大鏈接（active）平均響應(yīng)時間（ms）2.521.510.50NormalC2KC4KC10KC10K10min12001000900800700600500400大鏈接（active）32子實例OPS（KOPS/s）NormalC2KC4KC10KC10K10minGETMGETRT-99%RT-95RT-80%RT-AVGGETMGET（四）“Couldnotgetaresourcefromthepool”如下圖所示，由于Redis執(zhí)行Run-To-Completion特性，客戶端只能采用連接池的方案；Redis協(xié)議不支持連接池收斂，是因為Message沒有ID，所以Request和Response對不起來。連接池具體運作方式是每次查詢，都要先從連接池拿出SLOW當(dāng)Engine層出現(xiàn)慢查詢，就會讓請求返回的慢·很容易讓用戶把連接池用光·當(dāng)應(yīng)用機器特別多的情況，按每個SLOW當(dāng)Engine層出現(xiàn)慢查詢，就會讓請求返回的慢·很容易讓用戶把連接池用光·當(dāng)應(yīng)用機器特別多的情況，按每個client連接池50個maxlink來算，很容易打到10K鏈接的限制，導(dǎo)致engine回調(diào)速度慢1、SETkey1value121、SETkey1value12、HGETALLbigkey11、OKRedisClient1、OKRedisClient之所以使用連接池，是因為Redis協(xié)議不支持連接收斂·Message沒有ID，所以Request和Response對不起來·非常類似HTTP1.x消息RedisClientRedisClient1、每次查詢，都要先從連接池拿出一根連接來，當(dāng)返回后，再放回連接池RedisClient2、如果用戶返回的及時，那么連接池一直保有的連接數(shù)并不高1、每次查詢，都要先從連接池拿出一根連接來，當(dāng)返回后，再放回連接池RedisClient2、如果用戶返回的及時，那么連接池一直保有的連接數(shù)并不高·但是一旦返回不了，又有新的請求，就只能再checkout一根連接·當(dāng)連接池被checkout完，就會爆沒有連接的異常：“Couldnotgetaresourcefromthepool”如果用戶返回的及時，那么連接池一直保有的連接數(shù)并不高，但是一旦服務(wù)端未及時返回，客戶端又有新的請求，就只能當(dāng)Engine層出現(xiàn)慢查詢，就會讓請求返回的慢，造成的后果是很容易讓用戶把連接池用光，當(dāng)應(yīng)用機器特別多的情況，按有惡性循環(huán)的邏輯在里面。比如說服務(wù)端返回的慢，連接池的連接就會創(chuàng)建的很快，用戶17Redis訓(xùn)練營電子書18Redis-不要觸碰邊界Redis的邊界--紅色區(qū)域代表危險上述羅列的問題，是為了讓我們在開發(fā)業(yè)務(wù)的時候，不要觸碰Redis的邊界。下面從計算、存儲、網(wǎng)絡(luò)三個維度出發(fā)，總高計算消耗WildcardLua并發(fā)1對NPUBSUBN>200企業(yè)版（Tair）較好模塊結(jié)構(gòu)化操作復(fù)雜Lua事務(wù)通用命令運算點查通用命令運算高并發(fā)訪問Keys等掃全表復(fù)雜結(jié)構(gòu)小range集群mget/msetStreaming慢消費HugeBatchmget/mset超大規(guī)模連接數(shù)HugeBatchmget/mset企業(yè)版（Tair）較好大量冷存企業(yè)版（Tair）較好BigkeyBigkeyRange大BigkeyBigkeyRange高網(wǎng)絡(luò)消耗高存儲消耗如hgetall，smembers高網(wǎng)絡(luò)消耗高存儲消耗計算方面：Wildcard、Lua并發(fā)、1對NPUBSUB、全局配置/熱點，會大量消耗計算資源（高計算消耗）；存儲方面：Streaming慢消費、Bigkey等，造成高存儲消耗。網(wǎng)絡(luò)方面：Keys等掃全表、HugeBatchmget/mset、大Value、BigkeyRange（如hgetall，smembers），造成高網(wǎng)·高并發(fā)不等于高吞吐·數(shù)據(jù)傾斜和算力傾斜大Range的問題：對NoSQL的慢查詢和導(dǎo)致的危害沒有足夠的重視。·存儲邊界·對于Latency的理解問題（RT高）存儲引擎的Latency都是P99Latency，如：99.99%在1ms以內(nèi)，99.5%在3ms以內(nèi)，等；Redis-阿里內(nèi)部開發(fā)規(guī)約Redis的使用建議·確定場景，是緩存（cache）還是存儲型；·Cache的使用原則是：“無它也可，有它更強”；·永遠(yuǎn)不要強依賴Cache，它會丟，也會被淘汰；·優(yōu)先設(shè)計合理的數(shù)據(jù)結(jié)構(gòu)和邏輯；·設(shè)計避免bigKey，就避免了80%的問題；·Keyspace能分開，就多申請幾個Redis實例；·pubsub不適合做消息分發(fā)；·盡量避免用lua做事務(wù)?！の业姆?wù)對RT很敏感。>>低RT能讓我的服務(wù)運行的更好;·我把存儲都公用在一個redis里。>>區(qū)分cache和內(nèi)存數(shù)據(jù)庫用法，區(qū)分應(yīng)用;·我有一個大排行榜/大集合/大鏈表/消息隊列；我覺得服務(wù)能力足夠了。>>集群版可以打散;·我有一個特別大的Value，存在redis里，訪問能好些。>>redis吞吐量有瓶頸。（一）BigKey-洪水猛獸BigKey，我們稱之為洪水猛獸，據(jù)初步統(tǒng)計，80%問題由bigKey導(dǎo)致。如下圖所示：集群中有4個分片，每個分片大約有102個key，實際上是均勻分布。圖中第三個key叫key301，hash301，中間有一個放了200w的hash，但因為根據(jù)hash301打散的這個key是個bigkey，嚴(yán)19Redis訓(xùn)練營電子書20101101個key，中間有一個放了200w的hashKey300val300Hash301skey1val1skey2val2…skey200000val2000000…key401val401Key1val1key2val2…key100val100Key1val1key2val2…key100val100Key500val500key501val501…key602val602Key200val200key201val201…key302val302ShardingFunction各個分片的實際各個分片的實際Key個數(shù)，容量，應(yīng)該都大差不差，但因為根據(jù)hash301打散的這個key是個bigkey，嚴(yán)重造成數(shù)據(jù)傾斜別的key只用了10%或20%的內(nèi)存，key301用了約80%，而且大概率是熱點。上圖的使用用法，有可能造成有一個分片內(nèi)存滿了，訪問出了問題，但是其他分片卻用的很閑。問題分片的訪問比較熱，造成網(wǎng)卡打滿，或者CPU打滿，導(dǎo)致限（二）RedisLUAJIT下面的示意圖表示了一次腳本的執(zhí)行過程，客戶端調(diào)用EVALscript之后會產(chǎn)生SCRIPTLoad的行為，LuaJIT開始編譯生成字節(jié)碼，這時產(chǎn)生一個SHA字符串，表示bytecode的緩存。Loadingbytecode之后，開始執(zhí)行腳本，還需要保證在ReturnResultEVALscriptSCRIPTLoadLuaJITCompileReturnSHATheLUAIceberginsideRedisReturnSHATheLUAIceberginsideRedis1、腳本的compile-load-run-unload非常耗費CPU2、整個lua相當(dāng)于把復(fù)雜事務(wù)推送到Redis中執(zhí)行，如果稍有不慎內(nèi)存會爆，引擎算力耗光后掛住redisRecordSHAEVALSHAGuardedbyTXNRunWithParamEVALSHAReturnResultprocessCommandunloadprocessCommandunload1、可以先把腳本在redis中預(yù)編譯和加載（不會unload和clean），使用EVALSHA執(zhí)行CleaningRedis2、會比純EVAL省CPU，但是Redis重啟/切換/變配codecache會失效，需要reloadCleaningRedis3、仍是缺陷方案。建議使用復(fù)雜數(shù)據(jù)結(jié)構(gòu)，或者module來取代lua示意圖中有3個火形圖標(biāo)，表示耗費CPU的程度，腳本的compile-load-run-unload非常耗費CPU。整個lua相當(dāng)于把復(fù)雜事務(wù)推送到Redis中執(zhí)行，如果稍有不慎CPU會爆，引擎算力耗光后掛住redis。clean），使用EVALSHA執(zhí)行，會比純EVAL省CPU，但是Redis重啟/切換/變配bytecodecache會失效，需要reload，·對于JIT技術(shù)在存儲引擎中而言，“EVALisevil”，盡量避免使用lua耗費內(nèi)存和計算資源（省事不省心）；·某些SDK（如Redisson）很多高級實現(xiàn)都內(nèi)置使用lua，開發(fā)者可能莫名走入CPU運算風(fēng)暴中，須謹(jǐn)慎。（三）Pubsub/Transaction/PipelinePubsub的典型場景Pubsub適合悲觀鎖和簡單信號，不適合穩(wěn)定的更新，因為可能會丟消息。在1對N的消息轉(zhuǎn)發(fā)通道中，服務(wù)瓶頸。還有模糊通知方面，算力瓶頸。在channel和client比較多的情況下，造成CPU打滿、服務(wù)夯住。TransactionTransaction是一種偽事物，沒有回滾條件；集群版需要所有key使用hashtag保證，代碼比較復(fù)雜，hashtag也可能導(dǎo)致算力和存儲傾斜；Lua中封裝了multi-exec，但更耗費CPU，比如編譯、加載時，經(jīng)常出現(xiàn)問題。PipelinePipeline用的比較多，如下面的示意圖，實際上是把多個請求封裝在一個請求中，合并在一個請求里發(fā)送，服務(wù)端一次性返回，能夠有效減少IO，提高執(zhí)行效率。需要注意的是，用戶需要聚合小的命令，避免在pipeline里做大range。注意Pipeline中的批量任務(wù)不是原子執(zhí)行ApplicationApplicationApplicationApplicationSETkey1123SETkey1SETkey1123123OKINCRkey1INCRkey1INCRkey1OKINCRkey1OK124OK124125INCRkey1125PipelinedNormalPipelined（四）KEYS命令KEYS命令，一定會出問題，即使當(dāng)前沒有，客戶數(shù)據(jù)量上漲后必然引發(fā)慢查，出現(xiàn)后無能為力。這種情況，需要在一開始就提前預(yù)防，可以在控制臺通過危險命令禁用，禁止掉keys命令，出現(xiàn)時也可以使用一些手段優(yōu)化。KEYS命令的模糊匹配：·Redis存儲key是無序的，匹配時必然全表掃描，key數(shù)目一多必然卡住，所以一定要去優(yōu)化?！た梢詮娜頀呙枳?yōu)辄c查/部分range,雖然hash結(jié)構(gòu)中field太多也會慢，但比keys性能提升一個到兩個數(shù)量級。21Redis訓(xùn)練營電子書22這個例子里面，Product1前綴可以提取成為hash的KEY，如果要去product1前綴的所有東西，其實可以下發(fā)一個HGETALL，這樣的就是優(yōu)化了。一定會出問題（soonerorlater）·客戶數(shù)據(jù)量上漲后必然引發(fā)的慢查·出現(xiàn)后無能為力·可以在控制臺通過危險命令禁用·優(yōu)化KEYSKEYS命令的模糊匹配：·Redis的存儲key是無序的，必然全表掃描·Key數(shù)目一多必然卡住product__23::nameproduct__7788::descproduct__32123::priceiamotherkey::11random::nameproduct__1::nameKEYSproduct__1::*redis::is::not::orderedKEYSproduct__1::*hello::slowlogproduct__11::whatever……product__1::price……name:iphoneprice:2999name:iphoneprice:2999HGETALLproduct__1修改為修改為hash結(jié)構(gòu)：·安全表掃描為點查/部分range·雖然hash結(jié)構(gòu)中field太多也會慢，但比keys性能提升一個到兩個數(shù)量級productproduct__23::nameproduct__7788::descproduct__32123::priceiamotherkey::11random::nameproduct__1namepriceredis::is::not::orderedhello::slowlogproduct__11::whatever……（五）除去KEYS，下面命令依然危險·hgetall，smembers，lrange，zrange，exhgetall直接與數(shù)據(jù)結(jié)構(gòu)的subkey（field）多少相關(guān)，O(n)，攜帶va建議使用scan來替代?！itop，bitset·flushall，flushdb用戶在操作的時候，需要很小心，因為會清空數(shù)據(jù)庫。在阿里云Redis控制臺里面點清除數(shù)據(jù)時，需要使用二次校驗，避免隨意清除數(shù)據(jù)。另外還可以單獨清理過期數(shù)·配置中和ziplist相關(guān)的參數(shù)Redis在存儲相關(guān)數(shù)據(jù)結(jié)構(gòu)時，數(shù)據(jù)量比較小，底層使用了ziplist結(jié)構(gòu)，達(dá)到一定的量級，比如k換數(shù)據(jù)結(jié)構(gòu)。當(dāng)結(jié)構(gòu)在ziplist結(jié)構(gòu)體下時，算力開銷變大，部分查詢變O(n)級別，匹配變O(m*n)，極端情況容易打滿CPU，不過占用的內(nèi)存確實變少了（需要評估帶來的收益是否匹配付出的代價？）。規(guī)范總結(jié)[JustFYI]1.選型：用戶需要確定場景是cache還是內(nèi)存數(shù)據(jù)庫使用·Cache場景，關(guān)閉AOF；內(nèi)存數(shù)據(jù)庫選擇雙副本·如果keyspace能夠分開，就申請不同的實例來隔離2.使用：避免觸發(fā)高速存儲的邊界·避免使用keys，hgetall，lrange0-1等大range（使用scan替代）·避免使用大value（10k以上就算大value，50k會記錄）3.SDK：使用規(guī)范·嚴(yán)禁設(shè)置低讀超時和緊密重試（建議設(shè)置200ms以下readtimeout）·需要接受P99時延，對超時和慢做容錯處理·盡量使用擴展數(shù)據(jù)結(jié)構(gòu)，避免使用lua·盡量避免pubsub和blocking的API4.接受主動運維·在阿里云上，如果機器宕機，或者是機器后面有風(fēng)險，我們會做主動運維保證服務(wù)的穩(wěn)定性。Redis-常見問題處理（一）Tair/Redis內(nèi)存模型內(nèi)存控制是Redis的精華部分，大部分遇到的問題都是跟內(nèi)存有，Tair/Redis內(nèi)存模型，如下圖所示，總內(nèi)存分為3個部分：鏈路內(nèi)存（動態(tài)）、數(shù)據(jù)內(nèi)存、管理內(nèi)存（靜況下比較小，但是當(dāng)Range操作的時候，或者有大key收發(fā)比較慢的時候，這兩個區(qū)的內(nèi)存會增大，影響數(shù)據(jù)區(qū)，甚至?xí)斐蒓OM。還包括JITOverhead、FakeLuaLink，包含了Codecache執(zhí)行緩存等等?！?shù)據(jù)內(nèi)存：用戶數(shù)據(jù)區(qū)，就是用戶實際存儲的value?！す芾韮?nèi)存（靜態(tài)）：是靜態(tài)buff，啟動的時候比較小，比較恒定。這個區(qū)域主要管理data的hash開銷，當(dāng)key非常多的時候，比如幾千萬、幾個億，會占用非常大的內(nèi)存。還包括Repl-buff、aof-buff（32M～623Redis訓(xùn)練營電子書24PerlinkMem1、正常較小2、RangePerlinkMem1、正常較小2、Range操作/快發(fā)慢收3、影響數(shù)據(jù)區(qū)ODM靜態(tài)buff1、啟動較小，比較恒定2、管理data的hash開銷3、Key-to-slot：每key到槽4、Repl-buff,aof-buff(32M-64M)InputbuffInputbuffUserDatasetMgrbuffUserDatasetMgrbuff+memOutputLuaJITMem1、CodecacheLuaJITMem1、Codecache2、偽裝成link3、Lua執(zhí)行緩存JITOverheadFakeLuaLinkJITOverhead），動態(tài)內(nèi)存極速飆升，造成OOM；無所畏懼的Lua腳本也有可能造成OOM。存接近UserDataset。（二）緩存分析-內(nèi)存分布統(tǒng)計、bigKey，keypattern對于內(nèi)存，阿里云有現(xiàn)成的功能一鍵分析，使用入口在“實例管理”-》“CloudDBA”下面的“緩存分析”，熱Key分析無需主動觸發(fā)。數(shù)據(jù)源支持歷史備份集，現(xiàn)有備份集，可以準(zhǔn)實時或者對歷史備份做分析。支持線上所有的社區(qū)版和企·“實例管理”-->“CloudDBA”-->“緩存分析”-->“立即分析”；熱Key分析無需主動觸發(fā)?！ぶС忠延袀浞菁?；·支持自動新建備份集?！ど鐓^(qū)版（2.8~6.0·企業(yè)版（Tair）?！?biāo)準(zhǔn)版；·讀寫分離版；·集群版。下圖所示，是阿里云控制臺使用截圖，這個功能下圖所示，是緩存分析報告，可以看到每一個DB內(nèi)存分布統(tǒng)計，包括不同類型的數(shù)據(jù)結(jié)構(gòu)內(nèi)存統(tǒng)計，key對應(yīng)的元素數(shù)分級統(tǒng)計，可以統(tǒng)計到總體上大概有多少個大key；統(tǒng)計key過期時間分布，可以發(fā)現(xiàn)過期時間設(shè)置的是否合BigKey(按內(nèi)存)，可以發(fā)現(xiàn)具體有哪些大key，業(yè)務(wù)上可以參照這個做優(yōu)化。Top100BigKey前綴是做了keyp計，如果key是按照業(yè)務(wù)模塊來制定的前綴，可以統(tǒng)計到各個業(yè)務(wù)上用了多少內(nèi)存，也可以大體上指25Redis訓(xùn)練營電子書26（三）熱Key分析（四）Tair/Redis全鏈路診斷在線實時分析熱key·使用入口：“實例管理”-->“CloudDBA”-->“緩存分析”-->“HotKey”；·使用須知：Tair版，或Redis版本>=redis4.0；·精確統(tǒng)計（非采樣），能抓出當(dāng)前所有PerKeyQPS>3000的記錄；離線分析熱key·方法1：緩存分析也可以分析出相對較熱的key，通過工具實現(xiàn)；·方法2：最佳實踐，imonitor命令+redis-faina分析出熱點Key；Tair/Redis全鏈路診斷，從“APP端的SDK”到“網(wǎng)絡(luò)”到“VIP”到“Proxy”再到“DB”，每個部分都有可能會出問題排查包括：前端排查和后端排查。前段排查首先需要確定是一臺出問題，還是全部有問題，如果是一臺出問題，大概·ECS2.PPS限制?！た蛻舳?.建鏈接慢（K8sDNS等·網(wǎng)絡(luò)后端排查：主要是慢查和CPU排查，包括·VIP（SLB/NGLB））；·Proxy）；4.Backend網(wǎng)絡(luò)抖動?！B）；27Redis訓(xùn)練營電子書28前端排查：一臺出問題，還是全部有問題前端排查：一臺出問題，還是全部有問題ECS1、Load，內(nèi)存等ECS1、Load，內(nèi)存等2、PPS限制3、消息堆積4、Backend網(wǎng)絡(luò)抖動2、運營商網(wǎng)絡(luò)抖動APPSDKVIPAPPSDKVIP(SLB/NGLB)2、流量不均衡（少）VIP(SLB/NGLB)2、流量不均衡（少）3、流量瓶頸（極少）DB1、容量，CPU，流量（見前文）2、主機故障，HA速度3、慢查詢2、RT高（跨地域，gc等）3、建鏈接慢（K8sDNS等）4、大查詢，發(fā)快收慢Tair/Redis80%的問題是RT（latency）相關(guān)后端排查：主要是慢查和CPU排查（五）Tair/Redis診斷報告對于全鏈路診斷，我們推出了診斷報告功能，可以對某個時間段發(fā)起“一鍵診斷”，這里主要是后端排查，目前都（六）Tair/Redis慢日志設(shè)置合理的Proxy和DB慢日志采集參數(shù)·slowlog-log-slower-than：DB分片上慢日志閾值，不可設(shè)置過低！；·slowlog-max-len：DB分片slowlog鏈表最大保持長度；·rt_threshold_ms：Proxy上慢日志閾值，不可設(shè)置過低！。以上建議使用默認(rèn)的參數(shù)，不要設(shè)置過小，因為如果這些閾值設(shè)置的過小，那么DB在采集慢日志的時候會頻繁記錄，可能慢日志查詢功能分為歷史慢日志和實時慢日志，入口也不相同，區(qū)別在于歷史慢日志可獲取近72小時內(nèi)的慢日志。實時慢日志能抓出當(dāng)前所有分片slowlog，但是有一個局限性，如果節(jié)點發(fā)生了HA或者手動清理慢日志，這部分慢日志就沒有·使用入口：“實例管理”-->“日志管理”-->“慢日志”；·使用須知：Tair版，或Redis版本>=redis4.0，具體查看幫助文檔；·可獲取近72小時內(nèi)的慢日志。·使用入口：“實例管理”-->“CloudDBA”-->“慢請求”；·實時獲取，能抓出當(dāng)前所有分片slowlog。29Redis訓(xùn)練營電子書30（七）資源的規(guī)劃-自建VS云Redis采購目標(biāo)：一個24GRedis主從版。上云方案包括ECS自建Redis與云Redis服務(wù)（Redis/Tair）。ECS自建Redis：·便宜；·擁有最高權(quán)限，完全自主可控，操控性強?！げ荒茏龅娇焖購椥缘馁Y源創(chuàng)建，業(yè)務(wù)突發(fā)高峰無法快速滿足系統(tǒng)性能要求；·需要專職DBA甚至是基礎(chǔ)架構(gòu)開發(fā)人員長期維護與技術(shù)演進；·管控節(jié)點/平臺需要使用第三方工具或額外研發(fā)，而且要額外購買資·Redis原生社區(qū)版內(nèi)核無優(yōu)化；·無專家服務(wù)兜底?！嵗?guī)格和數(shù)量：ecs.r6e.xlarge（4vCPU32GiB，內(nèi)存平衡增強型r6eecs.g6a.large（2vCPU8GiB，通用型g6a·實例數(shù)量:2+3（管控系統(tǒng)：2*APP+數(shù)據(jù)庫主從/Sentinel*3）；·部署資源分布：主從各24G，同時按照最普遍情況（見下文計算原理）主從各預(yù)留8GB作為COW的資源，另外包含三云Redis服務(wù)（Redis/Tair）·開箱即用，隨時彈性升降配和產(chǎn)品類型轉(zhuǎn)換；·內(nèi)核優(yōu)化，如簡化集群使用并支持跨SLOT多key操作的Proxy，安全加固，賬號權(quán)限控制；·眾多企業(yè)級管控增值功能特性，如：高可用無腦裂、賬號鑒權(quán)體系、操作審計、RDB+AOF備份、5秒監(jiān)控粒度、全量·性能強需求可選Tair性能增強型：具備多線程（性能是社區(qū)版的3倍）和豐富實用的數(shù)據(jù)結(jié)構(gòu)，同時擁有秒級數(shù)據(jù)恢復(fù)、31Redis訓(xùn)練營電子書32·成本與大規(guī)格強需求可選Tair持久內(nèi)存型與容量存儲型，多種形態(tài)存儲形態(tài)針對不同性能容量要求可以進一步降低成本，并提升數(shù)據(jù)持久化能力（Tair持久內(nèi)存型較內(nèi)存版降成本25%、Tair容量存儲型較內(nèi)存版降成本85%·7*24小時專家服務(wù)支持；即使出現(xiàn)重大問題，有阿里云專家在線支持，可以快速止血?！ず诤凶?，不開放最高權(quán)限?！ぐ姹绢愋停荷鐓^(qū)版；·版本號：Redis5.0；·架構(gòu)類型：標(biāo)準(zhǔn)版；·節(jié)點類型：雙副本；·實例規(guī)格：24G標(biāo)準(zhǔn)版。1950（成本稍低于自建，如果負(fù)載壓力滿足條件，進一步降低成本可以使用Tair持久內(nèi)存型，可以進一步降低30%的成本，而使用Tair容量存儲型會是ECS自建的1/5成本）。Redis的運維實戰(zhàn)Redis社區(qū)（一）Redis社區(qū)發(fā)展歷程200920132015201620172018202020202021Firstrelease2.8Redis誕生基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)主備復(fù)制持久化6.0Firstrelease2.8Redis誕生基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)主備復(fù)制持久化6.0IOthreadsClientsidecacheACLTLS3.2Lua復(fù)制優(yōu)化等4.05.0Streams6.2更豐富的命令性能優(yōu)化簡化運維3.0集群版發(fā)布Coreteam成立PSYNC2LazyCoreteam成立事務(wù)、lua、blocking事件通知Redis于2009年誕生，從第一個版本至今已經(jīng)經(jīng)歷了12年，目前也是全球最受歡迎的KV數(shù)據(jù)庫，在各個領(lǐng)域都有大規(guī)模的應(yīng)用。社區(qū)基本上每1～2年就會有一個版本推出，大版本為X.0格式，如3.0、4.0、5.0、6.0，小版本如3.2。每一個大從2.8版本開始，Redis就有很多功能完備的特性，已經(jīng)實現(xiàn)基本的數(shù)據(jù)集以及一系列使用命令，如簡單的字符串String，List的數(shù)據(jù)結(jié)構(gòu)，還有字典型的Hash，集合型的Set以及有序集合SortedSet，十分貼合軟件開發(fā)的實際需求。同時，支持主備復(fù)制和持久化，對服務(wù)的可用性和數(shù)據(jù)的可靠性都有一定的保證，而且支持像事務(wù)Multi、Exec這種批量操作。還有內(nèi)置的Lua虛擬機，可以在Redis里面執(zhí)行Lua腳本，以及像阻塞操作，比如Blocking的Brpop，還有事件通知等高級特性，此時的Redis已初步具備在生產(chǎn)環(huán)境中使用的能力。2015年社區(qū)推出3.0版本，發(fā)布集群Cluster這一重量級的特性。在2.8版本之前都只是支持主從版本，即最多一個節(jié)點提供服務(wù)。集群版本之后就可以有很多節(jié)點共同組成一個集群來提供服務(wù)，這樣可以有效地擴展數(shù)據(jù)的存儲能力和服務(wù)的性2016年推出3.2版本，主要是對Lua復(fù)制等方面進行優(yōu)化。2017年推出4.0版本，這個版本有很多重量級的特性。如LazyFree，可以對BigKey進行秒刪，避免業(yè)務(wù)清理BigKey時造成Latency時延的突增，讓運行更平滑更穩(wěn)定，業(yè)務(wù)也就更穩(wěn)定。PSYNC2是對原有的PSYNC協(xié)議的增強，在各個主從復(fù)制的場景下面做了相當(dāng)多的優(yōu)化，大大減少了在實際場景中進行全量復(fù)制的情況，有效節(jié)省了CPU、磁盤還有網(wǎng)絡(luò)帶寬等資源。Modules可以讓用戶自定義數(shù)據(jù)結(jié)構(gòu)和命令，相比于之前的Lua腳本，Modules更為靈活，可以讓Redis在各種定制的業(yè)33Redis訓(xùn)練營電子書34Redis于2009年誕生，從第一個版本至今已經(jīng)經(jīng)歷了12年，目前也是全球最受歡迎的KV數(shù)據(jù)庫，在各個領(lǐng)域都有大規(guī)模的應(yīng)用。社區(qū)基本上每1～2年就會有一個版本推出，大版本為X.0格式，如3.0、4.0、5.0、6.0，小版本如3.2。每一個大從2.8版本開始，Redis就有很多功能完備的特性，已經(jīng)實現(xiàn)基本的數(shù)據(jù)集以及一系列使用命令，如簡單的字符串String，List的數(shù)據(jù)結(jié)構(gòu)，還有字典型的Hash，集合型的Set以及有序集合SortedSet，十分貼合軟件開發(fā)的實際需求。同時，支持主備復(fù)制和持久化，對服務(wù)的可用性和數(shù)據(jù)的可靠性都有一定的保證，而且支持像事務(wù)Multi、Exec這種批量操作。還有內(nèi)置的Lua虛擬機，可以在Redis里面執(zhí)行Lua腳本，以及像阻塞操作，比如Blocking的Brpop，還有事件通知等高級特性，此時的Redis已初步具備在生產(chǎn)環(huán)境中使用的能力。2015年社區(qū)推出3.0版本，發(fā)布集群Cluster這一重量級的特性。在2.8版本之前都只是支持主從版本，即最多一個節(jié)點提供服務(wù)。集群版本之后就可以有很多節(jié)點共同組成一個集群來提供服務(wù)，這樣可以有效地擴展數(shù)據(jù)的存儲能力和服務(wù)的性2016年推出3.2版本，主要是對Lua復(fù)制等方面進行優(yōu)化。（二）Redis社區(qū)現(xiàn)狀目前社區(qū)CoreTeam一共有5名成員，3名來自于RedisLabs，1名來自亞馬遜云服務(wù)（AWS），1名來自阿里云，這5名成員共同組成了CoreTeam，維護社區(qū)的建設(shè)。目前，CoreTeam每兩周會舉行一次線上會來的，有沒有一些用戶的需求可以得到實現(xiàn)，大家提出來的這些Issue要如何解決，同時也會討論制定未來的發(fā)展方向，如比如要對主從復(fù)制、持久化與資源管理等做優(yōu)化。由于現(xiàn)在管理Redis內(nèi)存的話，數(shù)據(jù)區(qū)跟管理區(qū)是沒有區(qū)分的，因此7.0代碼行數(shù)1400001200001000008000060000400002000002.02.22.42.62.83.03.24.05.06.06.2Redis發(fā)展到現(xiàn)在，從最初的2萬行代碼，到現(xiàn)在6.2版本已經(jīng)有12萬行代碼。從代碼量上可以看出，Redis的功能越來越阿里云Redis（一）阿里云Redis產(chǎn)品系列Redis系列產(chǎn)品主要分為三大系列，分別是標(biāo)準(zhǔn)版、集群版與讀寫分離版，適用于不同的業(yè)務(wù)場景。標(biāo)準(zhǔn)版采用主從模式搭建，主節(jié)點提供日常的訪問需求，備節(jié)點是一個熱備，提供HA高可用。Master一旦發(fā)生宕機或者其它異常，會在30秒內(nèi)自動切換到備節(jié)點，保證業(yè)務(wù)平穩(wěn)運行集群版是多個Redis節(jié)點的組合，在容量和性能上都有大幅提升，滿足用戶對容量與高性能的需求，同時支持直連和代理了Proxy組件，通過Proxy組件訪問業(yè)務(wù)的話，就可以只通過一個統(tǒng)一的地址訪問Redis集群?？蛻舳说恼埱髸ㄟ^代理服讀寫分離板是由主備節(jié)點和只讀節(jié)點以及Proxy代理一起組成的系統(tǒng)。代理節(jié)點會自動把讀寫請求路由分發(fā)到Master節(jié)點（二）阿里云Redis運維體系細(xì)粒度監(jiān)控參數(shù)調(diào)節(jié)連接管理數(shù)據(jù)分析控制臺細(xì)粒度監(jiān)控參數(shù)調(diào)節(jié)連接管理數(shù)據(jù)分析控制臺35Redis訓(xùn)練營電子書36阿里云建立了一套Redis的運維體系，涵蓋日常運維管理各方面的需求，例如實例運行狀況實時和歷史的監(jiān)控，配置告數(shù)據(jù)安全方面開發(fā)了賬號體系，在網(wǎng)絡(luò)安全方面開發(fā)（三）性能監(jiān)控1.標(biāo)準(zhǔn)版Redis提供了非常豐富的監(jiān)控項，從實例的基礎(chǔ)運行狀態(tài)，如CPU、內(nèi)存、QPS和網(wǎng)絡(luò)帶寬，以及各種類型Key的數(shù)量，如過期key是否被刪除，Key的總量等。還有像實例運行的最大延遲，平均延遲，支持自定義監(jiān)控項，對各種數(shù)據(jù)結(jié)構(gòu)進2.集群版集群版支持對集群架構(gòu)下面各種指標(biāo)的查看，如Proxy節(jié)點的運行指標(biāo)，獨立數(shù)據(jù)節(jié)點運行指標(biāo)等，同時也可以查看節(jié)點3.監(jiān)控頻率用戶對于監(jiān)控頻率有需求的話，可以設(shè)置監(jiān)控的頻率，默認(rèn)為60秒/次。如果說需要細(xì)粒度監(jiān)控，可以在控制臺上進行修（四）連接管理在連接管理方面，我們同時支持內(nèi)網(wǎng)的VPC網(wǎng)絡(luò)訪問和公網(wǎng)訪問，公網(wǎng)訪問一般是做練習(xí)或者調(diào)試。在集群版的話，我們提供直連訪問和Proxy普通訪問的方式，都可以在控制臺連接管理進行開通。（五）賬號管理1.創(chuàng)建賬號登錄控制臺->點擊實例ID->賬號管理->創(chuàng)建賬號37Redis訓(xùn)練營電子書38關(guān)于賬號管理，在實際的業(yè)務(wù)場景中，有時一個實例可能會有多個業(yè)務(wù)線使為了避免相互干擾，需要做好權(quán)限控制。目前云Redis支持設(shè)置賬號管理體系，支持讀寫賬號和只讀賬號，幫助用戶更加2.權(quán)限修改另外，用戶可以對已有的賬號進行修改。比如說可以把一個只讀的賬號改為讀寫賬號。如果賬號不再使用，也可以進行刪（六）審計日志1.開通服務(wù)審計日志是對實際的運行操作記錄提供的一站式管理服務(wù)，由阿里巴巴集團經(jīng)歷了大量大數(shù)據(jù)場景之后錘煉而成，業(yè)務(wù)無需額外的開發(fā)，就可以在云端完成運行日志的采集、消費投遞以及查詢分析，3）點擊日志管理->審計日志4）選擇審計日志設(shè)置開通審計日志之后