.jpg)
redis作為當(dāng)下web編程必不可少的服務(wù)，它的特點(diǎn)的是顯而易見，相對(duì)memcached而言，做緩存，重啟數(shù)據(jù)不丟失，非常好用。那么問題來了，它是怎么做到的呢？
RDB
RDB就是持久化的一種手段，把內(nèi)存中數(shù)據(jù)在某些條件下寫到磁盤中去。那么在哪些條件下寫入呢？不可能無腦寫入，來一個(gè)寫一個(gè)，影響性能，也不能等老半天才寫一個(gè)，萬一中間宕機(jī)了，數(shù)據(jù)全丟失，還不如用memcached。在redis的配置里有著這樣的一段配置：
save 900 1
save 300 10
save 60 10000
很關(guān)鍵的一段配置，這時(shí)RDB持久化的核心。意思是：
1.如果900秒時(shí)，有1個(gè)key變化（插入或者更新），我就同步到磁盤一下
2.如果300秒時(shí)，有10個(gè)key變化（插入或者更新），我就同步到磁盤一下
3.如果60秒時(shí)，有10000個(gè)key變化（插入或者更新），我就同步到磁盤一下
這些時(shí)間點(diǎn)和變化的數(shù)量是怎么知道的，這時(shí)有另外兩個(gè)極為關(guān)鍵的東西，一個(gè)叫dirty計(jì)數(shù)器，一個(gè)叫l(wèi)astsave（上次save的時(shí)間），dirty計(jì)數(shù)器專門記錄從上次save后變化key的數(shù)量，lastsave記錄執(zhí)行save的時(shí)間，舉個(gè)例子剛開始時(shí)間是time1，dirty是0，這時(shí)有20個(gè)key發(fā)生了變化，dirty是20，然后現(xiàn)在的時(shí)間是time2，time2-time1 >= 300,滿足第二個(gè)條件，這時(shí)內(nèi)存中的數(shù)據(jù)會(huì)save一下，同時(shí)dirty清為0，然后再等待條件觸發(fā)。
如果我60秒內(nèi)有10萬個(gè)key，那么問題來了，一下大量磁盤io來臨，這時(shí)redis主進(jìn)程就會(huì)阻塞，期間的所有的命令都不執(zhí)行，這哪能行，于是就來了一個(gè)叫bgsave的，它是redis主進(jìn)程fork出來的一個(gè)子進(jìn)程，專門執(zhí)行rdb的持久化工作的。
保存的文件格式是二進(jìn)制格式的，萬一數(shù)據(jù)庫宕機(jī)，恢復(fù)不需要人為干預(yù)，redis會(huì)自動(dòng)讀取磁盤文件。
AOF
與RDB不同，AOF存儲(chǔ)的是你執(zhí)行的命令，當(dāng)aof功能打開的時(shí)候，執(zhí)行的更新命令不會(huì)直接寫到aof文件中去，而是先寫到一個(gè)aof buf中，我們知道不能一直往buf中寫，buf也是內(nèi)存啊，那么何時(shí)才能同步到磁盤中去呢？redis中也有這樣一段配置
appendfsync always
appendfsync everysec
appendfsync no
意思是：
1.只要有更新的命令我就同步
2.如果上次同步時(shí)間距離現(xiàn)在超過一秒就同步
3.不同步，等待操作系統(tǒng)自己判斷（什么時(shí)候我有空我才同步）
分析下，第一種io頻繁，io壓力大，但丟失數(shù)據(jù)的概率最小，第二種io壓力不是很大，最多也就丟失1秒左右的數(shù)據(jù)，第三中io壓力很小，丟失數(shù)據(jù)概率太大。綜合考慮，一般第二種。但還有個(gè)問題，我執(zhí)行了100次INCR num，按道理num就是100，aof中也有100個(gè)同樣的命令，沒毛病，那么請(qǐng)問執(zhí)行100次INCR num和SET num 100有什么區(qū)別，同樣的結(jié)果前者多了99倍的空間，很浪費(fèi)啊，于是就出現(xiàn)了AOF重寫，它是怎么做到的。很簡單：首先從數(shù)據(jù)庫讀取現(xiàn)在的值，然后用一條記錄代替，這就是AOF重寫的原理。重寫很花時(shí)間，所以也是子進(jìn)程來處理。重寫的過程中，如果有新的命令來臨怎么辦，老辦法，寫buf緩沖，重寫完成后，把buf中的命令追加到新的aof中，然后用新的aof替代老的aof，就實(shí)現(xiàn)了重寫。
本文來自redis教程，歡迎學(xué)習(xí)。
.png)
