??因?yàn)镽edis是內(nèi)存數(shù)據(jù)庫，它將自己的數(shù)據(jù)庫狀態(tài)存儲(chǔ)在內(nèi)存當(dāng)中消略，所以如果不想辦法將存儲(chǔ)在內(nèi)存中的數(shù)據(jù)庫狀態(tài)保存到磁盤里面蛤高，那么一旦服務(wù)器進(jìn)程退出，服務(wù)器中的數(shù)據(jù)庫狀態(tài)也會(huì)消失不見钦购。
??為了解決這個(gè)問題，Redis提供了RDB（Redis DataBase)持久化功能和AOF(Append Only File)持久化功能铸本，都可以將Redis在內(nèi)存中的數(shù)據(jù)庫狀態(tài)保存到磁盤里面肮雨，避免數(shù)據(jù)意外丟失。下面分別介紹：
RDB持久化
??RDB持久化功能既可以手動(dòng)執(zhí)行箱玷，也可以根據(jù)服務(wù)器配置選項(xiàng)定期執(zhí)行怨规，該功能可以將某個(gè)時(shí)間點(diǎn)上的數(shù)據(jù)庫狀態(tài)保存到一個(gè)RDB文件中陌宿，如圖10-2:
??RDB文件是一個(gè)經(jīng)過壓縮的二進(jìn)制文件，通過該文件可以還原生成RDB文件時(shí)的數(shù)據(jù)庫狀態(tài)波丰，如上圖10-3壳坪。
??因?yàn)镽DB文件是保存在硬盤中的，所以即使Redis服務(wù)器進(jìn)程退出掰烟，甚至運(yùn)行Redis服務(wù)器的計(jì)算機(jī)停機(jī)爽蝴，但只要RDB文件仍然存在，Redis服務(wù)器就可以用它來還原數(shù)據(jù)庫狀態(tài)纫骑。
RDB文件的創(chuàng)建
??有兩個(gè)Redis命令可以用于生成RDB文件蝎亚，一個(gè)是SAVE,另一個(gè)是BGSAVE，如下：
127.0.0.1:6379> save //等待直到RDB文件創(chuàng)建完畢
OK
??SAVE命令會(huì)阻塞服務(wù)器進(jìn)程先馆，直到RDB文件創(chuàng)建完畢為止发框，在服務(wù)器進(jìn)程阻塞期間，服務(wù)器不能處理任何客戶端發(fā)送的命令請(qǐng)求煤墙。只有在服務(wù)器執(zhí)行完;SAVE命令后梅惯、重新開始接受命令請(qǐng)求之后，客戶端發(fā)送的命令才會(huì)被處理仿野。
127.0.0.1:6379> bgsave //派生子進(jìn)程铣减，并由子進(jìn)程創(chuàng)建RDB文件
Background saving started
??和SAVE命令不同的是，BGSAVE命令會(huì)派生出一個(gè)子進(jìn)程脚作，然后由子進(jìn)程負(fù)責(zé)創(chuàng)建RDB文件葫哗，服務(wù)器進(jìn)程(父進(jìn)程)繼續(xù)處理命令請(qǐng)求，所以Redis服務(wù)器仍然可以繼續(xù)處理客戶端的命令請(qǐng)求鳖枕。不過需要注意的是魄梯，BGSAVE命令執(zhí)行期間，客戶端發(fā)送的SAVE命令和BGSAVE命令都會(huì)被服務(wù)器拒絕宾符，這是為了防止產(chǎn)生競(jìng)爭(zhēng)條件酿秸。還有BGSAVE命令不能和BGREWRITEAOF命令同時(shí)執(zhí)行。
??通過默認(rèn)方式啟動(dòng)的服務(wù)器生成的RDB文件名默認(rèn)為dump.rdb魏烫，默認(rèn)存放的位置可以通過config get dir命令查看辣苏，不同系統(tǒng)的存儲(chǔ)位置可能有偏差，macOS中dump.rdb文件位置如下：
127.0.0.1:6379> config get dir
1) "dir"
2) "/Users/apple"
??當(dāng)然我們也可以以指定配置文件(redis.conf)的方式啟動(dòng)服務(wù)器哄褒，所以你可以修改生成的RDB文件名字和位置稀蟋，下面為配置文件中的默認(rèn)配置(一般不修改)
# The filename where to dump the DB
dbfilename dump.rdb
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir /usr/local/var/db/redis/
??我們打開dump.rdb文件查看一下：
REDIS0009? redis-ver?5.0.4?
redis-bits?@??ctime??\?used-mem????aof-preamble???i????=y
??很顯然是一堆有部分是看不懂的二進(jìn)制字符，因?yàn)镽DB文件本身就是是一個(gè)經(jīng)過壓縮的二進(jìn)制文件呐赡，它默認(rèn)有一定字節(jié)退客，保存了Redis版本等信息。
localhost:~ wksky$ od /usr/local/var/db/redis/dump.rdb
0000000 042522 044504 030123 030060 175071 071011 062145 071551
0000020 073055 071145 032405 030056 032056 005372 062562 064544
0000040 026563 064542 071564 040300 002772 072143 066551 141145
0000060 164447 056252 004372 071565 062145 066455 066545 110302
0000100 010007 175000 060414 063157 070055 062562 066541 066142
0000120 140145 177400 014442 141640 160140 073510
0000134
RDB文件的載入
??和使用命令創(chuàng)建RDB文件不同，RDB文件的載入工作是在服務(wù)器啟動(dòng)時(shí)自動(dòng)執(zhí)行的萌狂，所以Redis并沒有專門用于載入RDB文件的命令档玻，只要Redis服務(wù)器在啟動(dòng)時(shí)監(jiān)測(cè)到RDB文件存在，它就會(huì)自動(dòng)載入RDB文件茫藏，下面為啟動(dòng)服務(wù)器時(shí)的日志：
4831:M 08 Apr 2019 10:46:15.806 # Server initialized
4831:M 08 Apr 2019 10:46:15.806 * DB loaded from disk: 0.000 seconds //載入RDB文件
4831:M 08 Apr 2019 10:46:15.806 * Ready to accept connections
??根據(jù)Redis服務(wù)器不同的啟動(dòng)方式載入的RDB文件也不相同误趴，默認(rèn)方式啟動(dòng)載入的是/Users/apple下的dump.rdb文件(mac OS)，以指定配置文件方式啟動(dòng)服務(wù)器載入的是配置文件中的RDB文件务傲，即/usr/local/var/db/redis/下的dump.rdb文件(mac OS)凉当。
??還有需要注意的一點(diǎn)是：Redis服務(wù)器在載入RDB文件期間，會(huì)一直處于阻塞狀態(tài)售葡，直到載入工作完成為止看杭。
自動(dòng)間隔性保存
??因?yàn)?code>BGSAVE命令可以在不阻塞服務(wù)器進(jìn)程的情況下執(zhí)行，所以Redis允許用戶通過設(shè)置服務(wù)器配置的save選項(xiàng)天通，讓服務(wù)器每隔一段時(shí)間自動(dòng)執(zhí)行一次BGSAVE命令泊窘。用戶可以通過save選項(xiàng)設(shè)置多個(gè)保存條件，只要其中任意一個(gè)條件被滿足像寒，服務(wù)器就會(huì)執(zhí)行BGSAVE命令。以下為redis.conf文件中相關(guān)配置:
# Save the DB on disk:
#
# save <seconds> <changes>
#
# Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
#
# Note: you can disable saving completely by commenting out all "save" lines.
#
# It is also possible to remove all the previously configured save
# points by adding a save directive with a single empty string argument
# like in the following example:
#
# save ""
save 900 1
save 300 10
save 60 10000
??Redis的服務(wù)器周期性操作函數(shù)serverCron默認(rèn)每隔100毫秒就會(huì)執(zhí)行一次瓜贾，該函數(shù)用于對(duì)正在運(yùn)行的服務(wù)器進(jìn)行維護(hù)诺祸，它的一項(xiàng)工作就是檢查上面save選項(xiàng)所設(shè)置的保存條件是否已經(jīng)滿足，如果滿足的話祭芦，就執(zhí)行BGSAVE命令.
??那么只要滿足以下3個(gè)條件中的任何一個(gè)保存條件筷笨，BGSAVE命令就會(huì)被執(zhí)行：
- 服務(wù)器在900秒之內(nèi)，對(duì)數(shù)據(jù)庫進(jìn)行了至少1次修改
- 服務(wù)器在300秒之內(nèi)龟劲，對(duì)數(shù)據(jù)庫進(jìn)行了至少10次修改
- 服務(wù)器在60秒之內(nèi)胃夏，對(duì)數(shù)據(jù)庫進(jìn)行了至少10000次修改
??舉個(gè)例子，以下是Redis服務(wù)器在60秒之內(nèi)昌跌，對(duì)數(shù)據(jù)庫進(jìn)行了至少10000次修改之后仰禀，服務(wù)器自動(dòng)執(zhí)行BGSAVE命令時(shí)打印出來的日志：
??當(dāng)然，以默認(rèn)方式啟動(dòng)服務(wù)器的保存配置并不一樣蚕愤，不過相信你有了上面的理解答恶，可以很容易的看懂它們，代碼如下：
127.0.0.1:6379> config get save
1) "save"
2) "3600 1 300 100 60 10000"
AOF持久化
??除了RDB外萍诱，Redis還提供了AOF持久化功能悬嗓。與RDB持久化通過保存數(shù)據(jù)庫中的鍵值對(duì)來記錄數(shù)據(jù)庫狀態(tài)不同，AOF持久化是通過保存Redis服務(wù)器所執(zhí)行的寫命令來記錄數(shù)據(jù)庫狀態(tài)的裕坊，如下圖：
??舉個(gè)例子包竹，當(dāng)我們開啟AOF持久化功能時(shí)(后面介紹)，如果我們?cè)跀?shù)據(jù)庫中執(zhí)行下面3個(gè)命令，庫中將包含3個(gè)鍵值對(duì)：
127.0.0.1:6379> set msg "hello world"
OK
127.0.0.1:6379> sadd fruits apple banana orange
(integer) 3
127.0.0.1:6379> rpush age 2 3 4
(integer) 3
??RDB持久化保存數(shù)據(jù)庫狀態(tài)的方式是將msg周瞎、fruits悟狱、age3個(gè)鍵的鍵值對(duì)保存到RDB文件中，而AOF持久化保存數(shù)據(jù)庫狀態(tài)的方法是將服務(wù)器執(zhí)行的set堰氓、sadd挤渐、rpush3個(gè)命令保存到AOF文件中。
??被寫入AOF文件的所以命令都是以Redis的命令請(qǐng)求協(xié)議格式保存的双絮，為純文本格式浴麻，和RDB的二進(jìn)制不同，我們可以直接打開一個(gè)AOF文件appendonly.aof囤攀，如下：
*2
$6
SELECT
$1
0
*3
$3
set
$3
msg
$11
hello world
*5
$4
sadd
$6
fruits
$5
apple
$6
banana
$6
orange
*5
$5
rpush
$3
age
$1
2
$1
3
$1
4
??這個(gè)文件中软免，除了用于指定數(shù)據(jù)庫的SELECT命令是服務(wù)器自動(dòng)添加的外，其他都是我們之前發(fā)送的命令焚挠，服務(wù)器啟動(dòng)時(shí)膏萧，可以通過載入和執(zhí)行AOF文件中保存的命令來還原服務(wù)器關(guān)閉之前的數(shù)據(jù)庫狀態(tài)。
??問題:既然這個(gè)文件是純文本格式蝌衔，有一定格式榛泛，那我們是否能在其上增加一些命令或刪除一些命令呢？放心噩斟，Redis有一定的檢驗(yàn)機(jī)制曹锨，當(dāng)發(fā)現(xiàn)該文件出現(xiàn)了錯(cuò)誤文本時(shí)，會(huì)提示文件錯(cuò)誤剃允，請(qǐng)求修復(fù)沛简。如果你按其指定格式來增加命令，該命令會(huì)被識(shí)別為錯(cuò)誤命令斥废，不會(huì)執(zhí)行它椒楣。
AOF持久化的開啟配置
??AOF文件和RDB文件不同的是，以默認(rèn)方式啟動(dòng)的Redis服務(wù)器是不開啟AOF持久化技術(shù)的牡肉，我們以默認(rèn)方式啟動(dòng)服務(wù)器并通過命令查看一下：
localhost:~ wksky$ redis-cli
127.0.0.1:6379> config get appendonly
1) "appendonly" //是否開啟AOF持久化技術(shù)
2) "no" //不開啟
127.0.0.1:6379> config get appendfilename
(empty list or set) //文件名也是空的
??可以看到默認(rèn)是不開啟AOF持久化技術(shù)的捧灰，所以我們一般使用redis.conf配置文件啟動(dòng)Redis服務(wù)器，將其appendonly狀態(tài)改為yes即可荚板，下面為redis.conf中配置信息：
############################## APPEND ONLY MODE ###############################
# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.
#appendonly no
appendonly yes
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
?? appendfilename文件名默認(rèn)為"appendonly.aof"就好凤壁，其文件保存位置和RDB文件保存的位置一樣。
AOF持久化的實(shí)現(xiàn)
?? AOF持久化功能的實(shí)現(xiàn)可以分為命令追加(append)跪另、文件寫入拧抖、文件同步(sync)3個(gè)步驟.
命令追加
??當(dāng)AOF持久化功能處于打開狀態(tài)時(shí)，服務(wù)器在執(zhí)行完一個(gè)寫命令之后免绿，會(huì)以協(xié)議格式將被執(zhí)行的寫命令追加到服務(wù)器狀態(tài)的aof_buf緩沖區(qū)的末尾唧席。
文件的寫入
??Redis的服務(wù)器進(jìn)程就是一個(gè)事件循環(huán)(loop)，這個(gè)循環(huán)中的文件事件負(fù)責(zé)接受客戶端的命令請(qǐng)求，以及向客戶端發(fā)送命令回復(fù)淌哟，而時(shí)間事件則負(fù)責(zé)執(zhí)行像serveerCron函數(shù)這樣需要定期運(yùn)行的函數(shù)迹卢。
??為了提高文件的寫入效率，在現(xiàn)代操作系統(tǒng)中徒仓，當(dāng)用戶調(diào)用write函數(shù)腐碱，將一些數(shù)據(jù)寫入到文件的時(shí)候，操作系統(tǒng)通常會(huì)將寫入數(shù)據(jù)暫時(shí)保存在一個(gè)內(nèi)存緩沖區(qū)中掉弛，等到緩沖區(qū)的空間被填滿症见、或者超過了指定的時(shí)限之后，才真正地將緩沖區(qū)中的數(shù)據(jù)寫入到磁盤里面(寫入 = 數(shù)據(jù)進(jìn)內(nèi)存緩沖區(qū)殃饿， 同步 = 緩沖區(qū)數(shù)據(jù)進(jìn)硬盤)谋作。
??因?yàn)榉?wù)器在處理文件事件時(shí)可能會(huì)執(zhí)行寫命令，使得一些內(nèi)容被追加到aof_buf緩沖區(qū)里面乎芳，所以在服務(wù)器每次結(jié)束一個(gè)事件循環(huán)之前遵蚜，它都會(huì)調(diào)用flushAppendOnlyFile函數(shù)，考慮是否需要將aof_buf緩沖區(qū)的內(nèi)容寫入和保存到AOF文件里面奈惑，它的行為由redis.conf設(shè)置的appendfsync屬性來決定吭净，配置如下。
# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
??其中的appendfsync屬性携取，可以設(shè)置為always攒钳、everysec、no雷滋，它們代表著不同的AOF文件保存方式
-
always：該模式下,服務(wù)器在每個(gè)事件循環(huán)后都要將寫入進(jìn)aof_buf緩沖區(qū)中的所有數(shù)據(jù)同步到AOF文件。雖然其效率是3個(gè)值中最慢的一個(gè)文兢，但從安全行來說晤斩，它是最安全的，因?yàn)榧词钩霈F(xiàn)故障停機(jī)姆坚，AOF持久化也只會(huì)丟失一個(gè)事件循環(huán)中所產(chǎn)生的命令數(shù)據(jù)澳泵。 -
everysec(默認(rèn)設(shè)置)：該模式下，服務(wù)器每隔一秒將寫入進(jìn)aof_buf緩沖區(qū)中的所有數(shù)據(jù)同步到AOF文件兼呵。從效率上來說兔辅，該模式足夠快，并且就算出現(xiàn)故障停機(jī)击喂，數(shù)據(jù)庫也只丟失一秒鐘的命令數(shù)據(jù)维苔。 -
no：該模式下，服務(wù)器在每個(gè)事件循環(huán)后將所有數(shù)據(jù)寫入aof_buf緩沖區(qū)中懂昂，至于何時(shí)同步AOF文件介时，則由操作系統(tǒng)控制。因?yàn)樵撃Ｊ綗o需隔時(shí)間同步操作，所以寫入速度是最快的沸柔。不過因?yàn)闀?huì)在系統(tǒng)緩存中積累一段時(shí)間的寫入數(shù)據(jù)循衰，所以該模式的單次同步時(shí)長(zhǎng)是最長(zhǎng)的。但若服務(wù)機(jī)出現(xiàn)故障時(shí)褐澎，將丟失上次同步之后的所有寫命令數(shù)據(jù)会钝。
文件的同步(了解)
??雖然寫入時(shí)的緩沖區(qū)機(jī)制提高了效率，但也帶來了安全問題工三。如果計(jì)算機(jī)停機(jī)迁酸，那么保存在內(nèi)存緩沖區(qū)里面的寫入數(shù)據(jù)將會(huì)丟失。
??為此徒蟆，系統(tǒng)提供了fsync和fdatasync兩個(gè)同步函數(shù)胁出，它們可以強(qiáng)制讓操作系統(tǒng)立即將緩沖區(qū)中的數(shù)據(jù)寫入到硬盤里面，從而確保寫入數(shù)據(jù)的安全性段审。
AOF文件的載入與數(shù)據(jù)還原
??因?yàn)锳OF文件里面包含了重建數(shù)據(jù)庫狀態(tài)所需的所有寫命令全蝶，所以服務(wù)器只要讀入并重新執(zhí)行一遍AOF文件里面保存的寫命令，即可還原服務(wù)器關(guān)閉之前的數(shù)據(jù)庫狀態(tài)寺枉。
AOF重寫
??因?yàn)锳OF持久化是通過保存被執(zhí)行的寫命令來記錄數(shù)據(jù)庫狀態(tài)的抑淫，所以隨著服務(wù)器運(yùn)行時(shí)間的流逝，AOF文件中的內(nèi)容會(huì)越來越多姥闪，文件的體積也越來越大始苇。如果不加以控制，可能對(duì)Redis服務(wù)器筐喳、甚至整個(gè)宿主機(jī)造成影響催式，而且文件體積越大，進(jìn)行數(shù)據(jù)還原的所需的時(shí)間就越來越多避归。
??為了解決這個(gè)問題荣月，Redis提供了AOF文件重寫(rewrite)功能，類似于壓縮梳毙。通過該功能哺窄，Redis服務(wù)器可以創(chuàng)建一個(gè)新的AOF文件來替代現(xiàn)有的AOF文件，新舊兩個(gè)文件保存的數(shù)據(jù)庫狀態(tài)相同账锹，但新的體積更小萌业。通過一個(gè)例子了解一下：
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> incr age
(integer) 19
127.0.0.1:6379> incr age
(integer) 20
??當(dāng)執(zhí)行完上面命令后，會(huì)生成一個(gè)appendonly.aof文件奸柬，內(nèi)容如下：
*2
$6
SELECT
$1
0
*3
$3
set
$3
age
$2
18
*2
$4
incr
$3
age
*2
$4
incr
$3
age
??當(dāng)我們執(zhí)行重寫命令bgrewriteaof后：
127.0.0.1:6379> bgrewriteaof
??appendonly.aof變?yōu)槿缦赂袷?
REDIS0009? redis-ver?5.0.4?
redis-bits?@??ctime?m2?\?used-mem?P??aof-preamble??????age?????m1???
??是不是感覺似曾相識(shí)生年？它變?yōu)槎M(jìn)制文件了。
??我們使用的是后臺(tái)重寫鸟缕，原因和RDB文件保存和后臺(tái)保存類似晶框，不僅可以防止線程被長(zhǎng)時(shí)間阻塞排抬，還可以避免使用鎖來保證數(shù)據(jù)的安全性。
??可是在重寫期間授段，若服務(wù)器進(jìn)程還繼續(xù)處理命令請(qǐng)求蹲蒲，新命令可能對(duì)現(xiàn)有數(shù)據(jù)庫進(jìn)行更改，會(huì)使得服務(wù)器當(dāng)前狀態(tài)和重寫后的狀態(tài)不一致侵贵。這該如何解決谬哀？為了解決數(shù)據(jù)不一致問題郊供，Redis服務(wù)器設(shè)置了一個(gè)AOF重寫緩沖區(qū)，在服務(wù)器創(chuàng)建子進(jìn)程之后使用，當(dāng)Redis服務(wù)器執(zhí)行完一個(gè)寫命令之后峭跳，會(huì)同時(shí)將這個(gè)寫命令發(fā)送給AOF緩沖區(qū)和AOF重寫緩沖區(qū)蒂破，保證了數(shù)據(jù)的一致性扒接，如下圖：
兩種持久化技術(shù)的總結(jié)
?emsp;因?yàn)锳OF文件的更新頻率通常比RDB文件的更新頻率高精钮，所以：
- 如果服務(wù)器開啟了AOF持久化功能，服務(wù)器會(huì)優(yōu)先使用AOF文件來還原數(shù)據(jù)庫狀態(tài)
- 只有在AOF持久化功能處于關(guān)閉狀態(tài)乞娄，服務(wù)器才使用RDB文件來還原數(shù)據(jù)庫狀態(tài)瞬逊。
RDB的優(yōu)點(diǎn)
- 節(jié)省磁盤空間
- 恢復(fù)速度快
RDB的缺點(diǎn)
- 雖然Redis在fork時(shí)使用了寫時(shí)拷貝技術(shù)，但如果數(shù)據(jù)龐大時(shí)還是比較消耗性能
- 一定時(shí)間間隔做一次備份仪或，如果服務(wù)器意外宕機(jī)确镊，就會(huì)丟失最后一次快照后的所有修改
AOF的優(yōu)點(diǎn)
- 備份機(jī)制更穩(wěn)定，丟失數(shù)據(jù)概率更低
- 可讀性強(qiáng)的日志文本范删，可以處理誤操作
AOF的缺點(diǎn)
- 比RDB耗費(fèi)更多磁盤空間
- 每次讀寫都同步會(huì)有一定的性能壓力
- 存在個(gè)別Bug蕾域，造成無法恢復(fù)的情況
用哪個(gè)好
- 官方推薦兩個(gè)都用
- 如果對(duì)數(shù)據(jù)不敏感，可以選單獨(dú)用RDB
- 如果只是做純內(nèi)存緩存到旦，可以都不使用
- 不建議單獨(dú)用AOF旨巷，因?yàn)榭赡艹霈F(xiàn)Bug
參考資料
《redis設(shè)計(jì)與實(shí)現(xiàn)》(第二版)
