程序內快取的缺陷和解決方法
程序內快取的適用場景
什麼是程序內快取
例如：帶鎖的map
level級別的db
具有的優勢
與沒有快取的比較：
有了程序快取可以加速資料訪問，不用查詢資料庫
與快取集群比較
節省內網頻寬
時延更低
程序內快取的缺陷和解決方法
最嚴重的問題：快取一致性問題
資料的冗餘必然造成一致性問題，而程序內快取是每乙個程序乙份快取，不同快取之間會有一致性問題
解決方案主要有三個：
1 單節點通知
當乙個程序內的快取資料修改的時候它就向它的兄弟節點廣播修改的資訊，通知它們與它修改的內容的同步
缺點：
各節點緊耦合
實現複雜，程序要關注本身不需要關注的內容
通訊量大
2 使用mq解耦
節點不是向其它節點廣播通知，而是將修改資訊發布到mq上
3 放棄實時一致性，程序定時同資料庫同步
如果業務側可以忍受短暫的不一致，那麼可以使用最終一致性的方案，上面兩個方案可以做成最終一致性也可以做成強一致性，但這一方案肯定是最終一致的
程序更新資料庫後沒有任何其它操作
所有程序內的快取會定時通過資料庫來更新自己的資料
程序內快取的適用場景
不應頻繁的使用程序內快取！
它違背了「站點無狀態，服務無狀態」的設計準則
可以考慮使用的場景：
唯讀資料
併發極高，透傳後端資料壓力很大
允許一定程度上的資料不一致
大部分場景下，我們還是會選擇使用 redis / memcache這樣的快取集群
小白聊架構師 怎麼成為架構師
還有人說 我早就掌握了物件導向設計，也看了 企業應用架構模式 架構之美 大型 技術架構 等等架構的書，為啥還當不了架構師？是啊，這高階，大氣，上檔次的架構師是怎麼煉成的？這裡講乙個小王的故事吧。又到了畢業季，一批應屆生進了乙個軟體公司，小王也在其中。新人進入公司，基本上都是從最底層做起，做那些最髒最...
程序內快取分析
1.除了常見的redis memcache等程序外快取服務，快取還有一種常見的玩法，程序內快取，將一些資料快取在站點，或者服務的程序內，這就是程序內快取。2.程序內快取的實現載體，最簡單的，可以是乙個帶鎖的map。又或者，可以使用第三方庫，例如leveldb 3.與程序外快取相比 例如redis m...
架構師之路 快取與資料庫
一 更新快取vs淘汰快取 1 更新快取 資料不但寫入資料庫，還會寫入快取。優點 快取不會增加一次miss，命中率高。2 淘汰快取 資料只會寫入資料庫，不會寫入快取，只會把資料淘汰掉。優點 簡單。3 如何選擇呢 更新的代價不是太大則更新快取，否則淘汰快取。二 先運算元據庫vs先操作快取 1 如何選擇 ...