一、Redis先執行指令，再記錄AOF日志的原因

Redis是一種內存數據庫，對于大多數的操作，Redis會先將請求寫入內存中的數據結構，然后再異步地將修改同步到磁盤上的AOF（Append-Only File）文件中，這就是非常高效的原因。Redis的性能很大程度上取決于CPU的速度和內存的大小。因此，Redis選擇將大部分數據保存在內存中，以提高運行速度。Redis 的數據是存內存的，斷電之后就丟了。Redis 的 AOF / RDB 相當于有一個把硬盤當內存的 slave。存儲引擎數據是存硬盤的，斷電之后，可能有臟數據，也可能沒有，需要 redo log / undo log 來做原子 commit。保護 commit 的數據是不可能在 commit 之后寫的。存儲引擎的日志只保護 uncommitted data。

二、Redis 在 Java Web 中的應用

1、緩存

在日常對數據庫的訪問中，讀操作的次數遠超寫操作，比例大概在?1:9?到?3:7，所以需要讀的可能性是比寫的可能大得多的。當我們使用SQL語句去數據庫進行讀寫操作時，數據庫就會去磁盤把對應的數據索引取回來，這是一個相對較慢的過程。

如果我們把數據放在 Redis 中，也就是直接放在內存之中，讓服務端直接去讀取內存中的數據，那么這樣速度明顯就會快上不少，并且會極大減小數據庫的壓力，但是使用內存進行數據存儲開銷也是比較大的，限于成本的原因，一般我們只是使用 Redis 存儲一些常用和主要的數據，比如用戶登錄的信息等。

一般而言在使用 Redis 進行存儲的時候，我們需要從以下幾個方面來考慮：

**業務數據常用嗎？命中率如何？**如果命中率很低，就沒有必要寫入緩存；**該業務數據是讀操作多，還是寫操作多？**如果寫操作多，頻繁需要寫入數據庫，也沒有必要使用緩存；**業務數據大小如何？**如果要存儲幾百兆字節的文件，會給緩存帶來很大的壓力，這樣也沒有必要。

在考慮了這些問題之后，如果覺得有必要使用緩存，那么就使用它。

當名列前茅次讀取數據的時候，讀取 Redis 的數據就會失敗，此時就會觸發程序讀取數據庫，把數據讀取出來，并且寫入 Redis 中；當第二次以及以后需要讀取數據時，就會直接讀取 Redis，讀到數據后就結束了流程，這樣速度就大大提高了。

從上面的分析可以知道，讀操作的可能性是遠大于寫操作的，所以使用 Redis 來處理日常中需要經常讀取的數據，速度提升是顯而易見的，同時也降低了對數據庫的依賴，使得數據庫的壓力大大減少。

分析了讀操作的邏輯，下面我們來看看寫操作的流程：

從流程可以看出，更新或者寫入的操作，需要多個 Redis 的操作，如果業務數據寫次數遠大于讀次數那么就沒有必要使用 Redis。

2、高速讀/寫的場合

在如今的互聯網中，越來越多的存在高并發的情況，比如天貓雙11、搶紅包、搶演唱會門票等，這些場合都是在某一個瞬間或者是某一個短暫的時刻有成千上萬的請求到達服務器，如果單純的使用數據庫來進行處理，就算不崩，也會很慢的，輕則造成用戶體驗極差用戶量流失，重則數據庫癱瘓，服務宕機，而這樣的場合都是不允許的。所以我們需要使用 Redis 來應對這樣的高并發需求的場合，我們先來看看一次請求操作的流程圖：

我們來進一步闡述這個過程：

當一個請求到達服務器時，只是把業務數據在 Redis 上進行讀寫，而沒有對數據庫進行任何的操作，這樣就能大大提高讀寫的速度，從而滿足高速響應的需求；但是這些緩存的數據仍然需要持久化，也就是存入數據庫之中，所以在一個請求操作完 Redis 的讀/寫之后，會去判斷該高速讀/寫的業務是否結束，這個判斷通常會在秒殺商品為0，紅包金額為0時成立，如果不成立，則不會操作數據庫；如果成立，則觸發事件將 Redis 的緩存的數據以批量的形式一次性寫入數據庫，從而完成持久化的工作。

三、AOF簡介

1、AOF持久化方式

AOF持久化方式是將redis的操作日志以追加的方式寫入磁盤文件中。AOF持久化是以日志的形式記錄服務器所處理的每一個寫、刪除操作，查詢操作不會記錄，以文本的方式記錄，可以打開文件看到詳細的操作記錄。

2、AOF實現方式

AOF(append only file)持久化是以獨立日志的方式記錄每次寫命令，重啟時再重新執行AOF文件中命令達到恢復數據的目的。AOF的主要作用是解決了數據持久化的實時性，目前已經是Redis持久化的主流方式。

3、AOF優勢

該機制可以帶來更高的數據安全性，即數據持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。

每秒同步：事實上，每秒同步也是異步完成的，其效率也是非常高的，所差的是一旦系統出現宕機現象，那么這一秒鐘之內修改的數據將會丟失。每次修改：而每修改同步，我們可以將其視為同步持久化，即每次發生的數據變化都會被立即記錄到磁盤中。不同步：可以預見，這種方式在效率上是最低的。至于無同步，無需多言，我想大家都能正確的理解它。

由于該機制對日志文件的寫入操作采用的是append模式，因此在寫入過程中即使出現宕機現象，也不會破壞日志文件中已經存在的內容。如果我們本次操作只是寫入了一半數據就出現了系統崩潰問題，不用擔心，在Redis下一次啟動之前，我們可以通過redis-check-aof工具來幫助我們解決數據一致性的問題。

如果日志過大，Redis可以自動啟用rewrite機制，壓縮和瘦身相關的aof文件。Redis以append模式不斷的將修改數據寫入到老的磁盤文件中，同時Redis還會創建一個臨時的新文件用于記錄此期間有哪些修改命令被執行。因此在進行rewrite切換時可以更好的保證數據安全性。

延伸閱讀1：AOF重寫機制

隨著命令不斷寫入AOF，文件會越來越大，為了解決這個問題，Redis引入了AOF重寫機制壓縮文件體積。AOF文件重寫是把Redis進程內的數據轉化為寫命令同步到新AOF文件的過程。