android平台上持久化存储3种手段_深入学习Redis ：持久化
前言
在上一篇文章中，介紹了Redis的內(nèi)存模型，從這篇文章開(kāi)始，將依次介紹Redis高可用相關(guān)的知識(shí)——持久化、復(fù)制(及讀寫(xiě)分離)、哨兵、以及集群。
本文將先說(shuō)明上述幾種技術(shù)分別解決了Redis高可用的什么問(wèn)題；然后詳細(xì)介紹Redis的持久化技術(shù)，主要是RDB和AOF兩種持久化方案；在介紹RDB和AOF方案時(shí)，不僅介紹其作用及操作方法，同時(shí)介紹持久化實(shí)現(xiàn)的一些原理細(xì)節(jié)及需要注意的問(wèn)題。最后，介紹在實(shí)際使用中，持久化方案的選擇，以及經(jīng)常遇到的問(wèn)題等。
一、Redis高可用概述
在介紹Redis高可用之前，先說(shuō)明一下在Redis的語(yǔ)境中高可用的含義。
我們知道，在web服務(wù)器中，高可用是指服務(wù)器可以正常訪問(wèn)的時(shí)間，衡量的標(biāo)準(zhǔn)是在多長(zhǎng)時(shí)間內(nèi)可以提供正常服務(wù)(99.9%、99.99%、99.999% 等等)。但是在Redis語(yǔ)境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務(wù)(如主從分離、快速容災(zāi)技術(shù))，還需要考慮數(shù)據(jù)容量的擴(kuò)展、數(shù)據(jù)安全不會(huì)丟失等。
在Redis中，實(shí)現(xiàn)高可用的技術(shù)主要包括持久化、復(fù)制、哨兵和集群，下面分別說(shuō)明它們的作用，以及解決了什么樣的問(wèn)題。
二、Redis持久化概述
持久化的功能：Redis是內(nèi)存數(shù)據(jù)庫(kù)，數(shù)據(jù)都是存儲(chǔ)在內(nèi)存中，為了避免進(jìn)程退出導(dǎo)致數(shù)據(jù)的永久丟失，需要定期將Redis中的數(shù)據(jù)以某種形式(數(shù)據(jù)或命令)從內(nèi)存保存到硬盤(pán)；當(dāng)下次Redis重啟時(shí)，利用持久化文件實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。除此之外，為了進(jìn)行災(zāi)難備份，可以將持久化文件拷貝到一個(gè)遠(yuǎn)程位置。
Redis持久化分為RDB持久化和AOF持久化：前者將當(dāng)前數(shù)據(jù)保存到硬盤(pán)，后者則是將每次執(zhí)行的寫(xiě)命令保存到硬盤(pán)(類(lèi)似于MySQL的binlog)；由于AOF持久化的實(shí)時(shí)性更好，即當(dāng)進(jìn)程意外退出時(shí)丟失的數(shù)據(jù)更少，因此AOF是目前主流的持久化方式，不過(guò)RDB持久化仍然有其用武之地。
下面依次介紹RDB持久化和AOF持久化；由于Redis各個(gè)版本之間存在差異，如無(wú)特殊說(shuō)明，以Redis3.0為準(zhǔn)。
三、RDB持久化
RDB持久化是將當(dāng)前進(jìn)程中的數(shù)據(jù)生成快照保存到硬盤(pán)(因此也稱(chēng)作快照持久化)，保存的文件后綴是rdb；當(dāng)Redis重新啟動(dòng)時(shí)，可以讀取快照文件恢復(fù)數(shù)據(jù)。
1. 觸發(fā)條件
RDB持久化的觸發(fā)分為手動(dòng)觸發(fā)和自動(dòng)觸發(fā)兩種。
1) 手動(dòng)觸發(fā)
save命令和bgsave命令都可以生成RDB文件。
save命令會(huì)阻塞Redis服務(wù)器進(jìn)程，直到RDB文件創(chuàng)建完畢為止，在Redis服務(wù)器阻塞期間，服務(wù)器不能處理任何命令請(qǐng)求。
而bgsave命令會(huì)創(chuàng)建一個(gè)子進(jìn)程，由子進(jìn)程來(lái)負(fù)責(zé)創(chuàng)建RDB文件，父進(jìn)程(即Redis主進(jìn)程)則繼續(xù)處理請(qǐng)求。
此時(shí)服務(wù)器執(zhí)行日志如下：
bgsave命令執(zhí)行過(guò)程中，只有fork子進(jìn)程時(shí)會(huì)阻塞服務(wù)器，而對(duì)于save命令，整個(gè)過(guò)程都會(huì)阻塞服務(wù)器，因此save已基本被廢棄，線(xiàn)上環(huán)境要杜絕save的使用；后文中也將只介紹bgsave命令。此外，在自動(dòng)觸發(fā)RDB持久化時(shí)，Redis也會(huì)選擇bgsave而不是save來(lái)進(jìn)行持久化；下面介紹自動(dòng)觸發(fā)RDB持久化的條件。
2) 自動(dòng)觸發(fā)
save m n
自動(dòng)觸發(fā)最常見(jiàn)的情況是在配置文件中通過(guò)save m n，指定當(dāng)m秒內(nèi)發(fā)生n次變化時(shí)，會(huì)觸發(fā)bgsave。
例如，查看redis的默認(rèn)配置文件(Linux下為redis根目錄下的redis.conf)，可以看到如下配置信息：
其中save 900 1的含義是：當(dāng)時(shí)間到900秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少1次變化，則執(zhí)行bgsave；save 300 10和save 60 10000同理。當(dāng)三個(gè)save條件滿(mǎn)足任意一個(gè)時(shí)，都會(huì)引起bgsave的調(diào)用。
save m n的實(shí)現(xiàn)原理
Redis的save m n，是通過(guò)serverCron函數(shù)、dirty計(jì)數(shù)器、和lastsave時(shí)間戳來(lái)實(shí)現(xiàn)的。
serverCron是Redis服務(wù)器的周期性操作函數(shù)，默認(rèn)每隔100ms執(zhí)行一次；該函數(shù)對(duì)服務(wù)器的狀態(tài)進(jìn)行維護(hù)，其中一項(xiàng)工作就是檢查 save m n 配置的條件是否滿(mǎn)足，如果滿(mǎn)足就執(zhí)行bgsave。
dirty計(jì)數(shù)器是Redis服務(wù)器維持的一個(gè)狀態(tài)，記錄了上一次執(zhí)行bgsave/save命令后，服務(wù)器狀態(tài)進(jìn)行了多少次修改(包括增刪改)；而當(dāng)save/bgsave執(zhí)行完成后，會(huì)將dirty重新置為0。
例如，如果Redis執(zhí)行了set mykey helloworld，則dirty值會(huì)+1；如果執(zhí)行了sadd myset v1 v2 v3，則dirty值會(huì)+3；注意dirty記錄的是服務(wù)器進(jìn)行了多少次修改，而不是客戶(hù)端執(zhí)行了多少修改數(shù)據(jù)的命令。
lastsave時(shí)間戳也是Redis服務(wù)器維持的一個(gè)狀態(tài)，記錄的是上一次成功執(zhí)行save/bgsave的時(shí)間。
save m n的原理如下：每隔100ms，執(zhí)行serverCron函數(shù)；在serverCron函數(shù)中，遍歷save m n配置的保存條件，只要有一個(gè)條件滿(mǎn)足，就進(jìn)行bgsave。對(duì)于每一個(gè)save m n條件，只有下面兩條同時(shí)滿(mǎn)足時(shí)才算滿(mǎn)足：
(1)當(dāng)前時(shí)間-lastsave > m
(2)dirty >= n
save m n 執(zhí)行日志
下圖是save m n觸發(fā)bgsave執(zhí)行時(shí)，服務(wù)器打印日志的情況：
其他自動(dòng)觸發(fā)機(jī)制
除了save m n 以外，還有一些其他情況會(huì)觸發(fā)bgsave：
- 在主從復(fù)制場(chǎng)景下，如果從節(jié)點(diǎn)執(zhí)行全量復(fù)制操作，則主節(jié)點(diǎn)會(huì)執(zhí)行bgsave命令，并將rdb文件發(fā)送給從節(jié)點(diǎn)
- 執(zhí)行shutdown命令時(shí)，自動(dòng)執(zhí)行rdb持久化，如下圖所示：
2. 執(zhí)行流程
前面介紹了觸發(fā)bgsave的條件，下面將說(shuō)明bgsave命令的執(zhí)行流程，如下圖所示(圖片來(lái)源：https://blog.csdn.net/a1007720052/article/details/79126253)：
圖片中的5個(gè)步驟所進(jìn)行的操作如下：
1) Redis父進(jìn)程首先判斷：當(dāng)前是否在執(zhí)行save，或bgsave/bgrewriteaof(后面會(huì)詳細(xì)介紹該命令)的子進(jìn)程，如果在執(zhí)行則bgsave命令直接返回。bgsave/bgrewriteaof 的子進(jìn)程不能同時(shí)執(zhí)行，主要是基于性能方面的考慮：兩個(gè)并發(fā)的子進(jìn)程同時(shí)執(zhí)行大量的磁盤(pán)寫(xiě)操作，可能引起嚴(yán)重的性能問(wèn)題。
2) 父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，這個(gè)過(guò)程中父進(jìn)程是阻塞的，Redis不能執(zhí)行來(lái)自客戶(hù)端的任何命令
3) 父進(jìn)程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父進(jìn)程，并可以響應(yīng)其他命令
4) 子進(jìn)程創(chuàng)建RDB文件，根據(jù)父進(jìn)程內(nèi)存快照生成臨時(shí)快照文件，完成后對(duì)原有文件進(jìn)行原子替換
5) 子進(jìn)程發(fā)送信號(hào)給父進(jìn)程表示完成，父進(jìn)程更新統(tǒng)計(jì)信息
3. RDB文件
RDB文件是經(jīng)過(guò)壓縮的二進(jìn)制文件，下面介紹關(guān)于RDB文件的一些細(xì)節(jié)。
存儲(chǔ)路徑
RDB文件的存儲(chǔ)路徑既可以在啟動(dòng)前配置，也可以通過(guò)命令動(dòng)態(tài)設(shè)定。
配置：dir配置指定目錄，dbfilename指定文件名。默認(rèn)是Redis根目錄下的dump.rdb文件。
動(dòng)態(tài)設(shè)定：Redis啟動(dòng)后也可以動(dòng)態(tài)修改RDB存儲(chǔ)路徑，在磁盤(pán)損害或空間不足時(shí)非常有用；執(zhí)行命令為config set dir {newdir}和config set dbfilename {newFileName}。如下所示(Windows環(huán)境)：
RDB文件格式
RDB文件格式如下圖所示(圖片來(lái)源：《Redis設(shè)計(jì)與實(shí)現(xiàn)》)：
其中各個(gè)字段的含義說(shuō)明如下：
1) REDIS：常量，保存著”REDIS”5個(gè)字符。
2) db_version：RDB文件的版本號(hào)，注意不是Redis的版本號(hào)。
3) SELECTDB 0 pairs：表示一個(gè)完整的數(shù)據(jù)庫(kù)(0號(hào)數(shù)據(jù)庫(kù))，同理SELECTDB 3 pairs表示完整的3號(hào)數(shù)據(jù)庫(kù)；只有當(dāng)數(shù)據(jù)庫(kù)中有鍵值對(duì)時(shí)，RDB文件中才會(huì)有該數(shù)據(jù)庫(kù)的信息(上圖所示的Redis中只有0號(hào)和3號(hào)數(shù)據(jù)庫(kù)有鍵值對(duì))；如果Redis中所有的數(shù)據(jù)庫(kù)都沒(méi)有鍵值對(duì)，則這一部分直接省略。其中：SELECTDB是一個(gè)常量，代表后面跟著的是數(shù)據(jù)庫(kù)號(hào)碼；0和3是數(shù)據(jù)庫(kù)號(hào)碼；pairs則存儲(chǔ)了具體的鍵值對(duì)信息，包括key、value值，及其數(shù)據(jù)類(lèi)型、內(nèi)部編碼、過(guò)期時(shí)間、壓縮信息等等。
4) EOF：常量，標(biāo)志RDB文件正文內(nèi)容結(jié)束。
5) check_sum：前面所有內(nèi)容的校驗(yàn)和；Redis在載入RBD文件時(shí)，會(huì)計(jì)算前面的校驗(yàn)和并與check_sum值比較，判斷文件是否損壞。
壓縮
Redis默認(rèn)采用LZF算法對(duì)RDB文件進(jìn)行壓縮。雖然壓縮耗時(shí)，但是可以大大減小RDB文件的體積，因此壓縮默認(rèn)開(kāi)啟；可以通過(guò)命令關(guān)閉：
需要注意的是，RDB文件的壓縮并不是針對(duì)整個(gè)文件進(jìn)行的，而是對(duì)數(shù)據(jù)庫(kù)中的字符串進(jìn)行的，且只有在字符串達(dá)到一定長(zhǎng)度(20字節(jié))時(shí)才會(huì)進(jìn)行。
4. 啟動(dòng)時(shí)加載
RDB文件的載入工作是在服務(wù)器啟動(dòng)時(shí)自動(dòng)執(zhí)行的，并沒(méi)有專(zhuān)門(mén)的命令。但是由于AOF的優(yōu)先級(jí)更高，因此當(dāng)AOF開(kāi)啟時(shí)，Redis會(huì)優(yōu)先載入AOF文件來(lái)恢復(fù)數(shù)據(jù)；只有當(dāng)AOF關(guān)閉時(shí)，才會(huì)在Redis服務(wù)器啟動(dòng)時(shí)檢測(cè)RDB文件，并自動(dòng)載入。服務(wù)器載入RDB文件期間處于阻塞狀態(tài)，直到載入完成為止。
Redis啟動(dòng)日志中可以看到自動(dòng)載入的執(zhí)行：
Redis載入RDB文件時(shí)，會(huì)對(duì)RDB文件進(jìn)行校驗(yàn)，如果文件損壞，則日志中會(huì)打印錯(cuò)誤，Redis啟動(dòng)失敗。
5. RDB常用配置總結(jié)
下面是RDB常用的配置項(xiàng)，以及默認(rèn)值；前面介紹過(guò)的這里不再詳細(xì)介紹。
- save m n：bgsave自動(dòng)觸發(fā)的條件；如果沒(méi)有save m n配置，相當(dāng)于自動(dòng)的RDB持久化關(guān)閉，不過(guò)此時(shí)仍可以通過(guò)其他方式觸發(fā)
- stop-writes-on-bgsave-error yes：當(dāng)bgsave出現(xiàn)錯(cuò)誤時(shí)，Redis是否停止執(zhí)行寫(xiě)命令；設(shè)置為yes，則當(dāng)硬盤(pán)出現(xiàn)問(wèn)題時(shí)，可以及時(shí)發(fā)現(xiàn)，避免數(shù)據(jù)的大量丟失；設(shè)置為no，則Redis無(wú)視bgsave的錯(cuò)誤繼續(xù)執(zhí)行寫(xiě)命令，當(dāng)對(duì)Redis服務(wù)器的系統(tǒng)(尤其是硬盤(pán))使用了監(jiān)控時(shí)，該選項(xiàng)考慮設(shè)置為no
- rdbcompression yes：是否開(kāi)啟RDB文件壓縮
- rdbchecksum yes：是否開(kāi)啟RDB文件的校驗(yàn)，在寫(xiě)入文件和讀取文件時(shí)都起作用；關(guān)閉checksum在寫(xiě)入文件和啟動(dòng)文件時(shí)大約能帶來(lái)10%的性能提升，但是數(shù)據(jù)損壞時(shí)無(wú)法發(fā)現(xiàn)
- dbfilename dump.rdb：RDB文件名
- dir ./：RDB文件和AOF文件所在目錄
四、AOF持久化
RDB持久化是將進(jìn)程數(shù)據(jù)寫(xiě)入文件，而AOF持久化(即Append Only File持久化)，則是將Redis執(zhí)行的每次寫(xiě)命令記錄到單獨(dú)的日志文件中(有點(diǎn)像MySQL的binlog)；當(dāng)Redis重啟時(shí)再次執(zhí)行AOF文件中的命令來(lái)恢復(fù)數(shù)據(jù)。
與RDB相比，AOF的實(shí)時(shí)性更好，因此已成為主流的持久化方案。
1. 開(kāi)啟AOF
Redis服務(wù)器默認(rèn)開(kāi)啟RDB，關(guān)閉AOF；要開(kāi)啟AOF，需要在配置文件中配置：
appendonly yes
2. 執(zhí)行流程
由于需要記錄Redis的每條寫(xiě)命令，因此AOF不需要觸發(fā)，下面介紹AOF的執(zhí)行流程。
AOF的執(zhí)行流程包括：
- 命令追加(append)：將Redis的寫(xiě)命令追加到緩沖區(qū)aof_buf；
- 文件寫(xiě)入(write)和文件同步(sync)：根據(jù)不同的同步策略將aof_buf中的內(nèi)容同步到硬盤(pán)；
- 文件重寫(xiě)(rewrite)：定期重寫(xiě)AOF文件，達(dá)到壓縮的目的。
1) 命令追加(append)
Redis先將寫(xiě)命令追加到緩沖區(qū)，而不是直接寫(xiě)入文件，主要是為了避免每次有寫(xiě)命令都直接寫(xiě)入硬盤(pán)，導(dǎo)致硬盤(pán)IO成為Redis負(fù)載的瓶頸。
命令追加的格式是Redis命令請(qǐng)求的協(xié)議格式，它是一種純文本格式，具有兼容性好、可讀性強(qiáng)、容易處理、操作簡(jiǎn)單避免二次開(kāi)銷(xiāo)等優(yōu)點(diǎn)；具體格式略。在AOF文件中，除了用于指定數(shù)據(jù)庫(kù)的select命令(如select 0 為選中0號(hào)數(shù)據(jù)庫(kù))是由Redis添加的，其他都是客戶(hù)端發(fā)送來(lái)的寫(xiě)命令。
2) 文件寫(xiě)入(write)和文件同步(sync)
Redis提供了多種AOF緩存區(qū)的同步文件策略，策略涉及到操作系統(tǒng)的write函數(shù)和fsync函數(shù)，說(shuō)明如下：
為了提高文件寫(xiě)入效率，在現(xiàn)代操作系統(tǒng)中，當(dāng)用戶(hù)調(diào)用write函數(shù)將數(shù)據(jù)寫(xiě)入文件時(shí)，操作系統(tǒng)通常會(huì)將數(shù)據(jù)暫存到一個(gè)內(nèi)存緩沖區(qū)里，當(dāng)緩沖區(qū)被填滿(mǎn)或超過(guò)了指定時(shí)限后，才真正將緩沖區(qū)的數(shù)據(jù)寫(xiě)入到硬盤(pán)里。這樣的操作雖然提高了效率，但也帶來(lái)了安全問(wèn)題：如果計(jì)算機(jī)停機(jī)，內(nèi)存緩沖區(qū)中的數(shù)據(jù)會(huì)丟失；因此系統(tǒng)同時(shí)提供了fsync、fdatasync等同步函數(shù)，可以強(qiáng)制操作系統(tǒng)立刻將緩沖區(qū)中的數(shù)據(jù)寫(xiě)入到硬盤(pán)里，從而確保數(shù)據(jù)的安全性。
AOF緩存區(qū)的同步文件策略由參數(shù)appendfsync控制，各個(gè)值的含義如下：
- always：命令寫(xiě)入aof_buf后立即調(diào)用系統(tǒng)fsync操作同步到AOF文件，fsync完成后線(xiàn)程返回。這種情況下，每次有寫(xiě)命令都要同步到AOF文件，硬盤(pán)IO成為性能瓶頸，Redis只能支持大約幾百TPS寫(xiě)入，嚴(yán)重降低了Redis的性能；即便是使用固態(tài)硬盤(pán)(SSD)，每秒大約也只能處理幾萬(wàn)個(gè)命令，而且會(huì)大大降低SSD的壽命。
- no：命令寫(xiě)入aof_buf后調(diào)用系統(tǒng)write操作，不對(duì)AOF文件做fsync同步；同步由操作系統(tǒng)負(fù)責(zé)，通常同步周期為30秒。這種情況下，文件同步的時(shí)間不可控，且緩沖區(qū)中堆積的數(shù)據(jù)會(huì)很多，數(shù)據(jù)安全性無(wú)法保證。
- everysec：命令寫(xiě)入aof_buf后調(diào)用系統(tǒng)write操作，write完成后線(xiàn)程返回；fsync同步文件操作由專(zhuān)門(mén)的線(xiàn)程每秒調(diào)用一次。everysec是前述兩種策略的折中，是性能和數(shù)據(jù)安全性的平衡，因此是Redis的默認(rèn)配置，也是我們推薦的配置。
3) 文件重寫(xiě)(rewrite)
隨著時(shí)間流逝，Redis服務(wù)器執(zhí)行的寫(xiě)命令越來(lái)越多，AOF文件也會(huì)越來(lái)越大；過(guò)大的AOF文件不僅會(huì)影響服務(wù)器的正常運(yùn)行，也會(huì)導(dǎo)致數(shù)據(jù)恢復(fù)需要的時(shí)間過(guò)長(zhǎng)。
文件重寫(xiě)是指定期重寫(xiě)AOF文件，減小AOF文件的體積。需要注意的是，AOF重寫(xiě)是把Redis進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫(xiě)命令，同步到新的AOF文件；不會(huì)對(duì)舊的AOF文件進(jìn)行任何讀取、寫(xiě)入操作!
關(guān)于文件重寫(xiě)需要注意的另一點(diǎn)是：對(duì)于AOF持久化來(lái)說(shuō)，文件重寫(xiě)雖然是強(qiáng)烈推薦的，但并不是必須的；即使沒(méi)有文件重寫(xiě)，數(shù)據(jù)也可以被持久化并在Redis啟動(dòng)的時(shí)候?qū)?#xff1b;因此在一些實(shí)現(xiàn)中，會(huì)關(guān)閉自動(dòng)的文件重寫(xiě)，然后通過(guò)定時(shí)任務(wù)在每天的某一時(shí)刻定時(shí)執(zhí)行。
文件重寫(xiě)之所以能夠壓縮AOF文件，原因在于：
- 過(guò)期的數(shù)據(jù)不再寫(xiě)入文件
- 無(wú)效的命令不再寫(xiě)入文件：如有些數(shù)據(jù)被重復(fù)設(shè)值(set mykey v1, set mykey v2)、有些數(shù)據(jù)被刪除了(sadd myset v1, del myset)等等
- 多條命令可以合并為一個(gè)：如sadd myset v1, sadd myset v2, sadd myset v3可以合并為sadd myset v1 v2 v3。不過(guò)為了防止單條命令過(guò)大造成客戶(hù)端緩沖區(qū)溢出，對(duì)于list、set、hash、zset類(lèi)型的key，并不一定只使用一條命令；而是以某個(gè)常量為界將命令拆分為多條。這個(gè)常量在redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD中定義，不可更改，3.0版本中值是64。
通過(guò)上述內(nèi)容可以看出，由于重寫(xiě)后AOF執(zhí)行的命令減少了，文件重寫(xiě)既可以減少文件占用的空間，也可以加快恢復(fù)速度。
文件重寫(xiě)的觸發(fā)
文件重寫(xiě)的觸發(fā)，分為手動(dòng)觸發(fā)和自動(dòng)觸發(fā)：
手動(dòng)觸發(fā)：直接調(diào)用bgrewriteaof命令，該命令的執(zhí)行與bgsave有些類(lèi)似：都是fork子進(jìn)程進(jìn)行具體的工作，且都只有在fork時(shí)阻塞。
此時(shí)服務(wù)器執(zhí)行日志如下：
自動(dòng)觸發(fā)：根據(jù)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數(shù)，以及aof_current_size和aof_base_size狀態(tài)確定觸發(fā)時(shí)機(jī)。
- auto-aof-rewrite-min-size：執(zhí)行AOF重寫(xiě)時(shí)，文件的最小體積，默認(rèn)值為64MB。
- auto-aof-rewrite-percentage：執(zhí)行AOF重寫(xiě)時(shí)，當(dāng)前AOF大小(即aof_current_size)和上一次重寫(xiě)時(shí)AOF大小(aof_base_size)的比值。
其中，參數(shù)可以通過(guò)config get命令查看：
狀態(tài)可以通過(guò)info persistence查看：
只有當(dāng)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個(gè)參數(shù)同時(shí)滿(mǎn)足時(shí)，才會(huì)自動(dòng)觸發(fā)AOF重寫(xiě)，即bgrewriteaof操作。
自動(dòng)觸發(fā)bgrewriteaof時(shí)，可以看到服務(wù)器日志如下：
文件重寫(xiě)的流程
文件重寫(xiě)流程如下圖所示(圖片來(lái)源：http://www.cnblogs.com/yangmingxianshen/p/8373205.html)：
關(guān)于文件重寫(xiě)的流程，有兩點(diǎn)需要特別注意：(1)重寫(xiě)由父進(jìn)程fork子進(jìn)程進(jìn)行；(2)重寫(xiě)期間Redis執(zhí)行的寫(xiě)命令，需要追加到新的AOF文件中，為此Redis引入了aof_rewrite_buf緩存。
對(duì)照上圖，文件重寫(xiě)的流程如下：
1) Redis父進(jìn)程首先判斷當(dāng)前是否存在正在執(zhí)行 bgsave/bgrewriteaof的子進(jìn)程，如果存在則bgrewriteaof命令直接返回，如果存在bgsave命令則等bgsave執(zhí)行完成后再執(zhí)行。前面曾介紹過(guò)，這個(gè)主要是基于性能方面的考慮。
2) 父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，這個(gè)過(guò)程中父進(jìn)程是阻塞的。
3.1) 父進(jìn)程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父進(jìn)程，并可以響應(yīng)其他命令。Redis的所有寫(xiě)命令依然寫(xiě)入AOF緩沖區(qū)，并根據(jù)appendfsync策略同步到硬盤(pán)，保證原有AOF機(jī)制的正確。
3.2) 由于fork操作使用寫(xiě)時(shí)復(fù)制技術(shù)，子進(jìn)程只能共享fork操作時(shí)的內(nèi)存數(shù)據(jù)。由于父進(jìn)程依然在響應(yīng)命令，因此Redis使用AOF重寫(xiě)緩沖區(qū)(圖中的aof_rewrite_buf)保存這部分?jǐn)?shù)據(jù)，防止新AOF文件生成期間丟失這部分?jǐn)?shù)據(jù)。也就是說(shuō)，bgrewriteaof執(zhí)行期間，Redis的寫(xiě)命令同時(shí)追加到aof_buf和aof_rewirte_buf兩個(gè)緩沖區(qū)。
4) 子進(jìn)程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫(xiě)入到新的AOF文件。
5.1) 子進(jìn)程寫(xiě)完新的AOF文件后，向父進(jìn)程發(fā)信號(hào)，父進(jìn)程更新統(tǒng)計(jì)信息，具體可以通過(guò)info persistence查看。
5.2) 父進(jìn)程把AOF重寫(xiě)緩沖區(qū)的數(shù)據(jù)寫(xiě)入到新的AOF文件，這樣就保證了新AOF文件所保存的數(shù)據(jù)庫(kù)狀態(tài)和服務(wù)器當(dāng)前狀態(tài)一致。
5.3) 使用新的AOF文件替換老文件，完成AOF重寫(xiě)。
3. 啟動(dòng)時(shí)加載
前面提到過(guò)，當(dāng)AOF開(kāi)啟時(shí)，Redis啟動(dòng)時(shí)會(huì)優(yōu)先載入AOF文件來(lái)恢復(fù)數(shù)據(jù)；只有當(dāng)AOF關(guān)閉時(shí)，才會(huì)載入RDB文件恢復(fù)數(shù)據(jù)。
當(dāng)AOF開(kāi)啟，且AOF文件存在時(shí)，Redis啟動(dòng)日志：
當(dāng)AOF開(kāi)啟，但AOF文件不存在時(shí)，即使RDB文件存在也不會(huì)加載(更早的一些版本可能會(huì)加載，但3.0不會(huì))，Redis啟動(dòng)日志如下：
文件校驗(yàn)
與載入RDB文件類(lèi)似，Redis載入AOF文件時(shí)，會(huì)對(duì)AOF文件進(jìn)行校驗(yàn)，如果文件損壞，則日志中會(huì)打印錯(cuò)誤，Redis啟動(dòng)失敗。但如果是AOF文件結(jié)尾不完整(機(jī)器突然宕機(jī)等容易導(dǎo)致文件尾部不完整)，且aof-load-truncated參數(shù)開(kāi)啟，則日志中會(huì)輸出警告，Redis忽略掉AOF文件的尾部，啟動(dòng)成功。aof-load-truncated參數(shù)默認(rèn)是開(kāi)啟的：
偽客戶(hù)端
因?yàn)镽edis的命令只能在客戶(hù)端上下文中執(zhí)行，而載入AOF文件時(shí)命令是直接從文件中讀取的，并不是由客戶(hù)端發(fā)送；因此Redis服務(wù)器在載入AOF文件之前，會(huì)創(chuàng)建一個(gè)沒(méi)有網(wǎng)絡(luò)連接的客戶(hù)端，之后用它來(lái)執(zhí)行AOF文件中的命令，命令執(zhí)行的效果與帶網(wǎng)絡(luò)連接的客戶(hù)端完全一樣。
4. AOF常用配置總結(jié)
下面是AOF常用的配置項(xiàng)，以及默認(rèn)值；前面介紹過(guò)的這里不再詳細(xì)介紹。
- appendonly no：是否開(kāi)啟AOF
- appendfilename "appendonly.aof"：AOF文件名
- dir ./：RDB文件和AOF文件所在目錄
- appendfsync everysec：fsync持久化策略
- no-appendfsync-on-rewrite no：AOF重寫(xiě)期間是否禁止fsync；如果開(kāi)啟該選項(xiàng)，可以減輕文件重寫(xiě)時(shí)CPU和硬盤(pán)的負(fù)載(尤其是硬盤(pán))，但是可能會(huì)丟失AOF重寫(xiě)期間的數(shù)據(jù)；需要在負(fù)載和安全性之間進(jìn)行平衡
- auto-aof-rewrite-percentage 100：文件重寫(xiě)觸發(fā)條件之一
- auto-aof-rewrite-min-size 64mb：文件重寫(xiě)觸發(fā)提交之一
- aof-load-truncated yes：如果AOF文件結(jié)尾損壞，Redis啟動(dòng)時(shí)是否仍載入AOF文件
五、方案選擇與常見(jiàn)問(wèn)題
前面介紹了RDB和AOF兩種持久化方案的細(xì)節(jié)，下面介紹RDB和AOF的特點(diǎn)、如何選擇持久化方案，以及在持久化過(guò)程中常遇到的問(wèn)題等。
1. RDB和AOF的優(yōu)缺點(diǎn)
RDB和AOF各有優(yōu)缺點(diǎn)：
RDB持久化
優(yōu)點(diǎn)：RDB文件緊湊，體積小，網(wǎng)絡(luò)傳輸快，適合全量復(fù)制；恢復(fù)速度比AOF快很多。當(dāng)然，與AOF相比，RDB最重要的優(yōu)點(diǎn)之一是對(duì)性能的影響相對(duì)較小。
缺點(diǎn)：RDB文件的致命缺點(diǎn)在于其數(shù)據(jù)快照的持久化方式?jīng)Q定了必然做不到實(shí)時(shí)持久化，而在數(shù)據(jù)越來(lái)越重要的今天，數(shù)據(jù)的大量丟失很多時(shí)候是無(wú)法接受的，因此AOF持久化成為主流。此外，RDB文件需要滿(mǎn)足特定格式，兼容性差(如老版本的Redis不兼容新版本的RDB文件)。
AOF持久化
與RDB持久化相對(duì)應(yīng)，AOF的優(yōu)點(diǎn)在于支持秒級(jí)持久化、兼容性好，缺點(diǎn)是文件大、恢復(fù)速度慢、對(duì)性能影響大。
2. 持久化策略選擇
在介紹持久化策略之前，首先要明白無(wú)論是RDB還是AOF，持久化的開(kāi)啟都是要付出性能方面代價(jià)的：對(duì)于RDB持久化，一方面是bgsave在進(jìn)行fork操作時(shí)Redis主進(jìn)程會(huì)阻塞，另一方面，子進(jìn)程向硬盤(pán)寫(xiě)數(shù)據(jù)也會(huì)帶來(lái)IO壓力；對(duì)于AOF持久化，向硬盤(pán)寫(xiě)數(shù)據(jù)的頻率大大提高(everysec策略下為秒級(jí))，IO壓力更大，甚至可能造成AOF追加阻塞問(wèn)題(后面會(huì)詳細(xì)介紹這種阻塞)，此外，AOF文件的重寫(xiě)與RDB的bgsave類(lèi)似，會(huì)有fork時(shí)的阻塞和子進(jìn)程的IO壓力問(wèn)題。相對(duì)來(lái)說(shuō)，由于AOF向硬盤(pán)中寫(xiě)數(shù)據(jù)的頻率更高，因此對(duì)Redis主進(jìn)程性能的影響會(huì)更大。
在實(shí)際生產(chǎn)環(huán)境中，根據(jù)數(shù)據(jù)量、應(yīng)用對(duì)數(shù)據(jù)的安全要求、預(yù)算限制等不同情況，會(huì)有各種各樣的持久化策略；如完全不使用任何持久化、使用RDB或AOF的一種，或同時(shí)開(kāi)啟RDB和AOF持久化等。此外，持久化的選擇必須與Redis的主從策略一起考慮，因?yàn)橹鲝膹?fù)制與持久化同樣具有數(shù)據(jù)備份的功能，而且主機(jī)master和從機(jī)slave可以獨(dú)立的選擇持久化方案。
下面分場(chǎng)景來(lái)討論持久化策略的選擇，下面的討論也只是作為參考，實(shí)際方案可能更復(fù)雜更具多樣性。
(1)如果Redis中的數(shù)據(jù)完全丟棄也沒(méi)有關(guān)系(如Redis完全用作DB層數(shù)據(jù)的cache)，那么無(wú)論是單機(jī)，還是主從架構(gòu)，都可以不進(jìn)行任何持久化。
(2)在單機(jī)環(huán)境下(對(duì)于個(gè)人開(kāi)發(fā)者，這種情況可能比較常見(jiàn))，如果可以接受十幾分鐘或更多的數(shù)據(jù)丟失，選擇RDB對(duì)Redis的性能更加有利；如果只能接受秒級(jí)別的數(shù)據(jù)丟失，應(yīng)該選擇AOF。
(3)但在多數(shù)情況下，我們都會(huì)配置主從環(huán)境，slave的存在既可以實(shí)現(xiàn)數(shù)據(jù)的熱備，也可以進(jìn)行讀寫(xiě)分離分擔(dān)Redis讀請(qǐng)求，以及在master宕掉后繼續(xù)提供服務(wù)。
在這種情況下，一種可行的做法是：
master：完全關(guān)閉持久化(包括RDB和AOF)，這樣可以讓master的性能達(dá)到最好
slave：關(guān)閉RDB，開(kāi)啟AOF(如果對(duì)數(shù)據(jù)安全要求不高，開(kāi)啟RDB關(guān)閉AOF也可以)，并定時(shí)對(duì)持久化文件進(jìn)行備份(如備份到其他文件夾，并標(biāo)記好備份的時(shí)間)；然后關(guān)閉AOF的自動(dòng)重寫(xiě)，然后添加定時(shí)任務(wù)，在每天Redis閑時(shí)(如凌晨12點(diǎn))調(diào)用bgrewriteaof。
這里需要解釋一下，為什么開(kāi)啟了主從復(fù)制，可以實(shí)現(xiàn)數(shù)據(jù)的熱備份，還需要設(shè)置持久化呢？因?yàn)樵谝恍┨厥馇闆r下，主從復(fù)制仍然不足以保證數(shù)據(jù)的安全，例如：
- master和slave進(jìn)程同時(shí)停止：考慮這樣一種場(chǎng)景，如果master和slave在同一棟大樓或同一個(gè)機(jī)房，則一次停電事故就可能導(dǎo)致master和slave機(jī)器同時(shí)關(guān)機(jī)，Redis進(jìn)程停止；如果沒(méi)有持久化，則面臨的是數(shù)據(jù)的完全丟失。
- master誤重啟：考慮這樣一種場(chǎng)景，master服務(wù)因?yàn)楣收襄吹袅?#xff0c;如果系統(tǒng)中有自動(dòng)拉起機(jī)制(即檢測(cè)到服務(wù)停止后重啟該服務(wù))將master自動(dòng)重啟，由于沒(méi)有持久化文件，那么master重啟后數(shù)據(jù)是空的，slave同步數(shù)據(jù)也變成了空的；如果master和slave都沒(méi)有持久化，同樣會(huì)面臨數(shù)據(jù)的完全丟失。需要注意的是，即便是使用了哨兵(關(guān)于哨兵后面會(huì)有文章介紹)進(jìn)行自動(dòng)的主從切換，也有可能在哨兵輪詢(xún)到master之前，便被自動(dòng)拉起機(jī)制重啟了。因此，應(yīng)盡量避免“自動(dòng)拉起機(jī)制”和“不做持久化”同時(shí)出現(xiàn)。
(4)異地災(zāi)備：上述討論的幾種持久化策略，針對(duì)的都是一般的系統(tǒng)故障，如進(jìn)程異常退出、宕機(jī)、斷電等，這些故障不會(huì)損壞硬盤(pán)。但是對(duì)于一些可能導(dǎo)致硬盤(pán)損壞的災(zāi)難情況，如火災(zāi)地震，就需要進(jìn)行異地災(zāi)備。例如對(duì)于單機(jī)的情形，可以定時(shí)將RDB文件或重寫(xiě)后的AOF文件，通過(guò)scp拷貝到遠(yuǎn)程機(jī)器，如阿里云、AWS等；對(duì)于主從的情形，可以定時(shí)在master上執(zhí)行bgsave，然后將RDB文件拷貝到遠(yuǎn)程機(jī)器，或者在slave上執(zhí)行bgrewriteaof重寫(xiě)AOF文件后，將AOF文件拷貝到遠(yuǎn)程機(jī)器上。一般來(lái)說(shuō)，由于RDB文件文件小、恢復(fù)快，因此災(zāi)難恢復(fù)常用RDB文件；異地備份的頻率根據(jù)數(shù)據(jù)安全性的需要及其他條件來(lái)確定，但最好不要低于一天一次。
3. fork阻塞：CPU的阻塞
在Redis的實(shí)踐中，眾多因素限制了Redis單機(jī)的內(nèi)存不能過(guò)大，例如：
- 當(dāng)面對(duì)請(qǐng)求的暴增，需要從庫(kù)擴(kuò)容時(shí)，Redis內(nèi)存過(guò)大會(huì)導(dǎo)致擴(kuò)容時(shí)間太長(zhǎng)；
- 當(dāng)主機(jī)宕機(jī)時(shí)，切換主機(jī)后需要掛載從庫(kù)，Redis內(nèi)存過(guò)大導(dǎo)致掛載速度過(guò)慢；
- 以及持久化過(guò)程中的fork操作，下面詳細(xì)說(shuō)明。
首先說(shuō)明一下fork操作：
父進(jìn)程通過(guò)fork操作可以創(chuàng)建子進(jìn)程；子進(jìn)程創(chuàng)建后，父子進(jìn)程共享代碼段，不共享進(jìn)程的數(shù)據(jù)空間，但是子進(jìn)程會(huì)獲得父進(jìn)程的數(shù)據(jù)空間的副本。在操作系統(tǒng)fork的實(shí)際實(shí)現(xiàn)中，基本都采用了寫(xiě)時(shí)復(fù)制技術(shù)，即在父/子進(jìn)程試圖修改數(shù)據(jù)空間之前，父子進(jìn)程實(shí)際上共享數(shù)據(jù)空間；但是當(dāng)父/子進(jìn)程的任何一個(gè)試圖修改數(shù)據(jù)空間時(shí)，操作系統(tǒng)會(huì)為修改的那一部分(內(nèi)存的一頁(yè))制作一個(gè)副本。
雖然fork時(shí)，子進(jìn)程不會(huì)復(fù)制父進(jìn)程的數(shù)據(jù)空間，但是會(huì)復(fù)制內(nèi)存頁(yè)表(頁(yè)表相當(dāng)于內(nèi)存的索引、目錄)；父進(jìn)程的數(shù)據(jù)空間越大，內(nèi)存頁(yè)表越大，fork時(shí)復(fù)制耗時(shí)也會(huì)越多。
在Redis中，無(wú)論是RDB持久化的bgsave，還是AOF重寫(xiě)的bgrewriteaof，都需要fork出子進(jìn)程來(lái)進(jìn)行操作。如果Redis內(nèi)存過(guò)大，會(huì)導(dǎo)致fork操作時(shí)復(fù)制內(nèi)存頁(yè)表耗時(shí)過(guò)多；而Redis主進(jìn)程在進(jìn)行fork時(shí)，是完全阻塞的，也就意味著無(wú)法響應(yīng)客戶(hù)端的請(qǐng)求，會(huì)造成請(qǐng)求延遲過(guò)大。
對(duì)于不同的硬件、不同的操作系統(tǒng)，fork操作的耗時(shí)會(huì)有所差別，一般來(lái)說(shuō)，如果Redis單機(jī)內(nèi)存達(dá)到了10GB，fork時(shí)耗時(shí)可能會(huì)達(dá)到百毫秒級(jí)別(如果使用Xen虛擬機(jī)，這個(gè)耗時(shí)可能達(dá)到秒級(jí)別)。因此，一般來(lái)說(shuō)Redis單機(jī)內(nèi)存一般要限制在10GB以?xún)?nèi)；不過(guò)這個(gè)數(shù)據(jù)并不是絕對(duì)的，可以通過(guò)觀察線(xiàn)上環(huán)境fork的耗時(shí)來(lái)進(jìn)行調(diào)整。觀察的方法如下：執(zhí)行命令info stats，查看latest_fork_usec的值，單位為微秒。
為了減輕fork操作帶來(lái)的阻塞問(wèn)題，除了控制Redis單機(jī)內(nèi)存的大小以外，還可以適度放寬AOF重寫(xiě)的觸發(fā)條件、選用物理機(jī)或高效支持fork操作的虛擬化技術(shù)等，例如使用Vmware或KVM虛擬機(jī)，不要使用Xen虛擬機(jī)。
4. AOF追加阻塞：硬盤(pán)的阻塞
前面提到過(guò)，在AOF中，如果AOF緩沖區(qū)的文件同步策略為everysec，則：在主線(xiàn)程中，命令寫(xiě)入aof_buf后調(diào)用系統(tǒng)write操作，write完成后主線(xiàn)程返回；fsync同步文件操作由專(zhuān)門(mén)的文件同步線(xiàn)程每秒調(diào)用一次。
這種做法的問(wèn)題在于，如果硬盤(pán)負(fù)載過(guò)高，那么fsync操作可能會(huì)超過(guò)1s；如果Redis主線(xiàn)程持續(xù)高速向aof_buf寫(xiě)入命令，硬盤(pán)的負(fù)載可能會(huì)越來(lái)越大，IO資源消耗更快；如果此時(shí)Redis進(jìn)程異常退出，丟失的數(shù)據(jù)也會(huì)越來(lái)越多，可能遠(yuǎn)超過(guò)1s。
為此，Redis的處理策略是這樣的：主線(xiàn)程每次進(jìn)行AOF會(huì)對(duì)比上次fsync成功的時(shí)間；如果距上次不到2s，主線(xiàn)程直接返回；如果超過(guò)2s，則主線(xiàn)程阻塞直到fsync同步完成。因此，如果系統(tǒng)硬盤(pán)負(fù)載過(guò)大導(dǎo)致fsync速度太慢，會(huì)導(dǎo)致Redis主線(xiàn)程的阻塞；此外，使用everysec配置，AOF最多可能丟失2s的數(shù)據(jù)，而不是1s。
AOF追加阻塞問(wèn)題定位的方法：
(1)監(jiān)控info Persistence中的aof_delayed_fsync：當(dāng)AOF追加阻塞發(fā)生時(shí)(即主線(xiàn)程等待fsync而阻塞)，該指標(biāo)累加。
(2)AOF阻塞時(shí)的Redis日志：
Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
(3)如果AOF追加阻塞頻繁發(fā)生，說(shuō)明系統(tǒng)的硬盤(pán)負(fù)載太大；可以考慮更換IO速度更快的硬盤(pán)，或者通過(guò)IO監(jiān)控分析工具對(duì)系統(tǒng)的IO負(fù)載進(jìn)行分析，如iostat(系統(tǒng)級(jí)io)、iotop(io版的top)、pidstat等。
5. info命令與持久化
前面提到了一些通過(guò)info命令查看持久化相關(guān)狀態(tài)的方法，下面來(lái)總結(jié)一下。
(1)info Persistence
執(zhí)行結(jié)果如下：
其中比較重要的包括：
- rdb_last_bgsave_status:上次bgsave 執(zhí)行結(jié)果，可以用于發(fā)現(xiàn)bgsave錯(cuò)誤
- rdb_last_bgsave_time_sec:上次bgsave執(zhí)行時(shí)間(單位是s)，可以用于發(fā)現(xiàn)bgsave是否耗時(shí)過(guò)長(zhǎng)
- aof_enabled:AOF是否開(kāi)啟
- aof_last_rewrite_time_sec: 上次文件重寫(xiě)執(zhí)行時(shí)間(單位是s)，可以用于發(fā)現(xiàn)文件重寫(xiě)是否耗時(shí)過(guò)長(zhǎng)
- aof_last_bgrewrite_status: 上次bgrewrite執(zhí)行結(jié)果，可以用于發(fā)現(xiàn)bgrewrite錯(cuò)誤
- aof_buffer_length和aof_rewrite_buffer_length:aof緩存區(qū)大小和aof重寫(xiě)緩沖區(qū)大小
- aof_delayed_fsync:AOF追加阻塞情況的統(tǒng)計(jì)
(2)info stats
其中與持久化關(guān)系較大的是：latest_fork_usec，代表上次fork耗時(shí)，可以參見(jiàn)前面的討論。
六、總結(jié)
本文主要內(nèi)容可以總結(jié)如下：
1、持久化在Redis高可用中的作用：數(shù)據(jù)備份，與主從復(fù)制相比強(qiáng)調(diào)的是由內(nèi)存到硬盤(pán)的備份。
2、RDB持久化：將數(shù)據(jù)快照備份到硬盤(pán)；介紹了其觸發(fā)條件(包括手動(dòng)出發(fā)和自動(dòng)觸發(fā))、執(zhí)行流程、RDB文件等，特別需要注意的是文件保存操作由fork出的子進(jìn)程來(lái)進(jìn)行。
3、AOF持久化：將執(zhí)行的寫(xiě)命令備份到硬盤(pán)(類(lèi)似于MySQL的binlog)，介紹了其開(kāi)啟方法、執(zhí)行流程等，特別需要注意的是文件同步策略的選擇(everysec)、文件重寫(xiě)的流程。
4、一些現(xiàn)實(shí)的問(wèn)題：包括如何選擇持久化策略，以及需要注意的fork阻塞、AOF追加阻塞等。
參考文獻(xiàn)
《Redis開(kāi)發(fā)與運(yùn)維》
《Redis設(shè)計(jì)與實(shí)現(xiàn)》
《Redis實(shí)戰(zhàn)》
http://www.redis.cn/topics/persistence.html
https://mp.weixin.qq.com/s/fpupqLp-wjR8fQvYSQhVLg
https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650764050&idx=1&sn=891287b9f99a8c1dd4ce9e1805646741&chksm=f3f9c687c48e4f91c6631e7f5e36a9169c10549386bec541dbeef92ed0023a373f6ec25c2ef1&mpshare=1&scene=1&srcid=0525xnHQxiFwpzFWSME2LQrb#rd
https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650763383&idx=1&sn=348a84605a7cdefe4e075c9f0310f257&chksm=f3f9c5e2c48e4cf41bd3f708bce3f9a1302a699cf7defe611e9aea120fcb424944119e079362&mpshare=1&scene=1&srcid=0525XIl8KXvHYvX42oaUcop0#rd
https://blog.csdn.net/tonyxf121/article/details/8475603
http://heylinux.com/archives/1932.html
https://www.m690.com/archives/380/
總結(jié)
以上是生活随笔為你收集整理的android平台上持久化存储3种手段_深入学习Redis ：持久化的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 如何登陆网页的back office_如
- 下一篇： jmeter提取mysql数据_通过jm