轉(zhuǎn)自極客時(shí)間Redis 亞風(fēng) 原文視頻：https://u.geekbang.org/lesson/535?article=681062

Redis最佳實(shí)踐

普通KEY

Redis 的key雖然可以自定義，但是最好遵循下面幾個(gè)實(shí)踐的約定：
格式：[業(yè)務(wù)名稱]:[數(shù)據(jù)名]:[id] 長(zhǎng)度不超過44字節(jié) 不包含特殊字符
例如： login:user:10
這樣做的好處是
? 可讀性強(qiáng)
? 避免key沖突
? ?便管理
? 節(jié)省內(nèi)存：key是string類型，底層編碼包含int、embstr和raw三種。embstr在?于44字節(jié)使?，采?連續(xù)內(nèi)存空間，內(nèi)存占?更?。

set key "123"
object encoding key

BigKey

什么是bigKey?

• BigKey通常以Key的??和Key中成員的數(shù)量來(lái)綜合判定，例如：
• Key本身的數(shù)據(jù)量過?：?個(gè)String類型的Key，它的值為5 MB（key + val 加在一起 也就是一個(gè)Entry）。
• Key中的成員數(shù)過多：?個(gè)ZSET類型的Key，它的成員數(shù)量為10,000個(gè)。
  Key中成員的數(shù)據(jù)量過?：?個(gè)Hash類型的Key，它的成員數(shù)量雖然只有1,000個(gè)但這些成員的Value（值）總??為100 MB。
  推薦值：
  單個(gè)key的value?于10KB。
  對(duì)于集合類型的key，建議元素?cái)?shù)量?于1000。
  BigKey的問題
  ? ?絡(luò)阻塞
  對(duì)Bigkey執(zhí)?讀請(qǐng)求時(shí)，少量的QPS就可能導(dǎo)致帶寬使?率被占滿，導(dǎo)致Redis實(shí)例，乃?所在物理機(jī)變慢
  ? 數(shù)據(jù)傾斜
  BigKey所在的Redis實(shí)例內(nèi)存使?率遠(yuǎn)超其他實(shí)例，?法使數(shù)據(jù)分?的內(nèi)存資源達(dá)到均衡
  ? Redis阻塞
  對(duì)元素較多的hash、 list、 zset等做運(yùn)算會(huì)耗時(shí)較久，使主線程被阻塞
  ? CPU壓?
  對(duì)BigKey的數(shù)據(jù)序列化和反序列化會(huì)導(dǎo)致CPU的使?率飆升，影響Redis實(shí)例和本機(jī)其它應(yīng)?

BigKey的發(fā)現(xiàn)
? redis-cli --bigkeys
利? redis-cli提供的–bigkeys參數(shù)，可以遍歷分析所有key，并返回Key的整體統(tǒng)計(jì)信息與每個(gè)數(shù)據(jù)的Top1的big key

redis-cli --bigkeys #掃描bigkeys

這里只得出了最大的key是54bytes,沒有統(tǒng)計(jì)有那些key占用了多少空間，實(shí)際用用價(jià)值不大。

memory usage key #使用內(nèi)存大小 (integer) 112
strlen key #也是使用內(nèi)存大小
llen list #求內(nèi)存大小
#最好是使用后面兩個(gè)命令來(lái)求  memory usage性能不好

? scan掃描
??編程，利?scan掃描Redis中的所有key，利?strlen、hlen等命令判斷key的?度（此處不建議使?MEMORY USAGE)

scan 0 #第一頁(yè)是0
#第二頁(yè)則是 返回什么值 往下翻頁(yè)就是轉(zhuǎn)這個(gè)值
scan 7

// 自己編程
final static int STR_MAX_LEN = 10 * 1024;
final static int HASH_MAX_LEN = 1000;@Testvoid testScan() {int maxLen = 0;long len = 0;String cursor = "0";do {// 掃描并獲取?部分keyScanResult<String> result = jedis.scan(cursor);// 記錄cursorcursor = result.getCursor();List<String> list = result.getResult();if (list == null || list.isEmpty()) {break;}// 遍歷for (String key : list) {// 判斷key的類型String type = jedis.type(key);switch (type) {case "string":len = jedis.strlen(key);maxLen = STR_MAX_LEN;break;case "hash":len = jedis.hlen(key);maxLen = HASH_MAX_LEN;break;case "list":len = jedis.llen(key);maxLen = HASH_MAX_LEN;break;case "set":len = jedis.scard(key);maxLen = HASH_MAX_LEN;break;case "zset":len = jedis.zcard(key);maxLen = HASH_MAX_LEN;break;default:break;}if (len >= maxLen) {System.out.printf("Found big key : %s, ty
pe: %s, length or size: %d %n", key, type, len);}}} while (!cursor.equals("0"));}

? 第三??具
利?第三??具，如 Redis-Rdb-Tools 分析RDB快照?件，全?分析內(nèi)存使?情況（推薦使用，但是實(shí)時(shí)性比較差）
? ?絡(luò)監(jiān)控
?定義?具，監(jiān)控進(jìn)出Redis的?絡(luò)數(shù)據(jù)，超出預(yù)警值時(shí)主動(dòng)告警。直接監(jiān)控網(wǎng)絡(luò)數(shù)據(jù)包。

如何刪除BigKey
BigKey內(nèi)存占?較多，即便時(shí)刪除這樣的key也需要耗費(fèi)很?時(shí)間，導(dǎo)致
Redis主線程阻塞，引發(fā)?系列問題。
? redis 3.0 及以下版本
如果是集合類型，則遍歷BigKey的元素，先逐個(gè)刪除?元素，最后刪除Bigkey
? Redis 4.0以后
Redis在4.0后提供了異步刪除的命令：unlink

怎么存儲(chǔ)key
例1：?如存儲(chǔ)?個(gè)User對(duì)象，我們有三種存儲(chǔ)?式：
?式?：json字符串

user:1 {"name":"jack","age":21}

優(yōu)點(diǎn)：
簡(jiǎn)單粗暴
缺點(diǎn)：
數(shù)據(jù)耦合，不夠靈活
方式二
字段打散

user:1:name jack
user:1:age 21

優(yōu)點(diǎn)：可以靈活訪問對(duì)象任意字段
缺點(diǎn)：占?空間?、沒辦法做統(tǒng)?控制
方式三

hset uid name zhonglimo #單字段賦值
hmset uid name zhonglimo age 24 #多字段賦值

優(yōu)點(diǎn)：底層使?ziplist，空間占??，可以靈活訪問對(duì)象的任意字段
缺點(diǎn)：代碼相對(duì)復(fù)雜
實(shí)戰(zhàn)案例

假如有hash類型的key，其中有100萬(wàn)對(duì)field和value，field是?增id，這個(gè)key存在什么問題？如何優(yōu)化？

存在的問題：
? hash的entry數(shù)量超過500時(shí)，會(huì)使?dict?不是ZipList，內(nèi)存占?較多
? 可以通過hash-max-ziplist-entries配置entry上限。但是如果entry過多就會(huì)
導(dǎo)致BigKey問題
解決方案一直接將hash進(jìn)行拆分成String：

存在的問題：
? string結(jié)構(gòu)底層沒有太多內(nèi)存優(yōu)化，內(nèi)存占?較多
? 想要批量獲取這些數(shù)據(jù)?較麻煩

方式二：拆分為?的hash，將 id / 100 作為key，將id % 100 作為field，這樣每100個(gè)元素為?個(gè)Hash

HotKey

比如我有一個(gè)redis集群，由于2有一個(gè)熱鍵，所有的請(qǐng)都打到了這個(gè)機(jī)器上有可能這個(gè)機(jī)器扛不住壓力會(huì)掛掉，服務(wù)因而無(wú)法使用。

如果是讀：
比如用哈希取模的方法進(jìn)行路由到不同的機(jī)器，但是鍵也要做同樣的拆分因?yàn)橐粋€(gè)集群不能相同的鍵。

如果是寫，比如秒殺扣庫(kù)存，每臺(tái)機(jī)器存放100個(gè)庫(kù)存：

但是如果消耗到最后可能有碎片，比如剩了5個(gè)這個(gè)時(shí)候可以通過限流排隊(duì)取消耗這些碎片。還有一種解決方案是消耗到剩一些碎片的時(shí)候，直接關(guān)閉流量，保證不超消費(fèi)就行。

Pipeline批處理

MSET（不能被打斷）雖然可以批處理，但是卻只能操作部分?jǐn)?shù)據(jù)類型，因此如果有對(duì)復(fù)雜數(shù)據(jù)類型的批處理需要，建議使?Pipeline功能：

void testPipeline() {Pipline pipeline = jedis.pipelined();for (int i = 1; i <= 10000; i ++) {if (i % 1000 == 0） {pipline.sync();}}
}

注意事項(xiàng)：
? 批處理時(shí)不建議?次攜帶太多命令
? Pipeline的多個(gè)命令之間不具備原?性

MSET/Pipeline這樣的批處理需要在?次請(qǐng)求中攜帶多條命令，?此時(shí)如果Redis是?個(gè)集群，那批處理命令的多個(gè)key必須落在?個(gè)插槽中，否則就會(huì)導(dǎo)致執(zhí)?失敗。
解決方案：

并行Slot在spring中的應(yīng)用Spring->lettuce or Jedis->MultiKeyCommands

@Override
public RedisFuture<String> mset(Map<K,V> map) {Map<Integer, List<K>> partitioned = SlotHash.partition(codec, map.keySet());if (partitioned.size() < 2) {return super.mset(map);}
}

hash_tag

mset {a}name  zhangsan {a}age 12 {a}set male #這個(gè)hash Tag可以將key路由到同一個(gè)槽中

但是hash_tag 存在數(shù)據(jù)傾斜的問題，實(shí)戰(zhàn)中推薦使用并行slot.

RDB 數(shù)據(jù)文件備份

RDB全稱Redis Database Backup file (Redis數(shù)據(jù)備份?件），也被叫做Redis數(shù)據(jù)快照。簡(jiǎn)單來(lái)說(shuō)就是把內(nèi)存中的所有數(shù)據(jù)都記錄到磁盤中。當(dāng)Redis實(shí)例故障重啟后，從磁盤讀取快照?件，恢復(fù)數(shù)據(jù)。快照?件稱為RDB?件，默認(rèn)是保存在當(dāng)前運(yùn)??錄。

#有兩種命令
save #由redis主進(jìn)程來(lái)執(zhí)行RDB,會(huì)阻塞所有命令
#fork 出?個(gè)?進(jìn)程，?進(jìn)程執(zhí)?，不會(huì)阻塞 Redis 主線程，默認(rèn)選項(xiàng)
bgsave #開啟子進(jìn)程執(zhí)行RDB，避免主進(jìn)程受到影響

Redis 可以通過創(chuàng)建快照來(lái)獲得存儲(chǔ)在內(nèi)存??的數(shù)據(jù)在 某個(gè)時(shí)間點(diǎn) 上的副本。Redis 創(chuàng)建快照之后，可以對(duì)快照進(jìn)?備份，可以將快照復(fù)制到其他服務(wù)器從?創(chuàng)建具有相同數(shù)據(jù)的服務(wù)器副本（Redis 主從結(jié)構(gòu)，主要?來(lái)提?Redis 性能），還可以將快照留在原地以便重啟服務(wù)器的時(shí)候使??？煺粘志没?Redis 默認(rèn)采?的持久化?式，在 redis.conf 配置?件中默認(rèn)有此下配置：

#這些配置是一個(gè)或的關(guān)系，可以多個(gè)都生效，底層執(zhí)行的都是bgsave 會(huì)自動(dòng)轉(zhuǎn)換為bgsave
save 900 1 #900秒以后如果有一個(gè)key變化觸發(fā)bgsave
save 300 10 #300秒以后如果有10個(gè)key變化可以出發(fā)bgsave
save 60 10000 #一分鐘如果有10000個(gè)key發(fā)生變化觸發(fā)bgsave
rdbcompression yes #是否開啟壓縮，建議不開啟，壓縮會(huì)消耗cpu
dbfilename dump.rdb #rdb文件名稱
dir ./ #文件保存目錄

bgsave開始時(shí)會(huì)fork主進(jìn)程得到?進(jìn)程，?進(jìn)程共享主進(jìn)程的內(nèi)存數(shù)據(jù)。完成fork后讀取內(nèi)存數(shù)據(jù)并寫RDB ?件。fork采?的是copy-on-write技術(shù)：當(dāng)主進(jìn)程執(zhí)?讀操作時(shí)，訪問共享內(nèi)存；當(dāng)主進(jìn)程執(zhí)?寫操作時(shí)，則會(huì)拷??份數(shù)據(jù)，執(zhí)?寫操作。

AOF 追加文件

AOF全稱為Append Only File（追加?件）。Redis處理的每?個(gè)寫命令都會(huì)記錄在AOF?件，可以看做是命令?志?件。
與快照持久化相?，AOF 持久化的實(shí)時(shí)性更好。默認(rèn)情況下 Redis 沒有開啟 AOF?式的持久（Redis6.0 之后已經(jīng)默認(rèn)是開啟了），可以通過 appendonly 參數(shù)開啟：appendonly yes

開啟 AOF 持久化后每執(zhí)??條會(huì)更改 Redis 中的數(shù)據(jù)的命令，Redis 就會(huì)將該命令寫?到 AOF 緩沖區(qū)（用戶空間） server.aof_buf 中，然后再寫?到 AOF ?件中（此時(shí)在內(nèi)核緩存區(qū)），最后再根據(jù)持久化?式（ fsync策略）的配置來(lái)決定何時(shí)將系統(tǒng)內(nèi)核緩存區(qū)的數(shù)據(jù)同步到硬盤中的。

只有同步到磁盤中才算持久化保存了，否則依然存在數(shù)據(jù)丟失的?險(xiǎn)，?如說(shuō)：系統(tǒng)內(nèi)核緩存區(qū)的數(shù)據(jù)還未同步，磁盤機(jī)器就宕機(jī)了，那這部分?jǐn)?shù)據(jù)就算丟失了。

AOF ?件的保存位置和 RDB ?件的位置相同，都是通過 dir 參數(shù)設(shè)置的，默認(rèn)的?件名appendonly.aof。

AOF 持久化功能的實(shí)現(xiàn)分為 5 步：
1 命令追加（append） ：所有的寫命令會(huì)追加到 AOF 緩沖區(qū)中。
2 ?件寫?（write） ：將 AOF 緩沖區(qū)的數(shù)據(jù)寫?到 AOF ?件中。這?步
需要調(diào)?write函數(shù)（系統(tǒng)調(diào)?），write將數(shù)據(jù)寫?到了系統(tǒng)內(nèi)核緩沖區(qū)之
后直接返回了（延遲寫）。注意！此時(shí)并沒有同步到磁盤。
3 ?件同步（fsync） ：AOF 緩沖區(qū)根據(jù)對(duì)應(yīng)的持久化?式（ fsync 策略）
向硬盤做同步操作。這?步需要調(diào)? fsync 函數(shù)（系統(tǒng)調(diào)?）， fsync 針
對(duì)單個(gè)?件操作，對(duì)其進(jìn)?強(qiáng)制硬盤同步，fsync 將阻塞直到寫?磁盤完
成后返回，保證了數(shù)據(jù)持久化。
4 ?件重寫（rewrite） ：隨著 AOF ?件越來(lái)越?，需要定期對(duì) AOF ?件
進(jìn)?重寫，達(dá)到壓縮的?的。
5 重啟加載（load） ：Redis 重啟時(shí)，可以加載 AOF ?件進(jìn)?數(shù)據(jù)恢復(fù)。

Linux 系統(tǒng)直接提供了?些函數(shù)?于對(duì)?件和設(shè)備進(jìn)?訪問和控制，這些函數(shù)被稱為系統(tǒng)調(diào)?（syscall）。

write ：寫?系統(tǒng)內(nèi)核緩沖區(qū)之后直接返回（僅僅是寫到緩沖區(qū)），不會(huì)?即同步到硬盤。雖然提?了效率，但也帶來(lái)了數(shù)據(jù)丟失的?險(xiǎn)。同步硬盤操作通常依賴于系統(tǒng)調(diào)度機(jī)制，Linux 內(nèi)核通常為 30s 同步?次，具體值取決于寫出的數(shù)據(jù)量和 I/O 緩沖區(qū)的狀態(tài)。
fsync ： fsync?于強(qiáng)制刷新系統(tǒng)內(nèi)核緩沖區(qū)（同步到到磁盤），確保寫磁盤操作結(jié)束才會(huì)返回。

Redis fsync策略
在 Redis 的配置?件中存在三種不同的 AOF 持久化?式（ fsync策略），它們分別是：
? appendfsync always：主線程調(diào)? write 執(zhí)?寫操作后，后臺(tái)線程（ aof_fsync 線程）?即會(huì)調(diào)? fsync 函數(shù)同步 AOF ?件（刷盤），fsync 完成后線程返回，這樣會(huì)嚴(yán)重降低 Redis 的性能

? appendfsync everysec ：主線程調(diào)? write 執(zhí)?寫操作后?即返回，由后臺(tái)線程（ aof_fsync 線程）每秒鐘調(diào)? fsync 函數(shù)（系統(tǒng)調(diào)?）同步?次 AOF ?件

? appendfsync no ：主線程調(diào)? write 執(zhí)?寫操作后?即返回，讓操作系統(tǒng)決定何時(shí)進(jìn)?同步，Linux 下?般為 30 秒?次為了兼顧數(shù)據(jù)和寫?性能，可以考慮 appendfsync everysec 選項(xiàng) ，讓 Redis 每秒同步?次 AOF ?件，Redis 性能收到的影響較?。?且這樣即使出現(xiàn)系統(tǒng)崩潰，?戶最多只會(huì)丟失?秒之內(nèi)產(chǎn)?的數(shù)據(jù)。當(dāng)硬盤忙于執(zhí)?寫?操作的時(shí)候，Redis 還會(huì)優(yōu)雅的放慢??的速度以便適應(yīng)硬盤的最?寫?度。
**Multi Part AOF **
從 Redis 7 開始，Redis 使?了 Multi Part AOF 機(jī)制。顧名思義，Multi Part AOF 就是將原來(lái)的單個(gè) AOF ?件拆分成多個(gè) AOF ?件。在 Multi Part AOF 中，AOF ?件被分為三種類型，分別為：
BASE：表示基礎(chǔ) AOF ?件，它?般由?進(jìn)程通過重寫產(chǎn)?，該?件最多只有?個(gè)。
INCR：表示增量 AOF ?件，它?般會(huì)在 AOFRW 開始執(zhí)?時(shí)被創(chuàng)建，該?件可能存在多個(gè)。
HISTORY：表示歷史 AOF ?件，它由 BASE 和 INCR AOF 變化?來(lái)，每次 AOFRW 成功完成時(shí)，本次 AOFRW 之前對(duì)應(yīng)的 BASE 和 INCR AOF 都將變?yōu)?HISTORY，HISTORY 類型的 AOF 會(huì)被 Redis ?動(dòng)刪除。
當(dāng) AOF 變得太?時(shí)，Redis 能夠在后臺(tái)?動(dòng)重寫 AOF 產(chǎn)??個(gè)新的 AOF ?件，這個(gè)新的 AOF ?件和原有的 AOF ?件所保存的數(shù)據(jù)庫(kù)狀態(tài)?樣，但體積更?。

AOF重寫

AOF 重寫是?個(gè)有歧義的名字，該功能是通過讀取數(shù)據(jù)庫(kù)中的鍵值對(duì)來(lái)實(shí)現(xiàn)的（掃描鍵值對(duì)重新寫一個(gè)新文件，不會(huì)對(duì)之前的AOF進(jìn)行讀寫），程序?須對(duì)現(xiàn)有 AOF ?件進(jìn)?任何讀?或?qū)?操作。

由于 AOF 重寫會(huì)進(jìn)??量的寫?操作，為了避免對(duì) Redis 正常處理命令請(qǐng)求造成影響，Redis 將 AOF 重寫程序放到?進(jìn)程?執(zhí)?。
AOF ?件重寫期間，Redis 還會(huì)維護(hù)?個(gè) AOF 重寫緩沖區(qū)，該緩沖區(qū)會(huì)在?進(jìn)程創(chuàng)建新 AOF ?件期間，記錄服務(wù)器執(zhí)?的所有寫命令。當(dāng)?進(jìn)程完成創(chuàng)建新 AOF ?件的?作之后，服務(wù)器會(huì)將重寫緩沖區(qū)中的所有內(nèi)容追加到新 AOF ?件的末尾，使得新的 AOF ?件保存的數(shù)據(jù)庫(kù)狀態(tài)與現(xiàn)有的數(shù)據(jù)庫(kù)狀態(tài)?致。最后，服務(wù)器?新的 AOF ?件替換舊的 AOF ?件，以此來(lái)完成 AOF ?件重寫操作。

開啟 AOF 重寫功能，可以調(diào)? BGREWRITEAOF 命令?動(dòng)執(zhí)?，也可以設(shè)置下?兩個(gè)配置項(xiàng)，讓程序?動(dòng)決定觸發(fā)時(shí)機(jī)：

#增長(zhǎng)超過多少百分比觸發(fā)重寫
auto-aof-rewrite-percentage 100
#體積多大觸發(fā)重寫
auto-aof-rewrite-min-size 64mb

Redis 7.0 版本之前，如果在重寫期間有寫?命令，AOF 可能會(huì)使??量?jī)?nèi)存，重寫期間到達(dá)的所有寫?命令都會(huì)寫?磁盤兩次。AOF 重寫期間的增量數(shù)據(jù)如何處理?直是個(gè)問題，在過去寫期間的增量數(shù)據(jù)需
要在內(nèi)存中保留，寫結(jié)束后再把這部分增量數(shù)據(jù)寫?新的 AOF ?件中以保證數(shù)據(jù)完整性。可以看出來(lái) AOF 寫會(huì)額外消耗內(nèi)存和磁盤 IO，這也是 Redis AOF 寫的痛點(diǎn)，雖然之前也進(jìn)?過多次改進(jìn)但是資源消耗的本質(zhì)問題?直沒有解決。
阿? Redis 在最初也遇到了這個(gè)問題，在內(nèi)部經(jīng)過多次迭代開發(fā)，實(shí)現(xiàn)了 Multi-part AOF 機(jī)制來(lái)解決，同時(shí)也貢獻(xiàn)給了社區(qū)并隨此次 7.0 發(fā)布。具體?法是采? base（全量數(shù)據(jù)）+incr（增量數(shù)據(jù)）獨(dú)??件存儲(chǔ)的?式。由于 RDB 和 AOF 各有優(yōu)勢(shì)，Redis 4.0 開始?持 RDB 和 AOF 的混合持久化（默認(rèn)關(guān)閉，可以通過配置項(xiàng) aof-use-rdb-preamble 開啟）。如果把混合持久化打開，AOF 重寫的時(shí)候就直接把 RDB 的內(nèi)容寫到 AOF ?件開頭。這樣做的好處是可以結(jié)合 RDB 和 AOF 的優(yōu)點(diǎn), 快速加載同時(shí)避免丟失過多的數(shù)據(jù)。當(dāng)然缺點(diǎn)也是有的， AOF ??的 RDB 部分是壓縮格式不再是 AOF 格式，可讀性較差。

RDB與AOF的對(duì)比

RDB ? AOF 優(yōu)秀的地? ：
RDB ?件存儲(chǔ)的內(nèi)容是經(jīng)過壓縮的?進(jìn)制數(shù)據(jù)， 保存著某個(gè)時(shí)間點(diǎn)的數(shù)據(jù)集，?件很?，適合做數(shù)據(jù)的備份，災(zāi)難恢復(fù)。AOF ?件存儲(chǔ)的是每?次寫命令，類似于 MySQL 的 binlog ?志，通常會(huì)必 RDB ?件?很多。當(dāng) AOF 變得太?時(shí)，Redis 能夠在后臺(tái)?動(dòng)重寫 AOF。新的 AOF ?件和原有的 AOF ?件所保存的數(shù)據(jù)庫(kù)狀態(tài)?樣，但體積更?。不過， Redis 7 之前，如果在重寫期間有寫?命令，AOF 可能會(huì)使??量?jī)?nèi)存，重寫期間到達(dá)的所有寫?命令都會(huì)寫?磁盤兩次。使? RDB ?件恢復(fù)數(shù)據(jù)，直接解析還原數(shù)據(jù)即可，不需要?條?條地執(zhí)?命令，速度?常快。? AOF 則需要依次執(zhí)?每個(gè)寫命令，速度?常慢。也就是
說(shuō)，與 AOF 相?，恢復(fù)?數(shù)據(jù)集的時(shí)候，RDB 速度更快。

AOF ? RDB 優(yōu)秀的地? ：
RDB 的數(shù)據(jù)安全性不如 AOF，沒有辦法實(shí)時(shí)或者秒級(jí)持久化數(shù)據(jù)。?成 RDB ?件的過程是?較繁重的， 雖然 BGSAVE ?進(jìn)程寫? RDB ?件的?作不會(huì)阻塞主線程，但會(huì)對(duì)機(jī)器的 CPU 資源和內(nèi)存資源產(chǎn)?影響，嚴(yán)重的情況下甚?會(huì)直接把 Redis 服務(wù)?宕機(jī)。AOF ?持秒級(jí)數(shù)據(jù)丟失（取決 fsync 策略，如果是 everysec，最多丟失 1 秒的數(shù)據(jù)），僅僅是追加命令到 AOF ?件，操作輕量。
RDB ?件是以特定的?進(jìn)制格式保存的，并且在 Redis 版本演進(jìn)中有多個(gè)版本的 RDB，所以存在?版本的 Redis 服務(wù)不兼容新版本的 RDB 格式的問題。AOF 以?種易于理解和解析的格式包含所有操作的?志。你可以輕松地導(dǎo)出 AOF ?件進(jìn)?分析。?如，如果執(zhí)?FLUSHALL命令意外地刷新了所有內(nèi)容后，刪除最新命令并重啟即可恢復(fù)之前的狀態(tài)。持久化可以保證數(shù)據(jù)安全，但會(huì)帶來(lái)額外的開銷，請(qǐng)遵循下列建議：
? ?來(lái)做緩存的Redis實(shí)例盡量不要開啟持久化功能
? 建議關(guān)閉RDB持久化功能，使?AOF持久化
? 利?腳本定期在slave節(jié)點(diǎn)做RDB，實(shí)現(xiàn)數(shù)據(jù)備份
? 設(shè)置合理的rewrite閾值，避免頻繁的bgrewrite
? 配置no-appendfsync-on-rewrite =yes，禁?在rewrite期間做aof，避免因
AOF引起的阻塞

部署建議

? Redis實(shí)例的物理機(jī)要預(yù)留?夠內(nèi)存，應(yīng)對(duì)fork和rewrite
? 單個(gè)Redis實(shí)例內(nèi)存上限不要太?，例如8G?？梢约涌靎ork的速度（fork是到頁(yè)如果句柄太大，fork也會(huì)很慢）、減少主從同步、數(shù)據(jù)遷移壓?
? 不要與CPU密集型應(yīng)?部署在?起
? 不要與?硬盤負(fù)載應(yīng)??起部署。例如：數(shù)據(jù)庫(kù)、消息隊(duì)列

慢查詢

慢查詢閾值可以通過配置指定：slowlog-log-slower-than：慢查詢閾值，單位是微秒。默認(rèn)是10000（10ms），建議1000（1ms）
慢查詢會(huì)被放?慢查詢?志中，?志的?度有上限，可以通過配置指定：slowlog-max-len：慢查詢?志（本質(zhì)是?個(gè)隊(duì)列）的?度。默認(rèn)是128，建議1000
? slowlog len：查詢慢查詢?志?度
? slowlog get n：讀取n條慢查詢?志
? slowlog reset：清空慢查詢列表、

Redis 安全設(shè)置

Redis會(huì)綁定在0.0.0.0:6379，這樣將會(huì)將Redis服務(wù)暴露到公?上，?Redis如果沒有做身份認(rèn)證，會(huì)出現(xiàn)嚴(yán)重的安全漏洞.
漏洞出現(xiàn)的核?的原因有以下3點(diǎn)：
? Redis未設(shè)置密碼
? 利?了Redis的config set命令動(dòng)態(tài)修改Redis配置
? 使?了Root賬號(hào)權(quán)限啟動(dòng)Redis

為了避免漏洞，這?給出?些建議：
? Redis?定要設(shè)置密碼
? 禁?線上使?下?命令：keys、 flushall、 flushdb、 config set等命令。可以利?rename-command禁?。

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 #把修改配置的命令重新命名
rename-command KEYS ""      #必禁命令，線上用這種查詢方式絕對(duì)是不對(duì)的
rename-command FLUSHALL ""  #必禁命令，誰(shuí)會(huì)清除數(shù)據(jù)呢
rename-command FLUSHDB ""   #必禁命令，誰(shuí)會(huì)清除數(shù)據(jù)呢
rename-command CONFIG ""    #可以考慮重命名下

? bind：限制?卡，禁?外??卡訪問
? 開啟防?墻
? 不要使?Root賬戶啟動(dòng)Redis
? 盡量不是有默認(rèn)的端?

Redis內(nèi)存優(yōu)化

當(dāng)Redis內(nèi)存不?時(shí)，可能導(dǎo)致Key頻繁被刪除、響應(yīng)時(shí)間變?、QPS不穩(wěn)定等問題。當(dāng)內(nèi)存使?率達(dá)到90％以上時(shí)就需要我們警惕，并快速定位到內(nèi)存占?的原因。

redis info 詳解

內(nèi)存占用

內(nèi)存緩沖區(qū)常?的有三種：
復(fù)制緩沖區(qū)：主從復(fù)制的repl-backlog_buf，如果太?可能導(dǎo)致頻繁的全量復(fù)制，影響性能。通過repl-backlog-size來(lái)設(shè)置，默認(rèn)1mb。
AOF緩沖區(qū)：AOF刷盤之前的緩存區(qū)域，AOF執(zhí)?rewrite的緩沖區(qū)。?法設(shè)置容量上限。
客戶端緩沖區(qū)：分為輸?緩沖區(qū)和輸出緩沖區(qū)，輸?緩沖區(qū)最?1G且不能設(shè)置，輸出緩沖區(qū)可以設(shè)置。
通過下面這個(gè)命令進(jìn)行設(shè)置：
class 是一個(gè)什么，集群的時(shí)候配replica

CLIENT LIST #可以通過Client List 定位問題客戶端

Redis集群優(yōu)化

在Redis的默認(rèn)配置中，如果發(fā)現(xiàn)任意?個(gè)插槽不可?，則整個(gè)集群都會(huì)停?對(duì)外服務(wù)：

cluster-require-full-coverage  yes #通過這個(gè)配置來(lái)進(jìn)行設(shè)置 no 是有個(gè)一個(gè)插槽不可以也可以使用

集群節(jié)點(diǎn)之間會(huì)不斷的互相Ping來(lái)確定集群中其它節(jié)點(diǎn)的狀態(tài)。每次Ping攜帶的信息?少包括：
? 插槽信息
? 集群狀態(tài)信息
? 集群中節(jié)點(diǎn)越多，集群狀態(tài)信息數(shù)據(jù)量也越?，10個(gè)節(jié)點(diǎn)的相關(guān)信息可能達(dá)到1kb，此時(shí)每次集群互通需要的帶寬會(huì)?常?。
解決途徑：
? 避免?集群，集群節(jié)點(diǎn)數(shù)不要太多，最好少于1000，如果業(yè)務(wù)龐?，則建?多個(gè)集群
? 避免在單個(gè)物理機(jī)中運(yùn)?太多Redis實(shí)例
? 配置合適的cluster-node-timeout值