Redis最佳實踐Redis使用的經驗總結Redis鍵值設計批處理優化服務端優化集群最佳實踐Redis鍵值設計01優雅的key結構拒絕BigKey恰當的數據類型Redis的Key雖然可以自定義，但最好遵循下面的幾個最佳實踐約定：遵循基本格式：[業務名稱]:[數據名]:[id]長度不超過44字節不包含特殊字符例如：我們的登錄業務，保存用戶信息，其key是這樣的：優點：可讀性強避免key沖突方便管理更節省內存：key是string類型，底層編碼包含int、embstr和raw三種。embstr在小于44字節使用，采用連續內存空間，內存占用更小優雅的key結構login:user:10業務名稱數據名稱數據id優雅的key結構拒絕BigKey恰當的數據類型BigKey通常以Key的大小和Key中成員的數量來綜合判定，例如：Key本身的數據量過大：一個String類型的Key，它的值為5MB。Key中的成員數過多：一個ZSET類型的Key，它的成員數量為10,000個。Key中成員的數據量過大：一個Hash類型的Key，它的成員數量雖然只有1,000個但這些成員的Value（值）總大小為100MB。推薦值：單個key的value小于10KB對于集合類型的key，建議元素數量小于1000什么是BigKeyBigKey的危害

網絡阻塞對BigKey執行讀請求時，少量的QPS就可能導致帶寬使用率被占滿，導致Redis實例，乃至所在物理機變慢

數據傾斜BigKey所在的Redis實例內存使用率遠超其他實例，無法使數據分片的內存資源達到均衡

Redis阻塞對元素較多的hash、list、zset等做運算會耗時較舊，使主線程被阻塞

CPU壓力對BigKey的數據序列化和反序列化會導致CPU的使用率飆升，影響Redis實例和本機其它應用如何發現BigKey

redis-cli--bigkeys利用redis-cli提供的--bigkeys參數，可以遍歷分析所有key，并返回Key的整體統計信息與每個數據的Top1的bigkey

scan掃描自己編程，利用scan掃描Redis中的所有key，利用strlen、hlen等命令判斷key的長度（此處不建議使用MEMORYUSAGE）

第三方工具利用第三方工具，如Redis-Rdb-Tools

分析RDB快照文件，全面分析內存使用情況

網絡監控自定義工具，監控進出Redis的網絡數據，超出預警值時主動告警如何刪除BigKeyBigKey內存占用較多，即便時刪除這樣的key也需要耗費很長時間，導致Redis主線程阻塞，引發一系列問題。

redis3.0及以下版本如果是集合類型，則遍歷BigKey的元素，先逐個刪除子元素，最后刪除BigKey

Redis4.0以后

Redis在4.0后提供了異步刪除的命令：unlink優雅的key結構拒絕BigKey恰當的數據類型例1：比如存儲一個User對象，我們有三種存儲方式：方式一：json字符串方式二：字段打散方式三：hash恰當的數據類型user:1{"name":"Jack","age":21}user:1:nameJackuser:1:age21user:1nameJackuser:1:agejack21優點：實現簡單粗暴缺點：數據耦合，不夠靈活優點：可以靈活訪問對象任意字段缺點：占用空間大、沒辦法做統一控制優點：底層使用ziplist，空間占用小，可以靈活訪問對象的任意字段缺點：代碼相對復雜例2：假如有hash類型的key，其中有100萬對field和value，field是自增id，這個key存在什么問題？如何優化？恰當的數據類型KEYsomeKeyvalueid:0value0..........id:999999value999999field存在的問題：hash的entry數量超過500時，會使用哈希表而不是ZipList，內存占用較多。可以通過hash-max-ziplist-entries配置entry上限。但是如果entry過多就會導致BigKey問題例2：假如有hash類型的key，其中有100萬對field和value，field是自增id，這個key存在什么問題？如何優化？恰當的數據類型valueid:0value0..........id:999999value999999key方案二：拆分為string類型：存在的問題：string結構底層沒有太多內存優化，內存占用較多。想要批量獲取這些數據比較麻煩key:1key:9999例2：假如有hash類型的key，其中有100萬對field和value，field是自增id，這個key存在什么問題？如何優化？恰當的數據類型KEYkey:0valueid:00value0..........id:99value99field方案三：拆分為小的hash，將id/100作為key，將id%100作為field，這樣每100個元素為一個Hashid:00value100..........id:99value199id:00value999900..........id:99value999999...Key的最佳實踐：固定格式：[業務名]:[數據名]:[id]足夠簡短：不超過44字節不包含特殊字符Value的最佳實踐：合理的拆分數據，拒絕BigKey選擇合適數據結構Hash結構的entry數量不要超過1000設置合理的超時時間批處理優化02Pipeline集群下的批處理一堆糧食要搬運到倉庫，有幾種辦法？大量數據導入的方式一次命令的響應時間=1次往返的網絡傳輸耗時+1次Redis執行命令耗時單個命令的執行流程客戶端Redis服務端1.發送命令2.執行命令3.返回結果N次命令的響應時間=N次往返的網絡傳輸耗時+N次Redis執行命令耗時N條命令依次執行客戶端Redis服務端。。。1.發送命令2.執行命令3.返回結果1.發送命令N2.執行命令N3.返回結果NN次命令的響應時間=1次往返的網絡傳輸耗時+N次Redis執行命令耗時N條命令批量執行客戶端Redis服務端1.批量發送N條命令2.執行N個命令3.返回N個結果Redis提供了很多Mxxx這樣的命令，可以實現批量插入數據，例如：msethmset利用mset批量插入10萬條數據：MSET@Test

voidtestMxx(){

String[]arr=newString[2000];

intj;

for(inti=1;i<=100000;i++){

j=(i%1000)<<1;

arr[j]="test:key_"+i;

arr[j+1]="value_"+i;

if(j==0){

jedis.mset(arr);

}

}

}注意不要在一次批處理中傳輸太多命令，否則單次命令占用帶寬過多，會導致網絡阻塞MSET雖然可以批處理，但是卻只能操作部分數據類型，因此如果有對復雜數據類型的批處理需要，建議使用Pipeline功能：Pipeline@Test

voidtestPipeline(){

//創建管道

Pipelinepipeline=jedis.pipelined();

for(inti=1;i<=100000;i++){

//放入命令到管道

pipeline.set("test:key_"+i,"value_"+i);

if(i%1000==0){

//每放入1000條命令，批量執行

pipeline.sync();

}

}

}批量處理的方案：原生的M操作Pipeline批處理注意事項：批處理時不建議一次攜帶太多命令Pipeline的多個命令之間不具備原子性Pipeline集群下的批處理如MSET或Pipeline這樣的批處理需要在一次請求中攜帶多條命令，而此時如果Redis是一個集群，那批處理命令的多個key必須落在一個插槽中，否則就會導致執行失敗。集群下的批處理串行命令串行slot并行slothash_tag實現思路for循環遍歷，依次執行每個命令在客戶端計算每個key的slot，將slot一致分為一組，每組都利用Pipeline批處理。串行執行各組命令在客戶端計算每個key的slot，將slot一致分為一組，每組都利用Pipeline批處理。并行執行各組命令將所有key設置相同的hash_tag，則所有key的slot一定相同耗時N次網絡耗時+N次命令耗時m次網絡耗時+N次命令耗時m=key的slot個數1次網絡耗時+N次命令耗時1次網絡耗時+N次命令耗時優點實現簡單耗時較短耗時非常短耗時非常短、實現簡單缺點耗時非常久實現稍復雜slot越多，耗時越久實現復雜容易出現數據傾斜服務端優化03持久化配置慢查詢命令及安全配置內存配置Redis的持久化雖然可以保證數據安全，但也會帶來很多額外的開銷，因此持久化請遵循下列建議：用來做緩存的Redis實例盡量不要開啟持久化功能建議關閉RDB持久化功能，使用AOF持久化利用腳本定期在slave節點做RDB，實現數據備份設置合理的rewrite閾值，避免頻繁的bgrewrite配置no-appendfsync-on-rewrite=yes，禁止在rewrite期間做aof，避免因AOF引起的阻塞部署有關建議：Redis實例的物理機要預留足夠內存，應對fork和rewrite單個Redis實例內存上限不要太大，例如4G或8G。可以加快fork的速度、減少主從同步、數據遷移壓力不要與CPU密集型應用部署在一起不要與高硬盤負載應用一起部署。例如：數據庫、消息隊列持久化配置主線程AOF緩沖區對比上次fsync時間阻塞通過同步線程同步磁盤1）2）fsync3）大于2秒小于2秒持久化配置慢查詢命令及安全配置內存配置慢查詢：在Redis執行時耗時超過某個閾值的命令，稱為慢查詢。慢查詢客戶端Redis服務端1.發送命令2.執行命令3.返回結果入隊慢查詢的閾值可以通過配置指定：slowlog-log-slower-than：慢查詢閾值，單位是微秒。默認是10000，建議1000慢查詢會被放入慢查詢日志中，日志的長度有上限，可以通過配置指定：slowlog-max-len：慢查詢日志（本質是一個隊列）的長度。默認是128，建議1000修改這兩個配置可以使用：configset命令：慢查詢查看慢查詢日志列表：slowloglen：查詢慢查詢日志長度slowlogget[n]：讀取n條慢查詢日志slowlogreset：清空慢查詢列表慢查詢持久化配置慢查詢命令及安全配置內存配置Redis會綁定在:6379，這樣將會將Redis服務暴露到公網上，而Redis如果沒有做身份認證，會出現嚴重的安全漏洞.漏洞重現方式：漏洞出現的核心的原因有以下幾點：Redis未設置密碼利用了Redis的configset命令動態修改Redis配置使用了Root賬號權限啟動Redis命令及安全配置為了避免這樣的漏洞，這里給出一些建議：Redis一定要設置密碼禁止線上使用下面命令：keys、flushall、flushdb、configset等命令。可以利用mand禁用。bind：限制網卡，禁止外網網卡訪問開啟防火墻不要使用Root賬戶啟動Redis盡量不是有默認的端口命令及安全配置持久化配置慢查詢命令及安全配置內存配置當Redis內存不足時，可能導致Key頻繁被刪除、響應時間變長、QPS不穩定等問題。當內存使用率達到90%以上時就需要我們警惕，并快速定位到內存占用的原因。內存配置內存占用說明數據內存

是Redis最主要的部分，存儲Redis的鍵值信息。主要問題是BigKey問題、內存碎片問題進程內存Redis主進程本身運?肯定需要占?內存，如代碼、常量池等等；這部分內存?約?兆，在?多數?產環境中與Redis數據占?的內存相?可以忽略。緩沖區內存

一般包括客戶端緩沖區、AOF緩沖區、復制緩沖區等。客戶端緩沖區又包括輸入緩沖區和輸出緩沖區兩種。這部分內存占用波動較大，不當使用BigKey，可能導致內存溢出。Redis提供了一些命令，可以查看到Redis目前的內存分配狀態：infomemorymemoryxxx數據內存的問題內存緩沖區常見的有三種：復制緩沖區：主從復制的repl_backlog_buf，如果太小可能導致頻繁的全量復制，影響性能。通過repl-backlog-size來設置，默認1mbAOF緩沖區：AOF刷盤之前的緩存區域，AOF執行rewrite的緩沖區。無法設置容量上限客戶端緩沖區：分為輸入緩沖區和輸出緩沖區，輸入緩沖區最大1G且不能設置。輸出緩沖區可以設置默認的配置如下：內存緩沖區配置client-output-buffer-limit<class><hardlimit><softlimit><softseconds>客戶端類型normal：普通客戶端replica：主從復