摘要：因為文件重寫也需要用到子進程，所以快照持久化因為創(chuàng)建子進程而導致的性能問題和內(nèi)存占用問題，在持久化中也同樣存在。上一篇文章實戰(zhàn)第四章數(shù)據(jù)安全與性能保障第節(jié)快照持久化下一篇文章實戰(zhàn)第四章數(shù)據(jù)安全與性能保障第節(jié)復制

上一篇文章：Python--Redis實戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第2節(jié)：快照持久化
下一篇文章：Python--Redis實戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第4節(jié)：復制

簡單來說，AOF持久化會將被執(zhí)行的命令寫到AOF文件的末尾，以此來記錄數(shù)據(jù)發(fā)送的變化。因此，Redis只要從頭到尾重新執(zhí)行一次AOF文件包含的所有寫命令，就可以恢復AOF文件所記錄的數(shù)據(jù)集。AOF持久化可以通過設(shè)置代碼appendonly yes配置選項來打開。

文件同步：在向硬盤寫入文件時，至少會發(fā)生三件事情，當調(diào)用file.write()方法（或其它編程語言里面的類似操作）對文件進行寫入時，寫入的內(nèi)容首先會被存儲到緩沖區(qū)，然后操作系統(tǒng)會在將來的某個時候?qū)⒕彌_區(qū)存儲的內(nèi)容寫入硬盤，而數(shù)據(jù)只有在被寫入硬盤后，才算是真正地保存到了硬盤里面。用戶可以通過調(diào)用file.flush()方法來請求操作系統(tǒng)盡快地將緩沖區(qū)存儲的數(shù)據(jù)寫入硬盤里面，但具體地執(zhí)行寫入操作仍然由系統(tǒng)決定。除此之外，用戶還可以命令操作系統(tǒng)將文件同步(sync)到硬盤，同步操作會一直阻塞直到指定的文件被寫入硬盤為止。當同步操作執(zhí)行完畢之后，即使系統(tǒng)出現(xiàn)故障也不會對被同步的文件造成任何影響。

下表展示了appendfsync 配置選項對AOF文件的同步頻率的影響。

如果用戶使用appendfsync always 選項的話，那么每個Redis寫命令都會被寫入硬盤，從而將發(fā)生系統(tǒng)崩潰時出現(xiàn)的數(shù)據(jù)丟失減到最少。不過遺憾的是，因為這種同步策略需要對硬盤進行大量寫入，所以Redis處理命令的速度會受到硬盤性能的限制：轉(zhuǎn)盤式硬盤（spinning disk）在這種同步頻率下每秒只能處理大約200個寫命令，而固態(tài)硬盤(solid-state drive,SSD)每秒大概也只能處理幾萬個寫命令。

警告：固態(tài)硬盤和appendfsync always
使用固態(tài)硬盤的用戶請謹慎使用appendfsync always選項，因為這個選項讓Redis每次只寫入一個命令，而不是像其他appendfsync選項那樣一次寫入多個命令，這種不斷地寫入少量數(shù)據(jù)的做法有可能會引發(fā)嚴重的寫入放大（write amplification）問題，在某些環(huán)境下甚至會將固態(tài)硬盤的壽命從原來的幾年降低為幾個月。

為了兼顧數(shù)據(jù)安全和寫入性能，用戶可以考慮使用appendfsync everysec選項，讓Redis以每秒一次的頻率對AOF文件進行同步。Redis每秒同步一次AOF文件時的性能和不使用任何持久化特性時的性能相差無幾，而通過每秒同步一次AOF文件，Redis可以保證，即使出現(xiàn)系統(tǒng)崩潰，用戶也最多只會丟失一秒之內(nèi)產(chǎn)生的數(shù)據(jù)。當硬盤忙于執(zhí)行寫入操作的時候，Redis還會優(yōu)雅地放慢自己的速度以便適應(yīng)硬盤的最大寫入速度。

最后，如果用戶使用appendfsync no選項，那么Redis將不對AOF文件執(zhí)行任何顯示的同步操作，而是由操作系統(tǒng)來決定應(yīng)該在何時對AOF文件進行同步。這個選項在一般情況下不會對Redis的性能帶來影響，但系統(tǒng)崩潰將導致使用這種選項的Redis服務(wù)器丟失不定數(shù)量的數(shù)據(jù)。另外，如果用戶的硬盤處理寫入操作的速度不夠快的話，那么當緩沖區(qū)被等待寫入磁盤的數(shù)據(jù)填滿時，Redis的寫入操作將被阻塞，并導致Redis處理命令請求的速度變慢。因為這個原因，一般來說并不推薦使用appendfsync no選項，在這里介紹了它只是為了完整列舉appendfsync選項的可用的3個值。

雖然AOF持久化非常靈活地提供了多種不同的選項來滿足不同應(yīng)用程序?qū)?shù)據(jù)安全的不同要求，但AOF持久化也有缺陷：那就是AOF文件的體積大小。

AOF持久化既可以將丟失數(shù)據(jù)的時間區(qū)間降低至1秒（甚至不丟失任何數(shù)據(jù)），又可以在極端的時間內(nèi)完成定期的持久化操作，那么我們有什么理由不使用AOF持久化呢？但是這個問題實際上并沒有那么簡單，因為Redis會不斷地將被執(zhí)行的寫命令記錄到AOF文件里面，所有隨著Redis不斷運行，AOF文件的體積會不斷增長，在極端情況下，體積不斷增大的AOF文件甚至可能會用完磁盤的所有可用空間。還有另一個問題是，因為Redis在重啟之后需要通過重新執(zhí)行AOF文件記錄的所有寫命令的還原數(shù)據(jù)集，所以如果AOF文件的體積非常大，那么還原操作執(zhí)行的時間就可能會非誠長。

為了解決AOF文件體積不斷增大的問題，用戶可以向Redis發(fā)送bgrewriteaof命令，這個命令會通過移除AOF文件中的冗余命令來重寫（rewrite）AOF文件，使AOF文件的體積變得盡可能地小。bgrewriteaof的工作原理和bgsave創(chuàng)建快照的工作原因非常相似：Redis會創(chuàng)建一個子進程，然后由子進程負責對AOF文件進行重寫。因為AOF文件重寫也需要用到子進程，所以快照持久化因為創(chuàng)建子進程而導致的性能問題和內(nèi)存占用問題，在AOF持久化中也同樣存在。更糟糕的是，如果不加以控制的話，AOF文件的體積可能會比快照的體積大好幾倍，在進行AOF重寫并刪除舊AOF文件的時候，刪除一個體積達到數(shù)十GB大的舊AOF文件可能會導致操作系統(tǒng)掛起數(shù)秒。

跟快照持久化可以通過設(shè)置save選項來自動執(zhí)行bgsave一樣，AOF持久化也可以通過設(shè)置auto-aof-rewrite-percentage選項和auto-aof-rewrite-min-size選項來自動執(zhí)行bgrewriteaof。舉個例子，假設(shè)用戶對Redis設(shè)置了配置選項auto-aof-rewrite-percentage 100和auto-aof-rewrite-min-size 64mb，并且啟用了AOF持久化，那么當AOF文件的體積大于64MB，并且AOF文件的體積比上一次重寫之后的體積大了至少一倍（100%）的時候，Redis將執(zhí)行bgrewriteaof命令。如果aof重寫執(zhí)行得過于頻繁地話，那么用戶可以考慮將auto-aof-rewrite-percentage選項的值設(shè)置為100以上，這種做法可以讓Redis在AOF文件的體積變得更大之后才執(zhí)行重寫操作，不過也會讓Redis在啟動時還原數(shù)據(jù)集所需的時間變得更長。

無論是使用AOF持久化還是快照持久化，將數(shù)據(jù)持久化到硬盤上都是非常有必要的，但除了進行持續(xù)化之外，用戶還必須對持久化所得的文件進行備份（最好是備份到不同的地方），這樣才能盡量避免數(shù)據(jù)丟失事故發(fā)生。如果條件允許的話，最好能夠?qū)⒖煺瘴募妥钚轮貙懙腁OF文件備份到不同的服務(wù)器上面。

通過使用AOF持久化或者快照持久化，用戶可以在系統(tǒng)重啟或者崩潰的情況下仍讓保留數(shù)據(jù)。隨著負載量的上升、或者數(shù)據(jù)的完整性變得越來越重要時，用戶可能需要使用復制性。

上一篇文章：Python--Redis實戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第2節(jié)：快照持久化
下一篇文章：Python--Redis實戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第4節(jié)：復制