前言
沒有一種快取方案可以解決一切的業務場景或資料型別，我們需要根據自身的特殊場景和背景，選擇最適合的快取方案
一.是否需要使用快取
需要使用快取的業務場景
比如前台頁面展示，購物車
二.快取物件的粒度
一種資料乙個物件，簡單，讀取寫入都快，但是種類一多，快取的管理成本就會很高；多種資料放在乙個集合物件裡，方便，一塊全出來了，想用哪個都可以，但是如果只要一種資料就會造成網路頻寬的浪費和傳輸的延遲。
三.快取資料結構選擇
四.快取的更新策略
1.被動失效
思路失效後再去讀取時，如果發現資料過期了或者不存在了，那麼就重新去資料庫讀取，然後更新到快取中
方式設定快取過期時間
資料庫更新後刪除快取
定期刪除快取
問題從快取失效開始到新的資料再次被更新到快取中的這段時間，所有的讀請求都將會直接落到資料庫上
資料庫更新後刪除快取的步驟
先刪除快取，再更新資料庫 問題：對快取刪除完之後，有乙個讀請求，這個時候由於快取被刪除所以直接會讀庫，讀操作的資料是老的並且會被載入進入快取當中，後續讀請求全部訪問的老資料。
先更新資料庫，再刪除快取（推薦） 問題：極小概率依然會出現資料庫快取資料不一致的情況
2.主動更新
思路當資料庫資料更新時，主動更新快取
純記憶體資料庫必須採用主動更新！！！
方式事務的最後
事務之後
非同步問題
多個併發的請求更新資料，無法保證更新資料庫的順序和更新快取的順序一致，那就會出現資料庫快取中資料不一致的情況
五.快取的查詢策略
1.快取擊穿
發生場景
熱點key的過期引發
新功能上線
解決方法
加分布式鎖
快取到期時自動重新整理
熱點key採用邏輯過期，物理不過期（當發現超過邏輯過期時間後，會使用單獨的執行緒去構建快取，重構快取期間，會出現資料不一致的情況）
資料庫訪問限流
2.快取穿透
發生場景
惡意攻擊
正常業務查詢
解決方法
快取空物件（需要在插入快取的時候先刪除這個空快取，可以通過設定較短的過期時間來解決這個問題）
布隆過濾器（需要針對具體資料情況設定引數，盡量保證布隆過濾器的可靠性）
3.快取雪崩
發生場景
同一時間大量key過期
當redis服務不可用時
新功能上線
解決方法
快取的過期時間可以取個隨機值，盡量讓不同key的過期時間不同
資料庫訪問限流（總的訪問限流,根據key的型別限流，根據具體的key限流 限流實現不使用redis）
六.其他注意點
快取一定要支援從資料庫刷入
監控快取的大小，超過閾值後進行快取清除（三種演算法：lru/lfu/fifo）
出現資料不一致時的方案
無底洞問題
設計快取架構時需要考慮的因素總結
在設計架構快取的時候，首先要選定快取元件，比如要用local cache，還是redis memcached pika等開源快取元件。如果業務快取需求比較特殊，還要考慮是直接定製開發乙個新的快取元件，還是對開源快取進行二次開發，來滿足業務需要。確定好快取元件後，要根據業務訪問的特點，進行快取資料結構...
設計到底需要考慮什麼
設計到底需要考慮什麼by kangtian0 c 的具體背景知識 物件導向和設計模式經典書籍的閱讀 軟體開發技術管理者的精心結晶薰陶。一直認為做物件導向的軟體設計，自己的能力已經完全沒有問題。但是總歸還沒有做乙個真正專案的設計，還是有點心虛。自己很自信，但是別人問用沒用這些學過的知識的時候，還是啞口...
設計一款DLL殼需要考慮的問題
先說前一點，在內存中不確定的位置意味著重定位表是必須的。第二點，程式入口點，如你所知，程式入口點在pe結構中optional addressofentrypoint表示是乙個rva位址，即相對虛擬位址 relative virtual address 詳見pe結構介紹文章。entrypoint 入口...