緩存什麼時候持久化

A. Redis持久化策略(看這篇,你肯定會有所獲)

RDB：Redis DataBase ， 記錄快照

        RDB是redis 默認的持久化方案. RDB 是當滿足一定條件時, 就會將redis內存中的數據寫入磁碟,並生成一個快照文件mp.rdb 文件.Redis 重啟會通過載入mp.rdb文件恢復數據.

        一定條件分為以下幾種情況: 1.自動觸發  2. 手動觸發 . 下面分開說明下:

a).redis.conf 中 SNAPSHOTTING 其中定義了觸發把數據保存到磁碟的觸發頻率.

        如果不需要rdb 方案, 注釋save 或者配置成空字元串" ".

        save 900 1 #900秒內至少有一個key被修改(包括添加)

        save 300 10 #400秒內至少10個key被修改

        save 10000 #60秒內至少有10000個key 被修改.

        這三條配置不沖突, 只要滿足一條就觸發.

        rdb 文件位置和目錄 (默認在安裝根目錄下) 

        #文件路徑

        dir ./

        #文件名稱

        dbfilename mp.rdb

        #是否以LZY壓縮rdb 文件

        rdbcompression yes 

        #開啟數據校驗

        rdbchecksum yes

b) shutdown觸發 ,保證伺服器正常關閉.

c) flushall , rdb文件是空的, 會生成一個空的文件,所以這種情況也沒有什麼意義.但需要知道,這種情況下

會觸發生成rdb文件.

Redis 提供了兩條命令: save 和 bgsave

a). save 命令

        save 在生成快照的時候會阻塞當前Redis 伺服器,Redis不能處理其他命令.如果內存數據較多,會造成

b).bgsave 命令

        執行bgsave命令時,   Redis會在後台進行非同步快照操作,快照同時還可以響應客戶端請求.

具體操作

        具體操作:Redis進程會執行fork操作創建子進程(-on-write),RDB 持久化過程由子進程負載,完成後自動結束.它不會記錄fork之後產生的記錄.阻塞只發送在fork階段,一般時間較短.

一.優勢

    1.RDB是一個非常緊湊的文件,它保存了Redis在某個時間點上的數據集.這種文件非常適合進行備份和

災難恢復.

    2.生成RDB文件的時候,redis主進程會fork()一個子進程來處理所有保存的工作,主進程不需要進行任何

IO操作.

    3.RDB在恢復大數據集時的速度比AOF的恢復速度要快

二.劣勢

    1).RDB 沒辦法做到實時持久化/妙級持久化.因為bgsave每次運行都要執行fork創建子進程,頻繁執行成本過高.    

    2).在一定間隔時間做一次備份,所以如果Redis 以為down掉的話,就會丟失最後一次快照之後所有修改

(數據有丟失)

AOF：<Append Only File> ， 記錄日誌

Redis 默認不開啟.AOF採用日誌的形式來記錄每個寫操作,並追加到文件中.開啟後,執行更改Redis    命令時,就會把命令寫入到AOF文件中.

Redis 重啟時會根據日誌文件的內容把寫指令從前往後執行一次以完成數據的恢復工作.

#開關

appendonly no

#文件名

appendfilename "appendonly.aof"

        由於操作系統緩存機制,AOF數據並沒有真正地寫入硬碟,而是進入了系統的硬碟緩存.什麼時候

把緩沖區的內容寫入到AOF文件中? 由下面參數決定

appendfsync :  值: no  \ always \everysec 

        no: 表示不執行fync, 由操作系統保證數據同步到磁碟,速度最快,但是不安全.

        always:表示每次寫入都執行fync,以保證數據同步到磁碟,效率很低

        everysec:表示每秒執行以fync ,可能會導致丟失1s數據.通常選擇everysec,兼顧效率和安全性.

    因為AOF文件只有一個, 隨著redis 不斷進行,AOF 的文件會越來越大,文件越大, 文件佔用伺服器內存

以及AOF恢復要求時間越長.

    為了解決這個問題,可以使用bgwriteaof來重寫.那什麼時候重寫? 又是怎樣重寫?

    一. 什麼時候重寫?

    #重寫觸發機制

    auto-aof-rewrite-percentage 100 默認值是100. 當前aof 文件大小超過 上一次重寫的aof文件大小百分之多少進行重寫,即當aof文件增長到一定大小時,Redis能夠調用bgwriteaof對日誌文件進行重寫.當前aof文件大小是上次日誌重寫得到aof文件大小的二倍時, 自動啟動新的日誌重寫過程.

    auto-aof-rewrite-min-size 默認是64M.設置允許重寫的最小aof文件大小,避免達到了約定百分比 但尺寸

仍然很小的情況還要重寫.

   二. 怎樣重寫?

    並不是對原文件進行重新整理,而是直接讀取伺服器上現有的鍵值對,然後用一條命令去代替之間記錄這

個鍵值對的多條命令,生成一個新的文件後去替換原來的 AOF文件.

    看下面這兩個參數:

        no-appendfsync-on-rewrite

        aof-load-truncated

   AOF 數據恢復

        重啟Redis之後就會進行AOF文件恢復.

   AOF 的優勢和劣勢

優點:

1.AOF 持久化的方法提供了多種的同步頻率,即使使用默認的同步頻率每秒同步一次,Redis最多也就丟失

1秒的數據.

缺點:

1.對於具有相同數據的Redis, AOF文件通常比RDF文件體積更大(RDB存的是數據快照)

2.雖然AOF提供了多種同步的頻率,默認的情況下,沒秒同步一次的頻率也具有較高的性能.在高並發的情況下,RDB比AOF具有更好的性能.

        如果可以忍一小段時間數據的丟失,毫無疑問使用RDB 是最好的,定時生成RDB快照非常便於進行數據備份,而且RDB恢復數據集的速度也要比AOF恢復速度要快.

        否則就要使用AOF重寫.但是一般情況下建議不要單獨使用某一種持久化機制,而是兩種一起用.

本文內容來自咕泡學院-青山老師,感謝青山老師!!

B. linux裡面什麼是數據持久化

數據持久化顧名思義就是把程序中的數據以某種形式保存到某存貯介質中，以達到持久化的目的。當程序運行時，一些數據是臨時保存在內存中，一旦退出系統，這些數據就丟失了。那麼，使用某種手段將數據保存在硬碟上或者資料庫中，這樣即使退出系統後又重新啟動系統，那麼這些數據仍然可以重新找回來。

例如管理員向一個用戶管理系統中添加了一個用戶的資料，那麼這個系統需要將新添加的資料保存到資料庫中，否則系統退出或者電腦重啟後該用戶資料就會丟失。將數據從內存保存到資料庫中，這便是數據的持久化。當然，資料庫只是持久化方式中的一種，也可以保存在其他的永久存貯介質中。

圖為數據持久化的過程示意圖。

持久化（Persistence），即把數據（如內存中的對象）保存到可永久保存的存儲設備中（如磁碟）。持久化的主要應用是將內存中的對象存儲在資料庫中，或者存儲在磁碟文件中、XML數據文件中等等。

持久化是將程序數據在持久狀態和瞬時狀態間轉換的機制。

DBC就是一種持久化機制。文件IO也是一種持久化機制。

日常持久化的方法

在一定周期內保持不變就是持久化,持久化是針對時間來說的。資料庫中的數據就是持久化了的數據,只要你不去刪除或修改。比如在瀏覽器中一次Session會話中Session對象變數也是不變的,是Session容器中持久化。對象持久化的方式有很多種,根據周期不同有,page,Session,Application。對象序列化機制對於需要將對象的狀態保存到文件中，而後能夠通過讀入對象狀態來重新構造對象，恢復程序狀態. 對象序列化的過程是對象持久化的方法之一,把對象保存到文件中。

簡單的理解持久化可以在二個層面：應用層和系統層、

應用層

如果關閉(shutdown)你的應用然後重新啟動則先前的數據依然存在。

系統層

如果關閉(shutdown)你的系統（電腦）然後重新啟動則先前的數據依然存在。

持久化是一種對象服務實現至少3個介面

，就是把內存中的對象保存到外存中，讓以後能夠取回。需要實現至少3個介面：

void Save(object o) 把一個對象保存到外存中

Object Load(object oid) 通過對象標識從外存中取回對象

boolExists(object oid) 檢查外存中是否存在某個對象.

類似概念序列化

我們先跳開一下，看看另一個類似的有用概念：序列化Serialize也是一種對象服務，就是把內存中的對象序列化成流、或者把流反序列化成對象。需要實現2個介面：

void Serialize(Stream stream,object o) 把對象序列化到流中

object Deserialize(Stream stream) 把流反序列化成對象

序列化和持久化很相似，有些人甚至混為一談，其實還是有區別的，序列化是為了解決對象的傳輸問題，傳輸可以在線程之間、進程之間、內存外存之間、主機之間進行。我之所以在這里提到序列化，是因為我們可以利用序列化來輔助持久化，可以說凡是可以持久化的對象都可以序列化，因為序列化相對容易一些（也不是很容易），所以主流的軟體基礎設施，比如.net和java，已經把序列化的框架完成了。

持久化方案可以分為關系資料庫方案、文件方案、對象資料庫方案、xml資料庫方案

現今主流的持久化方案是關系資料庫方案，

關系資料庫方案不僅解決了並發的問題，更重要的是，關系資料庫還提供了持久化服務之外的價值：統計分析功能。剛才我說到，凡是可以序列化的對象都可以持久化，極端的說，我們可以只建立一個表Object(OID,Bytes)，但基本上沒有人這么做，因為一旦這樣，我們就失去了關系資料庫額外的統計分析功能。關系資料庫和面向對象之間有一條鴻溝，因為二者模式不匹配，所以就存在一個OR映射問題。

Redis支持兩種數據持久化方式：rdb方式和aof方式。前者會根據配置的規則定時將內存中的數據持久化到硬碟上，後者則是在每次執行寫命令之後將命令記錄下來。兩種持久化方式可以單獨使用，但是通常會將兩者結合使用。

1、RDB方式

RDB方式的持久化是通過快照的方式完成的。當符合某種規則時，會將內存中的數據全量生成一份副本存儲到硬碟上，這個過程稱作」快照」，redis默認開啟該持久化功能，具體配置如下：

save 900 1

save 300 10

save 60 10000

stop-writes-on-bgsave-error yes

rdbcompression yes

rdbchecksum yes

dbfilename mp.rdb

#文件名稱

dir ./

#rdb文件存放路徑

配置後系統會自動進行快照，save 60 10000表示60秒內有10000次寫入，那麼就會調用bgsave

除了系統自動進行快照外，我們也可以手動執行SAVE或BGSAVE命令主動進行快照操作：

執行SAVE或BGSAVE命令

執行FLUSHALL命令

2、AOF方式

在使用Redis存儲非臨時數據時，一般都需要打開AOF持久化來降低進程終止導致的數據丟失，AOF可以將Redis執行的每一條寫命令追加到硬碟文件中，這一過程會降低Redis的性能。

默認情況下，Redis沒有開啟AOF（append only file）持久化功能，可以通過在配置文件中作如下配置啟用：

appendonly no #是否開啟aof，開啟時將no改為yes

appendfilename "appendonly.aof" 持久化文件名稱

auto-aof-rewrite-percentage 100

#當前AOF文件大小是上次日誌重寫得到AOF文件大小的二倍時，自動啟動新的日誌重寫過程。

auto-aof-rewrite-min-size 64mb

#當前AOF文件啟動新的日誌重寫過程的最小值，避免剛剛啟動Reids時由於文件尺寸較小導致頻繁的重寫。

appendfsync :everysec (推薦配置)

#持久化策略

always (同步持久化，每次發生數據變更會被立即記錄到磁碟，性能差但數據完整性比較好)

everysec (非同步操作，每秒記錄，如果一秒鍾內宕機，有數據丟失)

no （將緩存回寫的策略交給系統，linux 默認是30秒將緩沖區的數據回寫硬碟的）

一般來說可以考慮同時使用兩種持久化方案.

C. 網頁緩存的生命周期是多少

有很多理由去解釋理解ASP.NET頁面生命周期是非常重要的，主要是要去理解什麼地方放置什麼特定的方法，什麼時候我們應該設置什麼相關的屬性。如果去開發自定義的伺服器控制項，理解生命周期對糾正控制項初始化時候的錯誤，以及使用view-state和後台代碼設置屬性是非常有用的。（控制項事件只與ASP.NET頁面相關）

頁面生命周期要看它是否是第一次請求，還是回發（本身頁面請求），最後決定是否到Web伺服器。當一個網頁被Web伺服器請求時，在回發到web瀏覽器之前，會經過一系列步驟/事件(如初始化，控制項實例化，state的恢復和保存，執行事件處理代碼，渲染)。

如果我們正確地使用和操作頁面生命周期事件，它對web應用程序開發會是一個非常方便和強大的工具。