因為最近專案由於效能優化，引入了redis，但是隨之而來的是大家關於快取一致性問題的討論。接下來主要是想和大家來聊一聊關於這個快取一致性的帶來的問題和一些處理方式。
關於快取的讀取，沒猜錯的話，大家應該都是按照如下的流程進行業務處理的。
注：什麼是快取一致性的問題，其實就是我們最終落庫資料和我們快取中的資料不一致。
但是我們對於快取資料的更新方式上大家有各種處理方式，下面針對不同的處理，以及各自對應的缺陷進行一下總結。
1.設定過期時間
這種方案我們是為快取的key值設定失效時間，這種情況下不管我們資料庫資料怎麼折騰，最晚會在快取失效後，重新從資料庫中獲取最新的資料，載入到快取中。
優點：這種方式注重在最終快取內資料和資料庫中資料是一致的。
缺點：內容更新不及時。
我們通常將這個中方式用作後續講到方式的補充。
2.先更新資料庫，再更新快取
這種方案的問題在於，當有兩個或者多個執行緒同時進行資料更新時，會發生資料不一致的情況。流程如下圖：
由此可以看出，當執行緒1 先更新資料庫，但是由於網路等原因晚於執行緒2更新快取，最終導致的結果是快取資料的不一致。
2.先刪除快取，在更新資料庫
此方案問題在於，當有乙個執行緒讀取快取時，快取已經被另乙個更新執行緒刪除了，此時讀取執行緒會去資料庫查詢資料，並且放到快取中，此時更新執行緒還沒有完成資料庫的更新操作，依舊會出現快取一致性的問題。流程如下：
那麼這種情況我們可以解決嗎？可以 我麼你可以採用延遲雙刪的策略，在我們更新資料庫之後，延時一段時間，然後將快取再次刪除掉，這樣其他讀取執行緒再次讀取時候，還是會載入最新的資料。
3.先更新資料庫，再刪除快取。
可以看到此時資料庫和快取中的資料是一致的，有些朋友會問，難道這種情況就可以完全杜絕一致性問題嗎？答案不是的。如果我們的讀取資料庫資料在更新之前，並且更新快取資料在刪除快取之後，也同樣會出現一致性問題。流程如下:
如圖也會出現快取一致性問題，但是這種出現概率很小。原因如下：
通常我們讀取操作的耗時會明顯短於更新操作，所以即使先於更新讀取了資料，但是由於更新執行緒最終刪除了快取，所以下次在讀取時還會重新載入。流程如下
所以大部分公司會選擇這種更新方式。來最大限度避免一致性問題。
4.使用分布式鎖
有些朋友會說，我們使用分布式鎖是不是可以徹底解決這個一致性問題呢。答案是的。當我們在更新和讀取執行緒同時加鎖，我們會按照順序進行執行，這樣我們確實可以杜絕，但是為什麼好多公司不這麼做呢？答案是效率問題，因為加了鎖，在高併發的情況下，我們大量讀取快取的操作可能會因為鎖而排隊。
分布式事務了解嗎？你們是如何解決分布式事務問題的？
只要聊到你做了分布式系統，必問分布式事務，你對分布式事務一無所知的話，確實會很坑，你起碼得知道有哪些方案，一般怎麼來做，每個方案的優缺點是什麼。現在面試，分布式系統成了標配，而分布式系統帶來的分布式事務也成了標配了。因為你做系統肯定要用事務吧，如果是分布式系統，肯定要用分布式事務吧。先不說你搞過沒有...
在分布式環境中如何解決session共享問題
一 什麼是session session在計算機中，尤其是在網路應用中，稱為 會話控制 session物件儲存特定使用者會話所需的屬性及配置資訊。這樣，當使用者在應用程式的web頁面之間跳轉時，儲存在session物件中的變數將不會丟失，而在整個使用者會話中一直存在下去。二 產生session不一致...
分布式job如何解決冪等性問題
思考 分布式job如何解決冪等性問題？1 使用分布式鎖 zk redis 保證只有一台伺服器執行job 2 使用配置檔案，配置檔案開關，加乙個配置start true或者start false，如果為true 執行job，如果為false不執行job 集群就沒有作用 3 使用資料庫唯一標識 缺點 效...