目前各個大專案中多多少少用了寫redis快取技術，通過對redis中資料的讀取來減少對db的壓力。
那麼在讀、寫兩個分離的技術中就容易造成，資料庫和快取不一致的問題
當使用者在更新資料時，在第二個步驟還未執行，但是此時又通過獲取資料介面，此時快取已經刪除，但是資料庫中還是老資料，那麼就會將老資料重新寫入快取，就會導致快取和資料庫中資料不一致。
所以需要解決的方式
1、在讀資料的時候，資料庫中讀取的一定是最新的資料（可以通過分布式鎖實現）。
2、讀請求造成的髒資料能進行覆蓋或是刪除。
在寫資料的時候加入乙個，更新完資料庫後，再進行一次刪除快取的操作，具體延遲多久，就需要根據讀資料中獲取資料和寫入快取的這個時間估值
目的：確保讀請求結束，寫請求可以刪除讀請求造成的快取髒資料。
通過更新資料後，告知乙個非同步訊息佇列或是非同步任務進行更新快取，只要更新執行完成，就對快取進行乙個重新讀取資料庫（或是通過解析binlog）然後快取更新的操作。實現最終一致性。
缺點：可能某個時間快取一直不存在，導致資料都從資料庫中獲取。
寫和讀進行序列化，通過分布式鎖，更新資料時通過加鎖，直到更新資料完成，讀取資料時，若快取為空，則通過分布式鎖（讀寫共用），獲取到鎖之後，再進行讀取資料庫，再寫入快取。
確保了資料庫中讀取的資料一定是最新資料。
快取不一致
當程式在執行過程中，會將運算需要的資料從主存複製乙份到cpu的快取記憶體當中，那麼cpu進行計算時就可以直接從它的快取記憶體讀取資料和向其中寫入資料，當運算結束之後，再將快取記憶體中的資料重新整理到主存當中。舉個簡單的例子 i i 1。當執行緒執行這個語句時，會先從主存當中讀取i的值，然後複製乙份到...
執行緒資料不一致例項
package kkkk public class sharedata private static class sharethread1 implements runnablecatch interruptedexception e private static class sharethread...
version magic 不一致問題
碰到乙個問題，在開發過程中發現以前編譯的模組載入失敗了。wlan version magic 4.1.15 gfb2dbf6 smp preempt mod unload armv7 p2v8 should be 4.1.15 ge5de83b dirty smp preempt mod unloa...