一、重客戶端
寫入快取：
應用同時更新資料庫和快取
如果資料庫更新成功，則開始更新快取，否則如果資料庫更新失敗，則整個更新過程失敗。
判斷更新快取是否成功，如果成功則返回
如果快取沒有更新成功，則將資料發到mq中
應用監控mq通道，收到訊息後繼續更新redis。
問題點：如果更新redis失敗，同時在將資料發到mq之前的時間，應用重啟了，這時候mq就沒有需要更新的資料，如果redis對所有資料沒有設定過期時間，同時在讀多寫少的場景下，只能通過人工介入來更新快取。
讀快取：
如何來解決這個問題?那麼在寫入redis資料的時候，在資料中增加乙個時間戳插入到redis中。在從redis中讀取資料的時候，首先要判斷一下當前時間有沒有過期，如果沒有則從快取中讀取，如果過期了則從資料庫中讀取最新資料覆蓋當前redis資料並更新時間戳。具體過程如下圖所示：
二、客戶端資料庫與快取解耦
上述方案對於應用的研發人員來講比較重，需要研發人員同時考慮資料庫和redis是否成功來做不同方案，如何讓研發人員只關注資料庫層面，而不用關心快取層呢?請看下圖：
應用直接寫資料到資料庫中。
資料庫更新binlog日誌。
利用canal中介軟體讀取binlog日誌。
canal借助於限流元件按頻率將資料發到mq中。
應用監控mq通道，將mq的資料更新到redis快取中。
可以看到這種方案對研發人員來說比較輕量，不用關心快取層面，而且這個方案雖然比較重，但是卻容易形成統一的解決方案。
最終一致性方案
訊息傳送一致性 微服務架構下，需要通過網路進行通訊，就自然引入了資料傳輸的不確定性，也就是cap原理中的p 分割槽容錯，而這裡的訊息傳送一致性是可靠訊息的保證。生成訊息的業務動作與訊息傳送的一致 e.g 如果業務操作成功，那麼由這個業務操作所產生的訊息一定會成功投遞出去，否則就丟失訊息 如上圖，保證...
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
快取一致性
一般應用而言，追求的都是快取的最終一致性。一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢 比如db 如果key對應的value是一定不存在的，並且對該key併發請求量很大，就會對後端系統造成很大的壓力。這就叫做快取穿透。引起這個問題的主要原因還是高併發的時...