Redis進階之面試不再沒話講
1.Redis.conf
他裏面明確標註了，對大小寫不敏感
還可以像腳手架一樣，包含其它，引入conf
//下面我就以文本顯示，不截圖了
protected-mode yes #跨域保護
port 6379 //端口配置daemonize yes #默認是no不以後臺運行
pidfile /var/run/redis_6379.pid #如果以後臺運行我們需要指定一個pid文件，以後報錯就是要有一個這個文件
logfile "" //日誌文件的名字
database 16 //默認16個庫快照
持久化規則，規定時間進行持久化可以通過rdb和aof兩種方式
save 900 1 # 如果900s內有一個key進行操作，就會進行持久化，下面一樣解讀
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes # 持久化出錯，是否還要繼續工作
rdbcompression yes #是否壓縮rdb文件，會在一定程度耗費時間和資源
rdbchecksum yes # 保存rdb文件的時候進行錯誤檢查
dir ./ //rdb文件默認保存在當前目錄下config set requirepass “123” //設置密碼
設置後登錄就要密碼了
auth 123
maxclients 10000 //設置最大能連接上的客戶端
maxmemory <bytes> //最大內存容量
maxmemory-policy noeviction //內存到達上線後的內存策略
appendfsync ererysec | always | no //看如何選擇，每秒同步，時刻同步，不同步
剩下的下面會詳解
2.持久化
面試重點，不持久化，斷電就會永久失去數據了
1.RDB(默認)
-
先fork一個子進程，子進程把數據先寫入臨時rdb文件
-
臨時文件去持久化,持久化完了，替換原來的rdb文件，成爲最新一份的備份rdb文件
-
父子進程共享內存
這種有個缺點，最後一次的斷電，數據就沒有備份成功，所以適合對數據完整性要求不嚴格的的場景
rdb是dump.rdb名字，，aof是appendonly.aof
觸發機制
- save的規則滿足的情況下，會自動觸發rdb規則
- 執行flushAll命令，也會觸發我們的rdb規則
- 退出redis,也會產生rdb文件！
備份就自動生成一個dump.rdb文件
恢復文件的話,只需要將rdb文件放在我們redis默認是啓動目錄(可以改)就可以，redis啓動會自動檢查dump文件
config get dir 查看dump需要放在哪個目錄下
適合大規模的數據恢復,容易丟掉最後一次數據，還要fork進程，會共享父進程的內存
2.AOF
追加文件，將所有寫命令和刪除記錄下來，恢復的時候重新執行一遍，以日誌的形式來記錄，不會改寫文件
大數據的話，就要一次次執行，太慢了
默認是不開啓的 appendonly no 需要手動開啓
如果aof文件出錯了redis啓動不起來，我們可以用redis-check-aof --fix aof文件 來修復
優點:每一次的修改命令都記錄下來，文件完整性高，每秒同步一次，可能丟失一秒的數據，從不同步效率最高
缺點: 修復很慢，而且運行效率也慢，要記錄操作日誌
3.Redis發佈訂閱
微信公衆號，網絡聊天室，廣播
subscribe channel //訂閱
publish channel message //發送消息訂閱頻道的人就像鏈表上的節點，發送消息，會遍歷鏈表發送給每一個節點
Psubscribe 正則channel 模糊匹配，可以匹配相關頻道，
這個可以簡單做個發佈訂閱，但是對於細粒度的發送和監管，還需要給mq消息中間件來做
4.主從複製
主機可讀可寫，從機只能讀
主從複製是單向的，由主機複製給從機，默認每個redis都是主機，但是在分配的情況下，所有從機只能有一個主機
主從複製的作用:
- 數據冗餘:主從複製實現了數據的備份，相當於一種緩存
- 故障恢復:老大掛了，小弟選一個老大可以頂上
- 負載均衡:讀的請求可以分擔給從機，大大減少了主機的壓力
一臺服務器是不可能的，宕機全玩完，所以集羣必不可免，所以主從複製是一種策略，而且一臺服務器也存不完所有數據
info replication //查看機器複製信息複製三個conf,改成三個端口，rdb文件，pid文件，實現一個簡單的集羣
slaveof 主機ip 主機端口 //認誰爲主機使用命令是暫時的，應該在配置文件中爲永久保持
從機會自動保存主機的信息和數據，主機如果斷了，也沒其它策略，從機不會自動變主機，除非手動設置
主機斷了又重連的話，依然還是主機，從機依然能連上主機，讀取信息
主機斷了
- 我們可以用slaveof no one 使自己變爲主機，再讓其它連接我，這是手動做法，如果主機連接那就重新連接，重新成爲老大
- 哨兵模式，自動選老大，重新連接也只能當從機了，多哨兵可能還有個延時等待，但過了也只能當從機了
5.哨兵模式
自動選取老大
ps: 不回我消息，你死了，我找別人去了
如果主機斷開了回來重新連接也只能當從機
哨兵也可以掛，所以哨兵也要集羣，多個哨兵互相監督，成立委員會
多哨兵比較人性，還會有個投票，單哨兵是你不回，我單方面認定你掛了
配置哨兵的配置文件sentinel.conf主要規則
#sentinel monitor 被監控的名稱 host port 1
sentinel monitor myredis 127.0.0.1 6379 1
數字1代表從機投票給誰當主機，票數最多的當
詳細配置，大致雷同
# 端口
port 26379
# 是否後臺啓動
daemonize yes
# pid文件路徑
pidfile /var/run/redis-sentinel.pid
# 日誌文件路徑
logfile "/var/log/sentinel.log"
# 定義工作目錄
dir /tmp
# 定義Redis主的別名, IP, 端口，這裏的2指的是需要至少2個Sentinel認爲主Redis掛了才最終會採取下一步行爲
sentinel monitor mymaster 127.0.0.1 6379 2
# 如果mymaster 30秒內沒有響應，則認爲其主觀失效
sentinel down-after-milliseconds mymaster 30000
# 如果master重新選出來後，其它slave節點能同時並行從新master同步數據的臺數有多少個，顯然該值越大，所有slave節點完成同步切換的整體速度越快，但如果此時正好有人在訪問這些slave，可能造成讀取失敗，影響面會更廣。最保守的設置爲1，同一時間，只能有一臺幹這件事，這樣其它slave還能繼續服務，但是所有slave全部完成緩存更新同步的進程將變慢。
sentinel parallel-syncs mymaster 1
# 該參數指定一個時間段，在該時間段內沒有實現故障轉移成功，則會再一次發起故障轉移的操作，單位毫秒
sentinel failover-timeout mymaster 180000
# 不允許使用SENTINEL SET設置notification-script和client-reconfig-script。
sentinel deny-scripts-reconfig yes6.Redis緩存穿透和服務雪崩
在查詢數據的時候，去redis緩存層查不到，就會去數據庫查，但是數據庫也沒有這個信息，如果這時候大量用戶，比如秒殺，去數據庫查詢壓力嚴重就容易崩潰，這就叫緩存穿透，一般秒殺會做個熱點數據提前緩存
解決方案 布隆過濾器
比如，查詢完會將查詢的結果以一個map存儲在緩存，如果沒查詢到，就存個null，這樣也防止了去查詢數據庫
但是這樣會有兩個缺點
- 如果大量數據沒有查詢到，就會有很多空間都是null，浪費了大量內存空間
- 即使設置了過期時間，但是如果數據庫是沒有的值，全都被設置爲空，後面有值了,那麼緩存層數據和持久層容易造成數據不一致性
1.緩存擊穿
子彈全打在一個點，一個熱點數據，承擔高併發量，在過期時間導致服務不可用，瞬間就有大量數據同時去往數據庫，這時壓力就容易導致服務器崩潰
解決辦法:
- 設置熱點key永不過期，這樣就不會存在擊穿緩存層的情況
- 加互斥鎖，分佈式鎖(主流解決方案)保證每個key對於一個數據都是一個線程去訪問，優點像同步隊列，其它沒有權限的沒拿到鎖，就只能等待，這種方式將對高併發的壓力轉移到了如何獲取分佈鎖上，所以設置分佈式鎖的方案很重要
緩存雪崩
停電了怎麼辦，緩存集中過期，Redis宕機，緩存層失效
所有訪問全來數據庫，跟下大暴雨一樣，而且數據庫一蹦，其它服務接着癱瘓，這就是雪崩效應
雙十一:
- 停掉一些服務，cloud的服務限流降級，來保證主要服務高可用
- redis集羣，異地多活，高可用，即使宕機一個其它也能保證數據不丟失
沒有權限的沒拿到鎖，就只能等待，這種方式將對高併發的壓力轉移到了如何獲取分佈鎖上，所以設置分佈式鎖的方案很重要
[外鏈圖片轉存中…(img-2Lk3tJ4x-1590375759527)]
緩存雪崩
停電了怎麼辦，緩存集中過期，Redis宕機，緩存層失效
所有訪問全來數據庫，跟下大暴雨一樣，而且數據庫一蹦，其它服務接着癱瘓，這就是雪崩效應
雙十一:
- 停掉一些服務，cloud的服務限流降級，來保證主要服務高可用
- redis集羣，異地多活，高可用，即使宕機一個其它也能保證數據不丟失
- 數據預熱，在項目啓動前，提前對熱點數據進行緩存，而且設置過期時間按照梯度層次，慢慢過期