對於一個分層的系統當中，如果不同層之間存在速度不一致的問題，就會用到緩存技術，可以把一些需要經常訪問的數據放到緩存當中，這樣就可以增加加快訪問的速度
對於計算機系統中存在兩種緩存
1：LLC緩存：cpu中的末級緩存，用來存放內存中的數據，避免每次從內存中存取數據。
2：內存中的高速頁緩存，即page-cache，用來緩存內存中的數據，可以避免每次從磁盤中獲取數據
對於互聯網應用來說，就是redis是快速子系統，數據庫時慢速子系統
但是對於緩存來說，它的容量總是有限的，也也可以說明緩存的所能夠保存的數據量也很有限，所以對於互聯網應用來說，緩沖中的數據也必然會按照一定規則淘汰出去，寫會到后端子系統（為什么會寫會？）
同時讀取新的數據，再寫入到緩存。
Redis 本身是支持按一定規則淘汰數據的，相當於實現了緩存的數據淘汰，這也是 Redis 適合用作緩存的一個重要原因。
Redis 用作緩存時，我們會把 Redis 部署在數據庫的前端，業務應用在訪問數據時，會先查詢 Redis 中是否保存了相應的數據，
此時會有兩種情況：緩存命中：則讀取數據，返回成功
緩存確實：則需要讀取數據庫中的數據，並寫入緩存（但是這里就會有數據不一致性的問題，寫入緩存中的數據，如果進行修改操作，怎么通知緩存更新數據？）
redis是一個獨立的軟件，和業務應用程序是兩個軟件，當部署了 Redis 實例后，它只會被動地等待客戶端發送請求，然后再進行處理。所以，如果應用程序想要使用 Redis 緩存，我們就要在程序中增加相應的緩存操作代碼。所以，我們也把 Redis 稱為旁路緩存，也就是說，讀取緩存、讀取數據庫和更新緩存的操作都需要在應用程序中來完成。（引用）
通過在應用程序中加入 Redis 的操作代碼，可以讓應用程序使用 Redis 緩存數據了。除了可以從 Redis 緩存中查詢，讀取數據以外，應用程序還可能會對數據進行修改，對於我們來說就由兩種選擇，既可以在緩存中修改，也可以在后端數據庫中進行修改。
所以這里提供了兩種緩存實現方式：只讀緩存和讀寫緩存。只讀緩存能加速讀請求，而讀寫緩存可以同時加速讀寫請求。而且，讀寫緩存又有兩種數據寫回策略，可以讓我們根據業務需求，在保證性能和保證數據可靠性之間進行選擇。
下面介紹只讀緩存：
只讀緩存：當應用程序調用get接口，會查詢緩存中數據是否存在，而寫請求則會發往數據庫，在數據庫中增刪改，對於刪改的數據來說，如果 Redis 已經緩存了相應的數據，應用需要把這些緩存的數據刪除，Redis 中就沒有這些數據了。當下次讀取時會從數據庫當中讀，然后寫回到緩存中（這樣凡是修改過的數據下次必須要先從數據庫讀出，對於經常進行寫操作的程序來說，降低了redis的使用性能）。
讀寫緩存：
對於讀寫緩存來說，除了讀請求會發送到緩存進行處理（直接在緩存中查詢數據是否存在)，所有的寫請求也會發送到緩存，在緩存中直接對數據進行增刪改操作。此時，得益於 Redis 的高性能訪問特性，數據的增刪改操作可以在緩存中快速完成，處理結果也會快速返回給業務應用，這就可以提升業務應用的響應速度。但是redis是內存性數據庫，一旦出現掉電或宕機，內存中的數據就會丟失，應用的最新數據可能會丟失，給應用業務帶來風險。
所以提供了兩種將數據寫入數據庫的方式：
根據業務應用對數據可靠性和緩存性能的不同要求，我們會有同步直寫和異步寫回兩種策略。其中，同步直寫策略優先保證數據可靠性，而異步寫回策略優先提供快速響應。
同步直寫：寫請求發給緩存時，也會發給后端數據庫進行處理，等到緩存和數據庫都寫完數據（原子性），才給客戶端返回。這樣，即使緩存宕機或發生故障，最新的數據仍然保存在數據庫中，這就提供了數據可靠性保證。
但是缺點就是同步直寫會降低緩存的訪問性能。這是因為緩存中處理寫請求的速度是很快的，而數據庫處理寫請求的速度較慢。即使緩存很快地處理了寫請求，也需要等待數據庫處理完所有的寫請求，才能給應用返回結果，這就增加了緩存的響應延遲。
異步寫會策略：則將響應速度排在了第一位，此時，所有寫請求都先在緩存中處理。等到這些增改的數據要被從緩存中淘汰出來時，緩存才將它們寫回后端數據庫。這樣一來，處理這些數據的操作是在緩存中進行的，很快就能完成。只不過，如果發生了掉電，而它們還沒有被寫回數據庫，就會有丟失的風險了。