1 業務場景
在電商系統中，随着使用者增多，系統中的并發也會逐漸增大。再者，電商系統為了能夠吸引使用者，經常會搞一些秒殺啊，促銷啊，店慶之類的活動，這類活動價格相對比較合适，是以參與的人就會越來越多，系統中的并發也會上去，這樣就會給傳統的資料庫架構造成比較大的沖擊，甚至會出現cpu100%，連接配接數不夠用等情況。
在上述問題出現後，大家就想盡各種方法去減輕資料庫的壓力。什麼分流啊，緩存啊，這些方案就搬到桌面上來了。分離這個我們在網關的那一節中已經着重的介紹了，後面我們還會介紹一下限流，熔斷之類的場景。今天我們着重說一個緩存，大家第一反應是redis，cache 等。
緩存在使用的時候，最容易出現資料不一緻的情況，也是本節重點要講解的架構設計和實戰。
2 緩存的分類
緩存的種類多種多樣，就目前而言，可以分為以下幾個大類
- 用戶端緩存: 頁面緩存，app緩存
- 服務端緩存：redis，memcache,spring cache
- 網絡緩存：CDN
從浏覽器到網絡，再到伺服器，最後到資料庫中，我們都能看到緩存的影子。有了緩存之後，服務的整體的性能會提升，同時我們可以對自己的後端服務進行保護。
3 緩存更新方案
上面我們提到過，使用緩存最重要的是保證資料的一緻性。查詢的時候，緩存中有資料就從緩存中取，緩存中沒有就查詢資料庫。這樣就會出現一些比較經典的問題，緩存穿透，緩存雪崩等。
關于緩存的更新方案主要有以下幾種
3.1 先更新緩存，再更新資料庫
這個方案，容易出現緩存更新成功，資料庫更新失敗的情況，這樣會導緻資料不一緻。比較緻命的是，一旦緩存失效，就會造成資料的丢失！是以不會使用這個。
3.2 先更新資料庫，再更新緩存
這個跟上面的很類型，非常大機率的造成資料的不一緻，是以也不推薦使用。
3.3 先删除緩存，再更新資料庫
這個地方就會存在一個時間差的問題，如果資料庫的資料同步成功之前，有人更新了緩存，那麼就會導緻緩存中的資料還是舊的資料，也會導緻資料不一緻。
解決這個問題，比較常用的方式是：
1 緩存雙删除（更新前删除一次，更新成功後删除一次）。
2 強制緩存查詢的時候，查詢主庫的資料，這樣可能會導緻資料庫崩潰。
如果遇到緩存雪崩的情況下，資料庫的性能和壓力還是會面臨比較大的考驗的。
3.4 先更新資料庫，再删除緩存
既然，上面的三種都有問題，難道這種就是完美的解決方案了？NO,這個也是會有問題的。
從理論的角度看，還是會存在資料不一緻的情況。雖然機率非常小，為啥機率小，大家想一下，讀取的時間肯定是比更新的時間要快的，不然搞啥讀寫分離呢！
如果一定要解決呢，目前我們的技術架構是這樣的：
我們加了一個定時任務的兜底方案，将删除緩存失敗的情況，再進行一次删除操作，這樣就能保證資料的一緻性了。
當然，這個地方還有其他的實作方案，比如使用隊列，redis 等，一定要結合自己的業務系統取實作。
4 總結
在高并發的場景下，緩存的重要性不言而語，對資料不一緻的情況，我們也是要采取零容忍的态度。随着技術的發展，方案也會越來越優化，前提是一定要在自己的業務系統上進行演進。