在高併發的系統中關於快取的重要性不言而喻，快取在專案當中大量使用，扛住了大部分的查詢流量，但也有很多點需要注意，最為典型的例子就是資料一致性問題，快取擊穿問題，快取高可用問題等等。這次需要解決的問題是乙個秒殺場景的高併發問題。
快取一致性就是說db的資料與快取的資料保持一致，理論上同一瞬間去變更兩個值是最理想的，訪問快取跟db是一致的，但是在分布式的情況下，無論如何操作，更新db與快取是存在間隙的。並且在結合實際情況下的多執行緒環境，那問題將更加複雜，我們可以簡單回顧下這幾種場景下不一致的原因。
秒殺是在瞬間極高的流量，無論是查詢或則更新庫存的流量都存在瞬間峰值，我們當然引入了快取這種中介軟體支撐整個系統，redis是比較流行的一種記憶體資料庫，我們一般用來做快取中介軟體，也是採用了先更新db再刪除快取的方案，這種方案是盡量保證實時資料一致性，因此效能開銷並不低，考慮到實際情況庫存業務上游大流量感知的更多是關心的是有或則無的狀態，理論上，返回給乙個布林值就能支撐業務。秒殺情況下，db在頻繁更新庫存的時候也在頻繁的刪除快取，這個時候使用者也在頻繁的查詢是否還有庫存，這些併發的查詢流量都形成了快取穿透。
在秒殺的極端情況下，db的壓力陡然增加，因此需要另闢蹊徑找到快取更高效的方案.
在我印象中binlog主要是用來主從同步與高可用資料恢復等等操作的用途，主要是給dba用的，其實還可以應用在一些其他的場景，快取就是其中的乙個場景，可以用來非同步做很多解耦的事情。其實這種方案並不多，可能因為其非同步的特性，存在延遲，但是這個問題我通過其他方式規避了。
作為高併發系統，不用在同步失效快取，進一步降低介面rt
應用解耦，不強依賴redis。
分散在業務**各處的更新快取操作可以收斂在乙個地方，業務**更加簡潔。
快取不再失效，有效解決高併發查詢流量快取擊穿問題。
強依賴binlog與訊息中介軟體的可用性與延遲.
資料存在延遲性與不一致的概率增加。
根據cap與base理論與實際業務，保證最終一致性（順序訊息）是最佳的方案，上游僅僅需要感知庫存不足的情況下的庫存，因此這裡作業特殊邏輯，在庫存不足的時候立即更新快取為db的最新值，但是這樣仍然存在乙個問題，延遲的訊息可能仍然將老的值覆蓋進來，這就需要丟棄，因此每條庫存記錄都存在乙個遞增版本號。每次訊息的消費都會判斷當前快取的版本號與訊息的版本號的大小，如果小於丟棄即可，但是仍然存在乙個問題由於在判斷版本大小之後和在更新快取之前，這個「縫隙」**做了一些可能存在高耗時的操作，因此再更新快取之前可能當前訊息仍存在「是延遲訊息」的風險，因此需要塞之前做二次判斷，盡量保證資料一致性。
涉及到訊息的監聽，建訊息和應用的發布先後順序需要考慮。
先發**，再建立訊息，落在發布機器上 所有扣減的庫存的地方快取不會失效，訊息監聽可能落在其他的未發布的集群，不會重新整理快取，所以有問題。
如果先發訊息、再發布**，因為發布**是乙個灰度發布的過程，依舊存在問題1的問題。
可以通過加開關的方式，先發布所有**，再建訊息，再開開關，全部失效快取的地方不失效，但這樣存在比較大的風險，因為每一步都是全流量驗證.
分兩次發布，先發布**讓監聽訊息的地方都去重新整理快取。
第一次發布：扣庫存邏輯不變，都會失效快取，老機器監聽訊息沒問題，新機器監聽無非多重新整理一次快取，沒問題。
第二次發布：扣庫存邏輯不會失效快取，新老機器監聽訊息已經會重新整理快取，沒問題。
看了此篇文章是不是感覺收穫蠻大
微信小程式快取 本地快取，同步快取，非同步快取
1.wx.setstorage wx.setstoragesync wx.getstorage wx.getstoragesync wx.clearstorage wx.clearstoragesync 可以對本地快取進行設定 獲取和清理。本地快取最大為10mb 2.localstorage 是永久...
高併發的實現（非同步化 快取 多執行緒）
一年前，本人有幸負責公司核心專案的優化。隨著公司業務的增長，專案處理量也越來越大。一次818大促甚至導致一台伺服器滿負荷運作。於是，高併發改造被提上日程。乾貨開始 技術實現上有三個重點 非同步化 一般使用mq 快取 一般使用redis 多執行緒 乙個功能併發量上大的提公升，是需要業務和技術上共同去努...
10 1 2 使用記憶化快取結果
10.1.2 使用記憶化快取結果 記憶化 memoization 可以描述為快取函式呼叫的結果，聽起來可能有點複雜，但是，技術非常簡單。正如我們前面提到的那樣，在函式式程式設計中，大多數函式是沒有 的，因此，如果我們用相同的引數值，兩次呼叫同乙個函式，得到的結果相同。如果我們要得到與上一次相同的結果...