Redis的持久化操作

2020-11-15 閃念基因

作者:learner

出處:https://segmentfault.com/a/1190000038170221

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伺服器.

作者:learner

出處:https://segmentfault.com/a/1190000038170221

相關焦點

  • Redis持久化及Redis集群
    設置持久化快照的條件在redis.conf中修改持久化快照的條件，如下：Rdb問題一旦redis非法關閉，那麼會丟失最後一次持久化之後的數據。Redis默認是不使用該方式持久化的。Aof方式的持久化，是操作一次redis資料庫，則將操作的記錄存儲到aof持久化文件中。第一步：開啟aof方式的持久化方案將redis.conf中的appendonly改為yes，即開啟aof方式的持久化方案。
  • Redis持久化之AOF持久化
    首先，需要開啟AOF持久化功能，這裡為了測試，我們把原有的配置文件redis.conf複製一份，命名為redis_aof.conf，然後修改appendonly 為yes，其餘配置不變Linux系統內核提供頁緩衝區來提高硬碟的IO性能，write操作在寫入系統緩衝區後就直接返回了，這時候數據還在系統緩衝區中，什麼時候真正同步到硬碟，取決於系統自身的調度機制，如果write操作成功後，系統還沒來得及同步到硬碟，那麼緩衝區中的數據將丟失。而fsync是強制同步硬碟，fsync會阻塞直到同步硬碟完成。知道了這兩個操作的區別，我們回頭再來看這三種同步策略。
  • Redis持久化
    Redis持久化就是將內存中的數據寫入磁碟，可以避免因某些故障導致的數據丟失，它支持rdb快照和aof文件兩種持久化機制。RDB持久化rdb保存支持同步阻塞(save)和異步非阻塞(bgsave)兩種方式：1 客戶端執行save命令時，當文件較大時就需要較長時間來完成rdb文件的保存，在此過程中，redis將不能提供服務，即redis服務不可用；2 客戶端執行bgsave命令時，當前的主進程會fork出一個子進程來完成快照文件保存
  • Redis 持久化
    為了達到這一目的，通常有兩種實現方式：將 Redis 當作一個狀態機，記錄每一次的對 Redis 的操作，也就是狀態轉移。需要恢復是再從初始狀態開始，依次重放記錄的操作，這樣的方式稱作邏輯備份將 Redis 完整的狀態保存下來，待必要時原樣恢復，這樣的方式稱作物理備份Redis 也實現了這兩種持久化方式，分別是 AOF 和 RDBAOFAOF 通過保存 Redis 伺服器執行的寫命令記錄資料庫狀態
  • 你不知道的redis三-Redis的持久化機制
    一、持久化我們前兩章已經講了，redis是內存型的資料庫，他之所以快是因為數據存儲在內存。那麼數據存儲在內存會有什麼問題呢？當然就是當服務重啟或者伺服器宕機內存數據就被清除，我們就無法訪問之前存儲的數據了。那麼怎麼解決這個問題呢？
  • Redis教程:Redis持久化方式
    ,只有主伺服器當時沒有進行bgsave操 作,那麼主伺服器就會執行bgsave操作。這一步是可選的， 如果你願意的話， 也可以同時使用 RDB 和 AOF 這兩種持久化功能。重要:別忘了在 redis.conf 中打開 AOF 功能！ 否則的話， 伺服器重啟之後， 之前通過 CONFIG SET 設置的配置就會被遺忘， 程序會按原來的配置來啟動伺服器。
  • Redis持久化方式
    眾所周知，redis是內存資料庫，在運行期間會將所有數據加載到內存中，所以如果不把數據落到磁碟的話，redis進程一旦被停掉，數據就會全部丟失。例如：（redis持久化已關閉，看下情況）。一開始redis裡面有多個key存在，關掉重啟之後，數據都已丟失。
  • Redis持久化和備份
    因為RDB 文件需要保存整個數據集的狀態， 所以它並不是一個輕鬆的操作。不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。Redis與其他key-value存儲庫的不同之一是Redis運行在內存中但是可以持久化到磁碟，我們來看看Redis 持久化的相關方式。
  • Redis持久化RDB 和 AOF的區別
    如何持久化Redis會單獨創建(fork)一個子進程來進行持久化，會先將數據寫進一個臨時文件中，等到持久化過程結束了，再用這個臨時文件替換上次持久化好的文件。在這個過程中，只有子進程來負責IO操作，主進程仍然處理客戶端的請求，這就確保了極高的性能。
  • Redis持久化策略
    1 持久化概論1.1 什麼是持久化redis所有數據保持在內存中，對數據的更新將異步地保存到磁碟上。持久化主要是做災難恢復、數據恢復，可歸類到高可用。當發生寫操作時，Redis就會從一個狀態切換到另外一個狀態。 基於全量的持久化就是在某個時刻，將Redis的所有數據持久化到硬碟中，形成一個快照。當Redis 重啟時，通過加載最近一個快照數據，可以將 Redis 恢復至最近一次持久化狀態上。
  • Redis持久化(RDB和AOF方式)
    redis是內存資料庫,在硬體或者資料庫crash後內存數據會丟失,因此我們需要以一種方式將內存的數據定期同步到磁碟中,這樣即使redis意外重啟後可以從硬碟讀取持久化的數據並恢復到crash之前的狀態.redis支持兩種類型的持久化方案.
  • 來說說Redis兩種持久化方式的優缺點
    前言Redis是一種K-V資料庫，它的數據也可以進行持久化操作。因為redis的數據都保存在內存中，如果不進行及時的持久化，可能就會因為重啟導致數據的丟失。這時候就需要對redis進行持久化操作，將數據保存在磁碟上。
  • Redis - 持久化
    持久化先說說持久化在系統層面的模型或者流程，不管是文件持久化、Redis或者其他應用的持久化都是類似的。進程內產生的數據一般需要經過上述的步驟進行持久化。2、數據從內核緩存到硬碟    應用調用內核函數fsync或者作業系統自行調用fsync將數據刷到硬碟，該步驟真正將數據落盤的硬碟，需進行io操作，耗時。3、數據從硬碟緩存到硬碟物理空間    這裡就完全是硬碟自身的行為了，應用或者作業系統都無法控制。
  • redis的兩種持久化的機制，我又有了全新的認識
    redis提供了兩種持久化的機制 RDB和AOF機制RDB(redis Database):RDB保存某一個時間點之前的快照數據。AOF(Append-Only File):指所有的命令行記錄以redis命令請求協議的格式完全持久化存儲保存為aof文件混合持久化(4.0版本以後)：指進行AOF重寫時，子進程將當前時間點的數據快照保存為RDB文件格式，而後將父進程累計命令保存為AOF格式。
  • Redis持久化AOF和RDB機制介紹
    介紹了上面兩種配置後，找到配置文件做相應的開啟策略修改，配置文件路徑如下：/usr/local/redis/etc/redis.conf 自己執行寫日誌操作appendfsync everysec 系統內核自動調用Redis 持久化的數據會存在如下目錄：dir /var/lib/redis/6379
  • redis學習(四)鍵空間數據持久化
    二、要不要做持久化1、如果不開啟持久化功能redis能提供更好的性能。不管是阻塞的save命令持久化還是非阻塞的bgsave命令持久化以及AOF持久化都是要寫磁碟的，雖然有三種寫磁碟策略但終究還是有性能損耗。
  • Redis的持久化:來看一看技術行業的緩存神器是如何持久化數據的
    這個過程就叫做Redis持久化。Redis持久化有三種機制：1、RDB機制（Redis DataBase）：也叫快照機制，將某一時刻的內存快照數據以二進位方式寫入磁碟。3、混合機制：顧名思義，為RDB和AOF機制的組合，綜合了各自的優點，先將當前的數據以RDB方式寫入文件，再將操作命令以AOF方式寫入文件。實際運用時，需要根據業務場景的特點選擇不同的持久化方案，我們分別來看一下。
  • Redis單機資料庫持久化與過期建刪除
    定期刪除 每隔一段時間檢查一次資料庫，刪除裡面的過期鍵，至於檢查多少個資料庫，由算法決定 優點 對cpu和內存均比較友好 缺點 如果頻繁清除對cpu不友好，如果清除不及時對內存不友好從上面來看，不論選擇哪種方式都不是最優，畢竟人無完人，十全十美的策略也是不存在的，團隊的力量才是最強大的，所以redis最終採用的策略是惰性刪除與定期刪除相結合，定期刪除過期鍵，並且在做get操作時進行過期鍵檢查
  • Redis 持久化之 RDB 與 AOF 詳解
    不過我們可以從上面了解到，資料庫在持久化的過程中主要應該去實現步驟3，也就是將原本在內存中的數據持久化到作業系統的內核緩衝區中。至於下面的兩步，則是作業系統需要關心的事，資料庫無能為力。資料庫通常僅在必要的時候會去調用將數據從內存寫入磁碟的系統調用。
  • Redis的持久化機制：RDB快照和AOF追加文件
    Redis本來作為緩存使用，但是現在數據越來越重要，或者是redis在系統建設中起到了至關重要的環節，特別是在機器學習中訓練用的語料及相似度向量和索引，這樣就不希望Redis重啟之後，或者是宕機之後，數據丟失，所以Redis的持久化機制是我們不得不了解的一個內容。