Redis的持久化操做

1.Redis持久化策略

1.1 什麼是持久化

說明:Redis運行環境在內存中,若是redis服務器關閉,則內存數據將會丟失.
需求: 如何保存內存數據呢?
解決方案: 能夠按期將內存數據持久化到磁盤中.
持久化策略規則:
當redis正常運行時,按期的將數據保存到磁盤中,當redis服務器重啓時,則根據配置文件中指定的持久化的方式,實現數據的恢復.(讀取數據,以後恢復數據.)

1.2 RDB模式

1.2.1RDB模式特色說明

1).RDB模式是Redis默認的策略.
2).RDB模式可以按期(時間間隔)持久化. 弊端:可能致使數據的丟失.
3).RDB模式記錄的是內存數據的快照.持久化效率較高. 快照只保留最新的記錄.

1.2.2 RDB模式命令

1.save命令: 將內存數據持久化到磁盤中 主動的操做 會形成線程阻塞
2.bgsave命令: 將內存數據採用後臺運行的方式,持久化到文件中. 不會形成阻塞.
3.默認的持久化的機制
save 900 1 若是在900秒內,執行了1次更新操做,則持久化一次
save 300 10 若是在300秒內,執行了10次更新操做,則持久化一次
save 60 10000 若是在60秒內,執行了10000次更新操做,則持久化一次

1.2.3 持久化文件配置

1).指定持久化文件

2).指定持久化文件目錄

1.3 AOF模式

1.3.1 AOF模式特色

1).AOF模式默認條件下是關閉的.須要手動開啓
2).AOF模式記錄的是用戶的操做過程,因此能夠實現實時持久化操做.
3).AOF模式因爲記錄的是實時的操做過程,因此持久化文件較大.須要按期維護.

1.3.2 啓動AOF模式

說明:若是一旦開啓AOF模式,則以AOF模式爲準.

1.4 關於持久化操做總結

1.當內存數據容許少許丟失時,採用RDB模式 (快)
2.當內存數據不容許丟失時,採用AOF模式(按期維護持久化文件)
3.通常在工做中採用 RDB+AOF模式共同做用,保證數據的有效性.

1.5 面試題

問題: 若是小李(漂亮妹子)在公司服務器中執行了flushAll命令,問怎麼辦?
答: 須要找到aof文件以後,刪除flushAll命令 以後重啓redis,執行save命令便可.

2.內存優化策略

2.1 爲何須要內存優化

說明: 因爲redis在內存中保存數據.若是一直存儲,則內存數據必然溢出.因此須要按期維護內存數據的大小.
維護策略: 刪除舊的不用的數據,保留新的經常使用的數據

2.2 LRU算法

LRU是Least Recently Used的縮寫，即最近最少使用，是一種經常使用的頁面置換算法，選擇最近最久未使用的頁面予以淘汰。該算法賦予每一個頁面一個訪問字段，用來記錄一個頁面自上次被訪問以來所經歷的時間 t，當須淘汰一個頁面時，選擇現有頁面中其 t 值最大的，即最近最少使用的頁面予以淘汰。
計算維度: 時間T
注意事項: LRU算法是迄今爲止內存中最好用的數據置換算法.

2.3 LFU算法

LFU（least frequently used (LFU) page-replacement algorithm）。即最不常用頁置換算法，要求在頁置換時置換引用計數最小的頁，由於常用的頁應該有一個較大的引用次數。可是有些頁在開始時使用次數不少，但之後就再也不使用，這類頁將會長時間留在內存中，所以能夠將引用計數寄存器定時右移一位，造成指數衰減的平均使用次數。
維度: 使用次數

2.4 隨機算法

隨機算法.

2.5 TTL算法

根據剩餘的存活時間,將立刻要超時的數據提早刪除.

2.6 配置內存優化策略

3.volatile-lfu 在設定了超時時間的數據中,採用lfu算法
4.allkeys-lfu 全部數據採用lfu算法
5.volatile-random 設置超時時間數據的隨機算法
6.allkeys-random 全部數據的隨機
7.volatile-ttl 將設定了超時時間的數據,提早刪除.
8.noeviction 默認規則 若是設定noeviction 則不刪除數據,直接報錯返回.

手動修改redis內存優化策略:

3.關於緩存面試問題

問題出發點:
因爲緩存失效,致使大量的用戶的請求,直接訪問數據庫服務器.致使負載太高,從而引起總體宕機的風險!!!

3.1 緩存穿透

說明: 用戶頻繁訪問數據庫中不存在的數據,可能出現緩存穿透的現象.若是該操做是高併發操做,則可能直接威脅數據庫服務器.
解決方案:
1.採用IP限流的方式 下降用戶訪問服務器次數. IP動態代理(1分鐘變一次)
2.微服務的處理方式: 利用斷路器返回執行的業務數據便可不執行數據庫操做 從而保護了數據庫.
3.微服務處理方式: API網關設計. 不容許作非法操做

3.2 緩存擊穿

說明: 因爲redis中某個熱點數據因爲超時/刪除等操做形成數據失效.同時用戶高併發訪問該數據,則可能致使數據庫宕機.該操做稱之爲 緩存擊穿.
解決方案: 能夠採用多級緩存的設計. 同時數據的超時時間採用隨機數的方式.

3.3 緩存雪崩

說明: 因爲redis內存數據大量失效.致使用戶的訪問命中率過低.大量的用戶直接訪問數據庫,可能致使數據庫服務器宕機. 這種現象稱之爲緩存雪崩.
解決:
1.採用多級緩存.
2.設定不一樣的超時時間
3.禁止執行 flushAll等敏感操做.

4.Redis分片機制

4.1 Redis分片說明

說明: 若是須要Redis存儲海量的內存數據,使用單臺redis不能知足用戶的需求,因此能夠採用Redis分片機制實現數據存儲.
注意事項:
若是有多臺redis,則其中的數據都是不同的…

4.2 Redis部署

搭建端口:6379/6380/6381

4.2.1 準備配置文件:

6379.conf 6380.conf 6381.conf

4.2.2 修改端口號

只修改80/81的端口便可

4.3 Redis分片測試

4.4 一致性HASH算法

4.4.1 概念

一致性哈希算法在1997年由麻省理工學院提出，是一種特殊的哈希算法，目的是解決分佈式緩存的問題。
[1] 在移除或者添加一個服務器時，可以儘量小地改變已存在的服務請求與處理請求服務器之間的映射關係。一致性哈希解決了簡單哈希算法在分佈式哈希表( Distributed Hash Table，DHT) 中存在的動態伸縮等問題 [2] 。

4.4.2 原理說明

知識複習:

1. 常規hash由多少位16進制數組成??? 8位16進制數組成 2^32次方
2. 若是對相同的數據進行hash計算問結果是否相同??? 結果必然相同.

4.4.3 特性一平衡性

①平衡性是指hash的結果應該平均分配到各個節點，這樣從算法上解決了負載均衡問題.
實現平衡性的方案: 引入虛擬節點

4.4.3 特性二單調性

②單調性是指在新增或者刪減節點時，不影響系統正常運行 [4] 。
特色:在進行數據遷移時,要求儘量小的改變數據.

4.4.4 特性三分散性

③分散性是指數據應該分散地存放在分佈式集羣中的各個節點(節點本身能夠有備份)，沒必要每一個節點都存儲全部的數據 [4] 。
俗語: 雞蛋不要到放到一個籃子裏

4.5 SpringBoot整合Redis分片

4.5.1 編輯properties配置文件

4.5.2 編輯配置類

4.5.3 修改AOP緩存注入

說明:將AOP中的注入對象切換爲分片對象

5 Redis哨兵機制

5.1 分片機制存在的問題

說明: redis分片主要的做用是實現內存數據的擴容.可是若是redis分片中有一個節點宕機,則直接影響全部節點的運行. 可否優化?
實現策略: 採用Redis哨兵機制實現Redis節點高可用.

5.2 Redis節點主從配置

5.2.1 準備主從節點

1).關閉redis分片的節點,以後複製配置文件準備哨兵的配置.

2).複製分片的目錄 更名爲sentinel

3).刪除多餘的持久化文件,保存redis配置文件

4).啓動3臺Redis服務器

5.2.2 實現redis主從

命令: info replication 檢查redis節點的狀態信息

節點劃分: 6379 當主機 6380/81 當從機

命令2: 實現主從掛載 slaveof host port


3).檢查6379主機的狀態

結論: redis全部節點均可以相同通訊.而且路徑當前的主從的狀態.

數據主從同步的狀態

5.3 哨兵機制工做原理

1).當哨兵啓動時,會連接redis主節點,同時獲取全部節點的狀態信息
2).當哨兵連續3次經過心跳檢測機制(PING-PONG),若是發現主機宕機,則開始選舉.
3).哨兵內部經過隨機算法篩選一臺從機當選新的主機.其餘的節點應該當新主機的從.

5.4 哨兵機制配置

5.4.1 關閉保護模式

5.4.2 開啓後臺運行

5.4.3 配置投票機制

5.5 哨兵高可用測試

1.啓動哨兵 redis-sentinel sentinel.conf

2).檢查哨兵配置

3)將主機宕機,以後檢查從機是否當選主機

4).啓動以前的主機,檢查是否當選新主機的從

5).若是搭建異常 則刪除重作
關閉全部redis服務器.