——僅供個人學習使用，如有侵犯版權，請作者聯系我，立馬處理。

【前端頁面緩存】 sessionStorage,localStorage,userData,cookie,
[sessionStorage]
h5后出現的新技術，這個生命周期短，當頁面關閉后，存儲資源即被釋放。可存儲體積也較大。對于不同的網站，數據存儲于不同的區域，并且一個網站只能訪問其自身的數據。注：頁面刷新，或disable cache，存儲資源還在，只有當頁面關閉后才沒有。
[localStorage]
與sessionStorage唯一區別是，存儲生命周期。它是長久存儲在瀏覽器中，沒有時間限制, 不清除就會一直存在。它不是存儲在瀏覽器中，存儲在本地。它按域名存儲，存儲大小大概是5m缺點是兼容性中等，ie9、ie10不支持,不能跨瀏覽器讀取的。
[userData]
這個是比較老的存儲技術，有兼容問題，Ie支持
[cookie]
這個兼容性最好，應用也最廣泛，現在大多登陸校驗都用這個。特點是：每次向服務器發請求，請求頭都會帶cookie，存儲大小有限制
[openDataBase]
其實就是一個本地數據庫，缺點是對前端開發成本高。它存儲在本地

【頁面片段緩存】
場景介紹：https://www.cnblogs.com/yuyijq/archive/2011/05/07/fragment_cache_one.html

一般，頁面上會分為很多部分，而不同的部分更新的頻率是不一樣的。如果對整個頁面采用統一的緩存策略則不太合適，
而且很多系統的頁面左上角都有一個該死的“Welcome XXX”。這種特定于用戶的信息我們是不能緩存的。對于這些情況我們就需要使用片段緩存了。對頁面不同的部分（片段）施加不同的緩存策略，而要使用片段緩存，首先就得對頁面進行切分。土一點的辦法可以用iframe，用iframe將頁面劃分為一塊塊的，不過我總覺得iframe是個邪惡的東西。好點的辦法可以用Ajax單獨的請求這個片段的內容然后再填充，看起來挺美好的。不過使用Ajax也有一些限制：
1、如果頁面上有許多片段，使用太多的這種技術，會有很多請求發送到服務器，HTTP對同一個域名有連接的限制，這樣會降低并發連接的效率。
2、如果說第一個不是什么問題，那么還有一點可能對用戶體驗不友好。比如有一個片段可能響應慢點，造成頁面閃爍。不過如果前面兩點都可以克服，這個方案還是可以的。可惡的是我們的客戶（此處省略500字），說他們的大多數用戶處于一個禁用JavaScript的環境里。好吧，這個方案也不能使用了。

成熟的頁面片段緩存技術-：ESI（Edge Side Include） https://www.cnblogs.com/yuyijq/archive/2011/05/08/fragment_cache_two.html

使用Velocity自定義標簽的方案工作在應用程序這一層，這樣開發人員有最大的控制權力，而且實現起來也比較簡單，所使用的也都是大家都熟悉的技術，但問題是它還是由應用程序服務器來處理得，可以說它減輕了一部分應用程序服務器和數據庫服務器的壓力，但還有一部分壓力還是需要它來承擔，而且在應用程序中解決所使用的緩存必定是和應用程序所采用的緩存機制一樣（當然你也可以為此獨立使用一個緩存），對緩存服務器也有部分壓力。
而使用ESI的方案，它需要運維團隊的配置，甚至需要修改服務器配置的架構（添加了前端服務器），如果在多部門協調比較困難的項目中，這種方案還會遇到一些阻力。
但是它帶來的好處確實顯而易見的。首先ESI是一個W3C標準，我更傾向于采用標準的做法。而且Varnish這樣的方向代理，它本來就擅長這個，它可以完全把這部分壓力從應用程序服務器和緩存服務器上接管過來，而且會處理的更出色。

【數據緩存】https://mp.weixin.qq.com/s/rD6hln8bSLW07lNAgOmZ1g
[解決的問題] 緩存是分布式系統中的重要組件，主要解決高并發，大數據場景下，熱點數據訪問的性能問題。提供高性能的數據快速訪問。
[原理]將數據寫入讀寫更快的存儲、離應用最近的位置(分布式應用、推薦系統)、離用戶最近的位置（需要及時響應到客戶端的服務）
[媒介]中間件: Varnish\Ngnix\Squid\Memcache\Redis\Ehcache,內容；文件、數據、對象；介質：CPU、內存、磁盤
[緩存設計] what？where？How？
what：1、熱點數據 2、靜態資源
Where：CDN、反向代理、分布式緩存服務器、本機
How：過期策略、固定時間、相對時間、同步機制、實時寫入、異步刷新

【數據分布式緩存】大型網站分布式緩存 https://blog.csdn.net/chenxiaochan/article/details/71036497
[產生背景]

高并發環境下，大量的讀寫請求涌向數據庫，磁盤的處理速度與內存顯然不在一個量級，從減輕數據庫的壓力和提高系統響應速度兩個角度來考慮，一般都會在數據庫之前加一層緩存。由于單臺機器的內存資源以及承載能力有限，并且，如果大量使用本地緩存，也會使相同的數據被不同的節點存儲多份，對內存資源造成較大的浪費，因此，才催生出了分布式緩存。

[memecache原理]

【數據庫中間件】數據庫中間件技術概貌了解一下、數據中間件技術詳解
[解決的問題]為海量前臺數據提供高性能、大容量、高可用性的訪問
為數據變更的消費提供準實時的保障
高效的異地數據同步
[數據庫中間件的分類]
分布式數據庫分表分庫
數據增量訂閱與消費
數據庫同步（全量、增量、跨機房、復制）
跨數據庫（數據源）遷移

【分布式文件系統】分布式文件系統
[主流的分布式文件系統] Hadoop生態、以spark為核心的大數據中心
[應用背景及作用]企業對數據存儲的要求越來越高，而且模式各異。分布式文件系統將數據存儲在物理上分散的多個存儲節點上，對這些節點的資源進行統一的管理與分配，并向用戶提供文件系統訪問接口，其主要解決了本地文件系統在文件大小、文件數量、打開文件數等的限制問題。參見

轉載于:https://www.cnblogs.com/Erma/p/10531528.html

總結

以上是生活随笔為你收集整理的大型网络架构变迁和知识图谱的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。