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

武定網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)公司！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站設(shè)計(jì)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。成都創(chuàng)新互聯(lián)公司于2013年開始到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)公司。

數(shù)據(jù)的持久化存儲(chǔ)是 Redis 的重要特性之一，它能夠?qū)?nèi)存中的數(shù)據(jù)保存到本地磁盤中，實(shí)現(xiàn)對(duì)數(shù)據(jù)的持久存儲(chǔ)。這樣即使在服務(wù)器發(fā)生故障之后，也能通過本地磁盤對(duì)數(shù)據(jù)進(jìn)行恢復(fù)。

Redis 提供了兩種持久化機(jī)制：第一種是 RDB，又稱快照（snapshot）模式，第二種是 AOF 日志，也就追加模式。本節(jié)先講解 RDB 快照模式，關(guān)于 AOF 日志會(huì)在《Redis AOF持久化詳解》一節(jié)講解。

RDB快照模式原理

RDB 即快照模式，它是 Redis 默認(rèn)的數(shù)據(jù)持久化方式，它會(huì)將數(shù)據(jù)庫的快照保存在 dump.rdb 這個(gè)二進(jìn)制文件中。

提示：所謂“快照”就是將內(nèi)存數(shù)據(jù)以二進(jìn)制文件的形式保存起來。

我們知道 Redis 是單線程的，也就說一個(gè)線程要同時(shí)負(fù)責(zé)多個(gè)客戶端套接字的并發(fā)讀寫，以及內(nèi)存數(shù)據(jù)結(jié)構(gòu)的邏輯讀寫。

Redis 服務(wù)器不僅需要服務(wù)線上請(qǐng)求，同時(shí)還要備份內(nèi)存快照。在備份過程中 Redis 必須進(jìn)行文件 IO 讀寫，而 IO 操作會(huì)嚴(yán)重服務(wù)器的性能。那么如何實(shí)現(xiàn)既不影響客戶端的請(qǐng)求，又實(shí)現(xiàn)快照備份操作呢，這時(shí)就用到了多進(jìn)程。

Redis 使用操作系統(tǒng)的多進(jìn)程 COW(Copy On Write) 機(jī)制來實(shí)現(xiàn)快照持久化操作。

RDB 實(shí)際上是 Redis 內(nèi)部的一個(gè)定時(shí)器事件，它每隔一段固定時(shí)間就去檢查當(dāng)前數(shù)據(jù)發(fā)生改變的次數(shù)和改變的時(shí)間頻率，看它們是否滿足配置文件中規(guī)定的持久化觸發(fā)條件。當(dāng)滿足條件時(shí)，Redis 就會(huì)通過操作系統(tǒng)調(diào)用 fork() 來創(chuàng)建一個(gè)子進(jìn)程，該子進(jìn)程與父進(jìn)程享有相同的地址空間。

Redis 通過子進(jìn)程遍歷整個(gè)內(nèi)存空間來獲取存儲(chǔ)的數(shù)據(jù)，從而完成數(shù)據(jù)持久化操作。注意，此時(shí)的主進(jìn)程則仍然可以對(duì)外提供服務(wù)，父子進(jìn)程之間通過操作系統(tǒng)的 COW 機(jī)制實(shí)現(xiàn)了數(shù)據(jù)段分離，從而保證了父子進(jìn)程之間互不影響。

RDB持久化觸發(fā)策略

RDB 持久化提供了兩種觸發(fā)策略：一種是手動(dòng)觸發(fā)，另一種是自動(dòng)觸發(fā)。

1) 手動(dòng)觸發(fā)策略

手動(dòng)觸發(fā)是通過
SAVAE命令或者
BGSAVE命令將內(nèi)存數(shù)據(jù)保存到磁盤文件中。如下所示：

127.0.0.1:6379> SAVE
OK
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379>  LASTSAVE
(integer) 1611298430

上述命令
BGSAVE從后臺(tái)執(zhí)行數(shù)據(jù)保存操作，其可用性要優(yōu)于執(zhí)行 SAVE 命令。

SAVE 命令會(huì)阻塞 Redis 服務(wù)器進(jìn)程，直到 dump.rdb 文件創(chuàng)建完畢為止，在這個(gè)過程中，服務(wù)器不能處理任何的命令請(qǐng)求。

BGSAVE命令是非阻塞式的，所謂非阻塞式，指的是在該命令執(zhí)行的過程中，并不影響 Redis 服務(wù)器處理客戶端的其他請(qǐng)求。這是因?yàn)?Redis 服務(wù)器會(huì) fork() 一個(gè)子進(jìn)程來進(jìn)行持久化操作（比如創(chuàng)建新的 dunp.rdb 文件），而父進(jìn)程則繼續(xù)處理客戶端請(qǐng)求。當(dāng)子進(jìn)程處理完后會(huì)向父進(jìn)程發(fā)送一個(gè)信號(hào)，通知它已經(jīng)處理完畢。此時(shí)，父進(jìn)程會(huì)用新的 dump.rdb 文件覆蓋掉原來的舊文件。

因?yàn)?br /> SAVE命令無需創(chuàng)建子進(jìn)程，所以執(zhí)行速度要略快于
BGSAVE命令，但是
SAVE命令是阻塞式的，因此其可用性欠佳，如果在數(shù)據(jù)量較少的情況下，基本上體會(huì)不到兩個(gè)命令的差別，不過仍然建議您使用
BGSAVE命令。

注意：LASTSAVE 命令用于查看 BGSAVE 命令是否執(zhí)行成功。

2) 自動(dòng)觸發(fā)策略

自動(dòng)觸發(fā)策略，是指 Redis 在指定的時(shí)間內(nèi)，數(shù)據(jù)發(fā)生了多少次變化時(shí)，會(huì)自動(dòng)執(zhí)行
BGSAVE命令。自動(dòng)觸發(fā)的條件包含在了 Redis 的配置文件中，如下所示：

上圖所示， save m n 的含義是在時(shí)間 m 秒內(nèi)，如果 Redis 數(shù)據(jù)至少發(fā)生了 n 次變化，那么就自動(dòng)執(zhí)行
BGSAVE命令。配置策略說明如下：

• save 900 1 表示在 900 秒內(nèi)，至少更新了 1 條數(shù)據(jù)，Redis 自動(dòng)觸發(fā) BGSAVE 命令，將數(shù)據(jù)保存到硬盤。
• save 300 10 表示在 300 秒內(nèi)，至少更新了 10 條數(shù)據(jù)，Redis 自動(dòng)觸 BGSAVE 命令，將數(shù)據(jù)保存到硬盤。
• save 60 10000 表示 60 秒內(nèi)，至少更新了 10000 條數(shù)據(jù)，Redis 自動(dòng)觸發(fā) BGSAVE 命令，將數(shù)據(jù)保存到硬盤。

只要上述三個(gè)條件任意滿足一個(gè)，服務(wù)器就會(huì)自動(dòng)執(zhí)行
BGSAVE命令。當(dāng)然您可以根據(jù)實(shí)際情況自己調(diào)整觸發(fā)策略。

注意：每次創(chuàng)建 RDB 文件之后，Redis 服務(wù)器為實(shí)現(xiàn)自動(dòng)持久化而設(shè)置的時(shí)間計(jì)數(shù)和次數(shù)計(jì)數(shù)就會(huì)被清零，并重新開始計(jì)數(shù)，因此多個(gè)策略的效果不會(huì)疊加。

RDB持久化優(yōu)劣勢(shì)

最后我們對(duì) RDB 持久化的優(yōu)劣勢(shì)做簡(jiǎn)單地分析：

我們知道，在 RDB 持久化的過程中，子進(jìn)程會(huì)把 Redis 的所有數(shù)據(jù)都保存到新建的 dump.rdb 文件中，這是一個(gè)既消耗資源又浪費(fèi)時(shí)間的操作。因此 Redis 服務(wù)器不能過于頻繁地創(chuàng)建 rdb 文件，否則會(huì)嚴(yán)重影響服務(wù)器的性能。

RDB 持久化的最大不足之處在于，最后一次持久化的數(shù)據(jù)可能會(huì)出現(xiàn)丟失的情況。我們可以這樣理解，在 持久化進(jìn)行過程中，服務(wù)器突然宕機(jī)了，這時(shí)存儲(chǔ)的數(shù)據(jù)可能并不完整，比如子進(jìn)程已經(jīng)生成了 rdb 文件，但是主進(jìn)程還沒來得及用它覆蓋掉原來的舊 rdb 文件，這樣就把最后一次持久化的數(shù)據(jù)丟失了。

RDB 數(shù)據(jù)持久化適合于大規(guī)模的數(shù)據(jù)恢復(fù)，并且還原速度快，如果對(duì)數(shù)據(jù)的完整性不是特別敏感（可能存在最后一次丟失的情況），那么 RDB 持久化方式非常合適。