cache aside pattern
最經典的快取+資料庫讀寫的模式，就是 cache aside pattern。
讀的時候，先讀快取，快取沒有的話，就讀資料庫，然後取出資料後放入快取，同時返回響應。
三種方案如下：
為什麼是刪除快取，而不是更新快取？
原因很簡單，很多時候，在複雜點的快取場景，快取不單單是資料庫中直接取出來的值。更新操作開銷大多，而這一時段如果讀少則造成程式的開銷增大。
這種方案也是程式在用的，同時也是與程式松耦合的方案。針對資料庫更新成功，快取刪除失敗的情況，canal監控到變化則資料庫更新成功，快取刪除失敗增加了訊息佇列進行重試機制。
canal監控mysql的變化，如果資料更新，則進行刪除快取操作，如果刪除快取失敗，則把刪除操作放入訊息佇列中，自己進行消費該訊息進行刪除重試。
以及這種方案詳細內容**
更新資料庫的時候，根據資料的唯一標識，將操作路由之後，傳送到乙個 jvm 內部佇列中。讀取資料的時候，如果發現資料不在快取中，那麼將重新讀取資料+更新快取的操作，根據唯一標識路由之後，也傳送同乙個 jvm 內部佇列中。
即更新資料庫快取操作，讀取資料時（快取不存在）放到記憶體佇列中，同時讀取資料等待佇列處理超時問題（超時先查詢資料庫返回）
高併發的場景下，該解決方案要注意的問題：
超時返回，同時提前做好服務到壓測跟預估
nginx路由到相同服務事例上
更多詳細的介紹參看文章：
總結：
其實秒殺商品的庫存大部分都是存放到redis中，庫存只更新快取的。
先刪除快取再更新資料庫，存在快取擊穿問題（大量讀請求過來，都走了資料庫），同時增加了**複雜性。
先更新資料庫，再刪除快取，通過松耦合的情況，大部分場景能滿足。
當然特殊場景需要特殊策略對待。
Redis如何保證快取與資料庫的雙寫一致性？
原創 只要用快取，就可能會涉及到快取與資料庫雙儲存雙寫，你只要是雙寫，就一定會有資料一致性的問題 那麼，如何解決一致性問題？一般來說，如果允許快取可以稍微的跟資料庫偶爾有不一致的情況，也就是說如果你的系統不是嚴格要求快取 資料庫必須保持一致性的話，最好不要做這個方案。即 讀請求和寫請求序列化，串到乙...
如何保證快取與資料庫的雙寫一致性？
只要用快取，就可能會涉及到快取與資料庫雙儲存雙寫，你只要是雙寫，就一定會有資料一致性的問題，那麼你如何解決一致性問題？一般來說，如果允許快取可以稍微的跟資料庫偶爾有不一致的情況，也就是說如果你的系統不是嚴格要求 快取 資料庫 必須保持一致性的話，最好不要做這個方案，即 讀請求和寫請求序列化，串到乙個...
如何保證快取與資料庫的雙寫一致性？
如何保證快取與資料庫的雙寫一致性？你只要用快取，就可能會涉及到快取與資料庫雙儲存雙寫，你只要是雙寫，就一定會有資料一致性的問題，那麼你如何解決一致性問題？一般來說，如果允許快取可以稍微的跟資料庫偶爾有不一致的情況，也就是說如果你的系統不是嚴格要求 快取 資料庫 必須保持一致性的話，最好不要做這個方案...