日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

成都創(chuàng)新互聯(lián)專注于網(wǎng)站建設|網(wǎng)站建設維護|優(yōu)化|托管以及網(wǎng)絡推廣，積累了大量的網(wǎng)站設計與制作經(jīng)驗，為許多企業(yè)提供了網(wǎng)站定制設計服務，案例作品覆蓋成都陽光房等行業(yè)。能根據(jù)企業(yè)所處的行業(yè)與銷售的產(chǎn)品，結合品牌形象的塑造，量身制作品質網(wǎng)站。

開啟AOF持久化

AOF 機制默認處于未開啟狀態(tài)，可以通過修改 Redis 配置文件開啟 AOF，如下所示：

1) Windows系統(tǒng)

執(zhí)行如下操作：

#修改配置文件，把no改為 yes
appendonly yes
#確定存儲文件名是否正確
appendfilename "appendonly.aof"
#重啟服務器
redis-server --service-stop
redis-server --service-start

2) Linux系統(tǒng)

執(zhí)行如下操作：

#修改配置文件：
vim /etc/redis/redis.conf
appendonly yes # 把 no 改為 yes
#確定存儲文件名是否正確
appendfilename "appendonly.aof"
#重啟服務：
sudo /etc/init.d/redis-server restart

提示：本節(jié)建議在您在 Linux 系統(tǒng)上操作 Redis，否則一些 AOF 的性能無法體現(xiàn)。

AOF持久化機制

每當有一個修改數(shù)據(jù)庫的命令被執(zhí)行時，服務器就將命令寫入到 appendonly.aof 文件中，該文件存儲了服務器執(zhí)行過的所有修改命令，因此，只要服務器重新執(zhí)行一次 .aof 文件，就可以實現(xiàn)還原數(shù)據(jù)的目的，這個過程被形象地稱之為“
命令重演”。

1) 寫入機制

Redis 在收到客戶端修改命令后，先進行相應的校驗，如果沒問題，就立即將該命令存追加到 .aof 文件中，也就是先存到磁盤中，然后服務器再執(zhí)行命令。這樣就算遇到了突發(fā)的宕機情況情況，也只需將存儲到  .aof 文件中的命令，進行一次“命令重演”就可以恢復到宕機前的狀態(tài)。

在上述執(zhí)行過程中，有一個很重要的環(huán)節(jié)就是命令的寫入，這是一個 IO 操作。Redis 為了提升寫入效率，它不會將內容直接寫入到磁盤中，而是將其放到一個內存緩存區(qū)（buffer）中，等到緩存區(qū)被填滿時才真正將緩存區(qū)中的內容寫入到磁盤里。

2) 重寫機制

Redis 在長期運行的過程中，aof 文件會越變越長。如果機器宕機重啟，“重演”整個 aof 文件會非常耗時，導致長時間 Redis 無法對外提供服務。因此就需要對 aof 文件做一下“瘦身”運動。

為了讓 aof 文件的大小控制在合理的范圍內，Redis 提供了 AOF 重寫機制，手動執(zhí)行
BGREWRITEAOF命令，開始重寫 aof 文件，如下所示：

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

通過上述操作后，服務器會生成一個新的 aof 文件，該文件具有以下特點：

• 新的 aof 文件記錄的數(shù)據(jù)庫數(shù)據(jù)和原 aof 文件記錄的數(shù)據(jù)庫數(shù)據(jù)完全一致；
• 新的 aof 文件會使用盡可能少的命令來記錄數(shù)據(jù)庫數(shù)據(jù)，因此新的 aof 文件的體積會小很多；
• AOF 重寫期間，服務器不會被阻塞，它可以正常處理客戶端發(fā)送的命令。

下表對原有 aof 文件和新生成的 aof 文件做了對比，如下所示：

從上表可以看出，新生成的 aof 文件中，它的命令格式做了很大程度的簡化。

3) 自動觸發(fā)AOF重寫

Redis 為自動觸發(fā) AOF 重寫功能，提供了相應的配置策略。如下所示：修改 Redis 配置文件，讓服務器自動執(zhí)行 BGREWRITEAOF 命令。

#默認配置項
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb #表示觸發(fā)AOF重寫的最小文件體積,大于或等于64MB自動觸發(fā)。

該配置項表示：觸發(fā)重寫所需要的 aof 文件體積百分比，只有當 aof 文件的增量大于 100% 時才進行重寫，也就是大一倍。比如，第一次重寫時文件大小為 64M，那么第二次觸發(fā)重寫的體積為 128M，第三次重寫為 256M，以此類推。如果將百分比值設置為 0 就表示關閉 AOF 自動重寫功能。

AOF策略配置

在上述介紹寫入機制的過程中，如果遇到宕機前，緩存內的數(shù)據(jù)未能寫入到磁盤中，那么數(shù)據(jù)仍然會有丟失的風險。服務器宕機時，丟失命令的數(shù)量，取決于命令被寫入磁盤的時間，越早地把命令寫入到磁盤中，發(fā)生意外時丟失的數(shù)據(jù)就會越少，否則越多。

Redis 為數(shù)據(jù)的安全性考慮，同樣為 AOF 持久化提供了策略配置，打開 Redis 配置文件，如下圖所示：

上述配置策略說明如下：

• Always：服務器每寫入一個命令，就調用一次 fsync 函數(shù)，將緩沖區(qū)里面的命令寫入到硬盤。這種模式下，服務器出現(xiàn)故障，也不會丟失任何已經(jīng)成功執(zhí)行的命令數(shù)據(jù)，但是其執(zhí)行速度較慢；
• Everysec（默認）：服務器每一秒調用一次 fsync 函數(shù)，將緩沖區(qū)里面的命令寫入到硬盤。這種模式下，服務器出現(xiàn)故障，最多只丟失一秒鐘內的執(zhí)行的命令數(shù)據(jù)，通常都使用它作為 AOF 配置策略；
• No：服務器不主動調用 fsync 函數(shù)，由操作系統(tǒng)決定何時將緩沖區(qū)里面的命令寫入到硬盤。這種模式下，服務器遭遇意外停機時，丟失命令的數(shù)量是不確定的，所以這種策略，不確定性較大，不安全。

注意：Linux 系統(tǒng)的 fsync() 函數(shù)可以將指定文件的內容從內核緩存刷到硬盤中。

由于是 fsync 是磁盤 IO 操作，所以它很慢！如果 Redis 執(zhí)行一條指令就要 fsync 一次（Always），那么 Redis 高性能將嚴重受到影響。

在生產(chǎn)環(huán)境的服務器中，Redis 通常是每隔 1s 左右執(zhí)行一次 fsync 操作（ Everysec），這樣既保持了高性能，也讓數(shù)據(jù)盡可能的少丟失。最后一種策略（No），讓操作系統(tǒng)來決定何時將數(shù)據(jù)同步到磁盤，這種策略存在許多不確定性，所以不建議使用。

從三種策略的運行速度來看，Always 的速度最慢，而 Everysec 和 No 都很快。

AOF和RDB對比

如果進行數(shù)據(jù)恢復時，既有 dump.rdb文件，又有 appendonly.aof 文件，您應該先通過 appendonly.aof 恢復數(shù)據(jù)，這能最大程度地保證數(shù)據(jù)的安全性。