引入快取可以提高效能，但是資料會存在兩份，一份在資料庫中，一份在快取中，如果更新其中任何一份會引起資料的不一致，資料的完整性被破壞了，因此，同步資料庫和快取的這兩份資料就非常重要。本文介紹常見的快取更新的同步策略。

預留快取Cache-aside

　　應用程式碼能夠手工管理資料庫和快取中資料，應用邏輯會在訪問資料庫之前檢查快取，在資料庫更新以後再更新快取：

上圖中Cache update快取更新時，通過手工編碼分別對資料庫save(entity)和快取(put(key,entity))做更新，將這種瑣碎的快取管理和更新夾雜在應用邏輯中並不是一種好方式，可以採取AOP面向方面攔截器等方式實現快取操作，減輕快取操作洩漏到應用程式碼中，同時確保資料庫和快取都能正確同步。

Read-through

　　相比上面同時管理資料庫和快取，我們可以簡單委託資料庫同步給一個快取提供者，所有資料互動通過這個快取抽象層完成。

圖中CacheStore是我們的快取抽象層，當我們應用通過其抓取一個快取資料時，這個快取提供者確認快取中是否有該資料，如果沒有，從資料庫載入，然後放入快取，下次以後再訪問就可以直接從快取中獲得。

Write-through

　　類似於Read-through的資料抓取策略，快取能夠在其中資料變化時自動更新底層資料庫。

　　儘管資料庫和快取同步更新了，但是我們也可以按照我們自己的業務要求選擇事務的邊界：

• 如果需要強一致性，，並且快取提供者提供了XAResource
   ，這樣我們可以在一個全域性事務中完成快取和資料庫的更新，這樣資料庫和快取更新是在一個原子單元：single atomic unit-of-work
• 如果只需要弱一致性，我們可以先後更新快取和資料庫，不必使用全域性事務，這會讓我們提升快速響應性與效能，通常快取首先被更新，如果資料庫更新失敗，快取可以通過補償動作實現回滾當前事務所做的改變。

Write-behind

　　如果強一致性不是必須的，我們可以簡單將快取的更新放在佇列中，然後定期批量地去更新資料庫。

　　這種策略雖然打破了事務保證，但是效能要遠遠超過write-through，因為資料庫能夠快速批量更新，事務機制不再需要。