如何保證redis快取和資料庫中資料的一致性
方案一：先刪除快取，再跟新資料庫
併發情況下，乙個更新，乙個查詢，更新操作刪除快取後，查詢操作沒有命中快取，先把老資料讀出來後放到快取中，然後更新操作更新了資料庫。於是，在快取中的資料還是老的資料，導致快取中的資料是髒的，而且還一直這樣髒下去了。
方案二：先更新資料庫，再刪除快取
乙個是讀操作，但是沒有命中快取，然後就到資料庫中取資料，此時來了乙個寫操作，寫完資料庫後，讓快取失效，然後，之前的那個讀操作再把老的資料放進去，所以，會造成髒資料。
因為寫和讀是併發的，沒法保證順序，如果刪除了快取，還沒有來得及寫庫，另乙個執行緒就來讀取，發現快取為空，則去資料庫中讀取資料寫入快取，此時快取中為髒資料。如果先寫了庫，在刪除快取前，寫庫的執行緒宕機了，沒有刪除掉快取，則也會出現資料不一致情況。
方案三 ：跟新資料時 只更新快取，然後通過非同步排程去批量更新資料庫
快取雪崩：由於原有的快取過期失效，新的快取還沒有快取進來，有乙隻請求快取請求不到，導致所有請求都跑去了資料庫，導致資料庫io、記憶體和cpu壓力過大，甚至導致宕機，使得整個系統崩潰。
解決思路：
1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓力，但是同時又降低了系統的吞吐量。
2，分析使用者行為，盡量讓失效時間點均勻分布。避免快取雪崩的出現。
3，如果是因為某台快取伺服器宕機，可以考慮做主備，比如：redis主備，但是雙快取涉及到更新事務的問題，update可能讀到髒資料，需要好好解決。
加鎖：加鎖排隊只是為了減輕資料庫的壓力，並沒有提高系統吞吐量。假設在高併發下，快取重建期間key是鎖著的，這是過來1000個請求999個都在阻塞的。同樣會導致使用者等待超時，這是個治標不治本的方法。
publicclasscachedemo
else
else
}
returncachevalue;
}
}
}
快取失效：
快取標記：記錄快取資料是否過期，如果過期會觸發通知另外的執行緒在後台去更新實際key的快取。
快取資料：它的過期時間比快取標記的時間延長1倍 ，例：標記快取時間30分鐘，資料快取設定為60分鐘。 這樣，當快取標記key過期後，實際快取還能把舊資料返回給呼叫端，直到另外的執行緒在後台更新完成後，才會返回新快取。
這樣做後，就可以一定程度上提高系統吞吐量。
publicobjectgetproductlistnew()
else
);
returncachevalue;
}
}
快取穿透：
快取穿透是指使用者查詢資料，在資料庫沒有，自然在快取中也不會有。這樣就導致使用者查詢的時候，在快取中找不到，每次都要去資料庫再查詢一遍，然後返回空。這樣請求就繞過快取直接查資料庫，這也是經常提的快取命中率問題。
解決思路：
1，如果查詢資料庫也為空，直接設定乙個預設值存放到快取，這樣第二次到緩衝中獲取就有值了，而不會繼續訪問資料庫，這種辦法最簡單粗暴。
2，根據快取資料key的規則。例如我們公司是做機頂盒的，快取資料以mac為key，mac是有規則，如果不符合規則就過濾掉，這樣可以過濾一部分查詢。在做快取規劃的時候，key有一定規則的話，可以採取這種辦法。這種辦法只能緩解一部分的壓力，過濾和系統無關的查詢，但是無法**。
3，採用布隆過濾器，將所有可能存在的資料雜湊到乙個足夠大的bitset中，不存在的資料將會被攔截掉，從而避免了對底層儲存系統的查詢壓力。關於布隆過濾器，詳情檢視：基於bitset的布隆過濾器(bloom filter)
大併發的快取穿透會導致快取雪崩。
publicobjectgetproductlistnew()
else
cachehelper.add(cachekey, cachevalue, cachetime);
returncachevalue;
}
}
把空結果，也給快取起來，這樣下次同樣的請求就可以直接返回空了，即可以避免當查詢的值為空時引起的快取穿透。同時也可以單獨設定個快取區域儲存空值，對要查詢的key進行預先校驗，然後再放行給後面的正常快取處理邏輯。
快取預熱
快取預熱就是系統上線後，將相關的快取資料直接載入到快取系統。這樣避免，使用者請求的時候，再去載入相關的資料。
解決思路：
1，直接寫個快取重新整理頁面，上線時手工操作下。
2，資料量不大，可以在web系統啟動的時候載入。
3，定時重新整理快取
分布式事務解決方案
一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性，分為三個階段tryi...
分布式事務解決方案
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...
分布式事務解決方案
由於資料量的巨大，大部分web應用都需要部署很多個資料庫例項。這樣，有些使用者操作就可能需要去修改多個資料庫例項中的資料。傳統的解決方法是使用分布式事務保證資料的全域性一致性，經典的方法是使用兩階段提交協議。長期以來，分布式事務提供的優雅的全域性acid保證麻醉了應用開發者的心靈，很多人都不敢越雷池...