關於不一致的問題：
一般情況下，我們都是先同步資料庫，然後再刪除redis，當刪除redis時出問題了，這樣就會出現不一致問題
於是，我們可以先刪除快取，再同步到資料庫。這樣，保證下次訪問時候，先訪問redis，沒有資料，則請求db，保證了redis與db的一致。當出錯了，至少不會出現超賣現象，但是使用者體驗感很差
這樣做會出現問題，那就是下一次訪問，db還沒更新完成，redis請求到沒有更新的db，這樣redis依舊會儲存的舊資料。
於是可以引入雙刪，寫之前刪除redis一次，db寫入完後再刪除一次redis，但這樣的操作代價較高
於是，可以在redis中引入佇列，佇列的容量與商品容量一致，同時將後續的讀請求壓入佇列中，滿則不再允許再進入請求，這樣對佇列乙個個處理，可以防止超賣問題，解決了資料不一致問題
但是這樣會出現問題，許多讀請求放入佇列，大量的請求會導致佇列溢位，這樣會給快取帶來壓力，於是可以在redis快取佇列中做請求去重，如果一致的請求，佇列中存放乙個請求任務。
為了防止乙個使用者拍多件商品，應該引入乙個使用者id集合在redis中，去除同一使用者的多搶購問題。
針對使用者體驗感問題，只要使用者任務入隊，則返回成功提示，剩下的訂單更新任務則繼續執行。
對於佇列中的任務，我們可以使用多執行緒進行處理，使用執行緒池加同步鎖加快處理。
如何再進行優化系統？個人理解如下
在應對大流量問題上，首先在硬體方面，申請足夠的頻寬，並使用集群進行應對，
在redis前進行過濾或者校驗，防止惡意重複ip攻擊，造成快取穿透或者擊穿，並配置過期策略
通過定時同步的方法，解決快取更新和失效問題，也可以做預熱處理
使用nginx進行負載，把請求均勻分發到每個tomcat中
使用分表技術，並對大流量進行一定的限流
前端優化使用cdn技術
以上是個人的一些理解，如有問題，懇請指正
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...
ceph pg不一致問題
今天在公司環境中出現了pg不一致問題，通過ceph health detail命令檢視如下 pg 19.211 is active clean inconsistent,acting 88,16 pg 19.214 is active clean inconsistent,acting 59,36 ...
快取不一致
當程式在執行過程中，會將運算需要的資料從主存複製乙份到cpu的快取記憶體當中，那麼cpu進行計算時就可以直接從它的快取記憶體讀取資料和向其中寫入資料，當運算結束之後，再將快取記憶體中的資料重新整理到主存當中。舉個簡單的例子 i i 1。當執行緒執行這個語句時，會先從主存當中讀取i的值，然後複製乙份到...