系統架構設計:程序快取和快取服務,如何抉擇?
阿新 • • 發佈:2020-11-03
概述
我們所說的快取分為程序內部快取(系統內部快取)和 快取服務(如redis/memcache)。計算機服務從原來的單體結構,到多例項,到現在流行的微服務,快取服務變得原來越流行了。程序快取
先說說程序快取,它將資料儲存在站點、服務的程序內。在Web的發展歷史上,這樣的方式備受歡迎。比如早期常用的.Net的 System.Web.Caching. 這種實現載體很簡單,比如一個帶鎖的HasTable,或者一個List物件。 使用簡單便捷,能儲存資料、html頁面片段、檔案,甚至任何物件。 在單體結構的Web模式下,程序內快取被開發到極致,大概流程如下圖:程序快取的問題
如上圖,但是有個問題,Cache1、Cache1、Cache3一致性難以保障,如果想保持快取的一致性時,該怎麼辦呢? 一般有以下幾種方法: 1、單一服務節點通知其他服務節點,如果我們只是Web Service1 在執行業務操作的時候修改資料庫,更新快取,同時通知其他Web Service 服務,其他Web Service 接收到資訊的時候,進行快取更新。
2、 啟動MQ通知其他節點:如下圖,可以通過MQ通知其他節點。寫請求發生在server1,在修改完自己快取資料與資料庫中的資料之後,給MQ生產資料變化通知, server2和server1訂閱MQ訊息,當消費到MQ資訊的時候,也修改快取資料。
3、有一種簡單的方式,也可以解耦與Web Server的關係,就是直接放棄了“實時一致性”,啟動一個獨立的程序服務,定時從後端拉取最新的資料,更新記憶體快取。
上述的幾種方法為了保持資料的一致性,增加了一定的開銷,一方面快取資料同步過程中會有出錯的風險;
另一方面實際上違背了快取的原則:冷熱資料隔絕,有效的利用冷資料,減輕資料庫壓力,提升效率。如果快取被頻繁修改或者同步,那快取的價值就不大了。 所以我們在以下這幾種情況下拋棄程序快取,選用快取服務: 1、Web叢集下,包含多個例項,並且不允許業務資料的不一致性(我相信大部分業務不允許) 2、程序內快取資料量較大,快取記憶體空間不足,影響Web效能,可以考慮走快取服務(快取服務如redis,一般獨立服務甚至叢集配置,支援超大量級)。 3、評估value大小、快取記憶體空間、峰值QPS、過期時間、快取命中率、讀寫更新策略、key值分佈路由策略、過期策略以及資料一致性方案,根據實際需要判斷是否走快取服務。快取服務
在網際網路分層架構中,最常用的kv結構的快取是redis。他有如下特點: