內(nèi)存分配控制
-
vm.overcommit_memory
vm.overcommit_memory的三個可選值及說明 - 獲取和設(shè)置
# cat /proc/sys/vm/overcommit_memory 獲取
echo "vm.overcommit_memory=1" >> /etc/sysctl.conf # 設(shè)置
sysctl vm.overcommit_memory=1
-
獲取和設(shè)置
Redis設(shè)置合理的maxmemory，保證機器有20%~30%的閑置內(nèi)存捂贿。
集中化管理AOF重寫和RDB的bgsave行您。
設(shè)置vm.overcommit_memory=1，防止極端情況下會造成fork失敗吉拳。 -
swappiness參數(shù)說明
swap對于操作系統(tǒng)來比較重要，當物理內(nèi)存不足時适揉，可以將一部分內(nèi)存頁進行swap操作留攒，已解燃眉之急。
swapniess重要值策略說明 - 設(shè)置方法
# echo {bestvalue} > /proc/sys/vm/swappiness 系統(tǒng)重啟后就會失效
echo vm.swappiness={bestvalue} >> /etc/sysctl.conf
需要注意/proc/sys/vm/swappiness是設(shè)置操作嫉嘀，/etc/sysctl.conf是追加操作炼邀。
-
如何監(jiān)控swap
（1）查看swap的總體情況
free–m
（2）實時查看swap的使用
vmstat 1 每隔一秒輸出
（3）查看指定進程的swap使用情況
redis-cli -h ip -p port info server | grep process_id # 獲取redis進程
process_id:986
cat /proc/986/smaps # 查詢swap信息
cat /proc/986/smaps | grep Swap #每個內(nèi)存塊鏡像信息中，這個進程使用到的swap量
- 其他優(yōu)化
## THP
echo never > /sys/kernel/mm/transparent_hugepage/enabled
## OOM killer 從-15到-17設(shè)置越小越好
echo {value} > /proc/${process_id}/oom_adj
flushall/flushdb誤操作
-
緩存與存儲
緩存：對后端數(shù)據(jù)源造成一定的負載壓力
存儲：很嚴重 -
借助AOF機制恢復
appendonly no：對AOF持久化沒有任何影響剪侮，因為根本就不存在AOF文件拭宁。
appendonly yes：只不過是在AOF文件中追加了一條記錄，雖然Redis中的數(shù)據(jù)被清除掉了瓣俯，但是AOF文件還保存著flush操作之前完整的數(shù)據(jù)杰标，這對恢復數(shù)據(jù)是很有幫助的。
1）如果發(fā)生了AOF重寫彩匕，Redis遍歷所有數(shù)據(jù)庫重新生成AOF文件腔剂，并會覆蓋之前的AOF文件。
1.調(diào)大AOF重寫參數(shù)auto-aof-rewrite-percentage和auto-aof-rewrite-minsize驼仪，讓Redis不能產(chǎn)生AOF自動重寫掸犬。
2.拒絕手動bgrewriteaof。
2）如果要用AOF文件進行數(shù)據(jù)恢復绪爸，那么必須要將AOF文件中的flushall相關(guān)操作去掉湾碎，為了更加安全，可以在去掉之后使用redis-check-aof這個工具去檢驗和修復一下AOF文件奠货，確保AOF文件格式正確介褥，保證數(shù)據(jù)恢復正常。
-
RDB有什么變化
1.必須自動策略是關(guān)閉的并且沒有手動執(zhí)行過save、bgsave或者發(fā)生了主從的全量復制
綜上所述呻顽，如果AOF已經(jīng)開啟了雹顺，那么用AOF來恢復是比較合理的方式，但是如果AOF關(guān)閉了廊遍，那么RDB雖然數(shù)據(jù)不是很實時嬉愧，但是也能恢復部分數(shù)據(jù)，完全取決于RDB是什么時候備份的喉前。
處理bigkey
- 字符串類型：體現(xiàn)在單個value值很大没酣，一般認為超過10KB就是bigkey，但這個值和具體的OPS相關(guān)卵迂。
- 非字符串類型：哈希裕便、列表、集合见咒、有序集合偿衰，體現(xiàn)在元素個數(shù)過多。
bigkey的危害 - 內(nèi)存空間不均勻（平衡）：例如在Redis Cluster中改览，bigkey會造成節(jié)點的內(nèi)存空間使用不均勻下翎。
- 超時阻塞：由于Redis單線程的特性，操作bigkey比較耗時宝当，也就意味著阻塞Redis可能性增大视事。
- 網(wǎng)絡(luò)擁塞：
bigkey造成網(wǎng)絡(luò)擁塞示意圖
如何發(fā)現(xiàn)
127.0.0.1:6379> debug object key
Value at:0x7fc06c1b1430 refcount:1 encoding:raw serializedlength:1256350 lru:11686193
lru_seconds_idle:20
可以發(fā)現(xiàn)serializedlength=11686193字節(jié)，約為1M庆揩，同時可以看到encoding是raw俐东，也就是字符串類型，那么可以通過strlen來看一下字符串的字節(jié)數(shù)為2247394字節(jié)订晌，約為2MB：
127.0.0.1:6379> strlen key
(integer) 2247394
- 被動收集：當拋出異常時打印出所操作的key
- 主動檢測：scan+debug object
如何刪除
Redis將在4.0版本支持lazy delete free的模式，那時刪除bigkey不會阻塞Redis锈拨。
尋找熱點key
客戶端
客戶端進行熱點key的統(tǒng)計
代理端
基于代理的熱點key統(tǒng)計
Redis服務(wù)端
使用monitor命令統(tǒng)計熱點key
機器
Redis客戶端使用TCP協(xié)議與服務(wù)端進行交互，通信協(xié)議采用的是RESP。
機器Redis TCP包分析
尋找熱點key的四種方案
本章重點回顧
1）Linux相關(guān)優(yōu)化：
·vm.overcommit_memory建議為1肉迫。
·Linux>3.5验辞，vm.swappiness建議為1，否則建議為0跌造。
·Transparent Huge Pages（THP）建議關(guān)閉掉，但需要注意Linux發(fā)行版本改變了THP的配置位置壳贪。
·可以為Redis進程設(shè)置oom_adj陵珍，減少Redis被OOM killer殺掉的概率，但不要過度依賴此特性违施。
·建議對Redis所有節(jié)點所在機器使用NTP服務(wù)互纯。
·設(shè)置合理的ulimit保證網(wǎng)絡(luò)連接正常磕蒲。
·設(shè)置合理的tcp-backlog參數(shù)留潦。
2）理解Redis的持久化有助于解決flush操作之后的數(shù)據(jù)快速恢復問題辣往。
3）Redis安全建議：
·根據(jù)具體網(wǎng)絡(luò)環(huán)境決定是否設(shè)置Redis密碼。
·rename-command可以偽裝命令坊萝，但是要注意成本。
·合理的防火墻是防止攻擊的利器十偶。
·bind可以將Redis的訪問綁定到指定網(wǎng)卡上。
·定期備份數(shù)據(jù)應(yīng)該作為習慣性操作扯键。
·可以適當錯開Redis默認端口啟動珊肃。
·使用非root用戶啟動Redis。
4）bigkey的危害不容忽視：數(shù)據(jù)傾斜伦乔、超時阻塞、網(wǎng)絡(luò)擁塞烈和，可能是Redis生產(chǎn)環(huán)境中的一顆定時炸彈，刪除bigkey時通常使用漸進式遍歷的方式恬试，防止出現(xiàn)Redis阻塞的情況疯暑。
5）通過客戶端训柴、代理妇拯、monitor洗鸵、機器抓包四種方式找到熱點key仗嗦，這幾種方式各具優(yōu)勢，具體使用哪種要根據(jù)當前場景來決定稀拐。
