什麼是在網絡服務器和應用程序服務器之間應用緩存層的好工具。緩存策略,以減少Web應用程序服務器上的負載
基本要求:
- 應用服務器需要一種方法來從緩存中刪除的項目,並把項目在緩存中的過期日期。
- Web服務器需要一種以非常輕量,快速的方式將項目從緩存中取出的方式,而無需在應用程序服務器上分配線程。
- 它並不一定需要是分佈式緩存(可從多臺機器訪問),但它不會傷害。
策略我已經考慮:
- 靜態文件緩存。請求進入,被哈希,如果我們提供了一個文件,如果沒有,我們將請求路由到應用服務器。是高I/O問題還是因併發導致文件鎖定問題?由於內存中的內核級高速緩存,文件系統實際上是否非常快速準確嗎?
- 使用鍵值數據庫,如mongodb或redis。這會將完成的HTML/JSON片段存儲在數據庫中。如果需要,網絡服務器將配備從數據庫讀取並路由到應用程序服務器。應用程序服務器將配備插入/刪除數據庫。
- 內存緩存像memcached或Varnish(不太瞭解Varnish)。我唯一關心的是memcached,我希望在任何給定的時間緩存3-10 GB的數據,這比我可以在內存中安全分配的要多得多。 memcached是否有一種方法泄漏到文件系統?
嘗試這種類型的緩存層時,有些技術和陷阱的想法?
Mongodb/redis可以輕鬆地緩存一些數據,尤其是來自SQL的查詢(這大致是Twitter對cassandra的處理)。通常我發現的一個很好的選擇是將半永久緩存(如MongoDB/redis)與memcached混合使用,在memcached中保留小熱量以提高速度,但通過在mongodb/redis中存儲更大的信息來提高速度 – Sammaye
服務數據之間沒有顯着差異來自memcache並從MongoDB/Redis提供服務,前提是後者在內存中有這些選項(MongoDB在數據足夠熱的時候做,但Redis並非100%,但我相信)。 memcache的另一個小問題是它是分佈式的,但不一定需要複製。如果一個memcache節點失敗,它將不得不重新啓動冷,這可能會導致你的問題。 –
如果相關,我不想緩存「數據」。在大多數情況下,緩存將被完整呈現HTML或HTML片段。這並不是真正意義上的減少SQL查詢的方法。這是減少整個應用程序堆棧上的負載,但將緩存層移動到Web服務器的一種方法。 – Nucleon