在設計count快取過程中遇到的一些問題，現總結如下，望共勉：
1. 在分布式併發情況下如何考慮原子性操作？
使用memcache的計數器實現
2. memcache的計數器沒有失效時間的概念，如何納入失效時間？
另外使用儲存乙個cache，用它的失效時間作為快取計數器的失效時間，該cache失效則計數器刪除
3. 如果計數器未命中（查詢時未命中則返回0，更新快取時未命中則返回-1）會如何？
有兩種情況：第一，如果查詢列表時計數器未命中：
解決方案：將list查詢提到count前面，如果list查詢有值，而從快取總取出的count為0，則count重查資料庫
第二，更新時計數器未命中（此時更新後的計數器會不準確，但是查詢時可能仍會命中，count不會重新走資料庫，則導致list的長度與count值不一致）：
解決方案：在更新時如果計數器未命中，則認為計數器失效，count重查資料庫
4. 如果用於儲存失效時間的cache未命中該如何？
如果未命中則同樣認為計數器失效，刪除計數器，重查資料庫
上面的第3、4點是上週沒有發現的，這週我重新審查了一下自己寫的**發現還有這些問題，究其原因是在設計這塊的時候根本就沒有
考慮到memcache作為快取的諸多特性，希望大家在以後的寫**的時候，尤其是在寫公共模組的時候，能夠充分的去了解自己所用技術
的原理，尤其是該技術需要注意的地方。
快取問題總結
概述 快取是分布式系統中的重要元件，主要解決高併發，大資料場景下，熱點資料訪問的效能問題。提供高效能的資料快速訪問。1 快取穿透 訪問乙個不存在的key，快取不起作用，請求會穿透到db，流量大時db會掛掉。解決的辦法 1採用布隆過濾器，使用乙個足夠大的bitmap，用於儲存可能訪問的key，不存在的...
快取常見問題總結
1.現象 request請求在cache中未找到資料，直接查詢storage 2.原因 2.1業務 自身問題 在資料庫中未找到資料，進入死迴圈 2.2惡意攻擊 爬蟲等 大量不存在資料查詢資料庫，進入死迴圈 3.如何發現 3.1業務響應時間 3.2業務本身問題 4.解決方法 4.1快取空物件 儲存層返...
快取設計需要考慮的問題
前言 沒有一種快取方案可以解決一切的業務場景或資料型別，我們需要根據自身的特殊場景和背景，選擇最適合的快取方案 一.是否需要使用快取 需要使用快取的業務場景 比如前台頁面展示，購物車 二.快取物件的粒度 一種資料乙個物件，簡單，讀取寫入都快，但是種類一多，快取的管理成本就會很高 多種資料放在乙個集合...