關注留言點贊，帶你了解最流行的軟體開發知識與最新科技行業趨勢。
緩存是提高我們網絡平台性能的關鍵之一。了解緩存和專注于前端和用戶端的特定用例。
緩存是所有工程師都必須知道的非常有用的軟體元件。它是一個橫向元件，适用于所有技術領域和架構層，如作業系統、資料平台、後端、前端和其他元件。在本文中，我們将描述什麼是緩存，并針對前端和用戶端解釋具體用例。
什麼是緩存？
緩存可以以基本方式定義為資料消費者和資料生産者之間的中間存儲器，用于存儲和提供将被相同/不同消費者多次通路的資料。除了提高性能外，它在使用者可用性方面對資料消費者來說是一個透明層。 通常，資料生産者提供的資料的可重用性是利用緩存優勢的關鍵。性能是使用記憶體資料庫等緩存系統來提供具有低延遲、高吞吐量和并發性的高性能解決方案的另一個原因。
例如，每天有多少人查詢天氣，他們會重複查詢多少次？假設紐約有 1,000 人查詢天氣，其中 50% 的人每天重複相同的查詢兩次。在這種情況下，如果我們可以将第一個查詢存儲在盡可能靠近使用者裝置的位置，我們将獲得兩個好處：增加使用者體驗，因為資料提供得更快，并減少對資料生産者/伺服器端的查詢次數。輸出是更好的使用者體驗和支援更多并發使用者使用該平台的解決方案。
天氣查詢場景
在高層次上，我們可以以互補的方式應用兩種緩存政策：
Client/Consumer Side：緩存的資料存儲在消費者或使用者端，當我們談論 Web 解決方案時，通常在浏覽器的記憶體中（也稱為私有緩存）。
伺服器/生産者端：緩存的資料存儲在資料生産者架構的元件中。
用戶端和伺服器端
與任何其他解決方案一樣，緩存具有一系列優勢，我們将對其進行總結：
應用程式性能：提供更快的響應時間，因為可以更快地提供資料。
減少伺服器端的負載：當我們将緩存應用到以前的系統并重用一段資料時，我們正在避免查詢/請求到下一層。
可擴充性和成本改進：随着資料緩存越來越接近消費者，我們以更低的成本提高了解決方案的可擴充性和性能。
靠近用戶端的元件更具可擴充性和更便宜，因為三個主要原因：
這些元件 側重于性能和可用性，但一緻性較差。
他們隻有部分資訊：使用者使用更多的資料。
在浏覽器的本地緩存的情況下，資料生産者沒有成本。
成本、性能和一緻性圖
緩存的最大挑戰是資料一緻性和資料新鮮度， 這意味着資料如何在整個組織内同步和更新。根據用例，我們會有或多或少的要求限制，因為它與緩存圖像相比與庫存或銷售行為有很大不同。
用戶端緩存
談到用戶端緩存，我們可以有不同類型的緩存，我們将在本文中稍微分析一下：
HTTP 緩存：這種緩存類型是一種中間緩存系統，因為它部分取決于伺服器。
緩存 API：這是一個浏覽器 API，允許我們在浏覽器中緩存請求。
自定義本地緩存： 前端應用控制緩存存儲、過期、失效和更新。
緩存
它在浏覽器中緩存對任何資源（CSS、HTML、圖像、視訊等）的 HTTP 請求，并從前端管理所有與存儲、過期、驗證、擷取等相關的内容。應用程式的觀點幾乎是透明的，因為它以正常方式送出請求并且浏覽 器執行所有“魔術”。
緩存
控制緩存的方法是使用 HTTP Headers，在伺服器端，它向 HTTP 響應添加特定于緩存的标頭，例如：“Expires: Tue, 30 Jul 2023 05:30:22 GMT”，然後是浏覽器知道這個資源可以被緩存，下次用戶端（應用程式）請求同一個資源時，如果請求時間在過期日期之前，請求将不會完成，浏覽器将傳回該資源的本地副本。
它允許您設定響應的僞裝方式，因為相同的 URL 可以生成不同的響應（并且它們的緩存應該以不同的方式處理）。例如，在傳回一些資料的 API 端點（即 http://example.com/my-data）中，我們可以使用請求标頭來Content-type指定我們是否需要 JSON 或 CSV 等格式的響應。是以，緩存應根據請求标頭與響應一起存儲。為此，伺服器應該設定響應标頭Vary: Accept-Language，讓浏覽器知道緩存取決于該值。有很多不同的标頭來控制緩存流和行為，但深入研究它不是本文的目标。它可能會在另一篇文章中解決。
正如我們之前提到的，這種緩存類型需要伺服器設定資源過期、驗證等。是以這不是一種純粹的前端緩存方法或類型，但它是緩存前端應用程式使用的資源的最簡單方法之一，它是我們将在下面提到的另一種方式的補充。
與這種緩存類型相關，由于它是中間緩存，我們甚至可以将其委托給用戶端和伺服器之間的“一塊”；例如，CDN、反向代理（例如 Varnish）等。
HTTP 緩存的優點和缺點
緩存接口
它與 HTTP 緩存方法非常相似，但在這種情況下，我們控制哪些請求被存儲或從緩存中提取。我們必須管理緩存過期（這并不容易，因為這些緩存被認為“永遠存在”）。即使這些 API 在視窗上下文中可用，也非常适合它們在 worker 上下文中的使用。
該緩存非常适合用于離線應用程式。在第一次請求時，我們可以擷取并緩存它需要的所有資源（圖像、CSS、JS 等），進而允許應用程式離線工作。它在移動應用程式中非常有用，例如，除了天氣資料之外，我們的 GPS 系統還可以使用地圖。這使我們即使沒有連接配接到伺服器也能獲得遠足路線的所有資訊。
它如何在視窗上下文中工作的一個示例：
const url = ‘https://catfact.ninja/breeds’
caches.open('v1').then((cache) => {
cache.match((url).then((res) => {
if (res) {
console.log('it is in cache')
console.log(res.json())
} else {
console.log('it is NOT in cache')
fetch(url) .then(res => {
cache.put('test', res.clone())
})
}
})
})
緩存 API 優缺點
自定義本地緩存
在某些情況下，我們 需要更多地控制緩存資料和失效（不僅僅是過期）。緩存失效不僅僅是檢查max-age緩存條目。
想象一下我們上面提到的天氣應用程式。該應用程式允許使用者更新天氣以反映某個地方的真實天氣。該應用程式需要針對每個城市執行請求并将溫度值從華氏度轉換為攝氏度（這是一個簡單的示例：在其他用例中計算成本可能更高）。
自定義本地緩存
為了避免向伺服器做請求（即使它被緩存），我們可以一次做所有的請求，把所有的資料放在一個我們友善的資料結構中，并存儲在，例如在浏覽器的IndexedDB中，在LocalStorage、SessionStorage 甚至在記憶體中（不推薦）。下次我們要顯示資料時，我們可以從緩存中擷取它，而不僅僅是資源資料（甚至是我們所做的計算），節省網絡和計算時間。
我們可以通過在API後面加上釋出時間來控制緩存的過期，也可以控制緩存的失效。現在想象一下，使用者在其浏覽器中添加了一隻新貓。我們可以讓緩存失效，下次再做請求和計算，或者更進一步，用新資料更新我們的本地緩存。或者，另一個使用者可以更改該值，伺服器将發送一個事件以将更改通知給所有用戶端。例如，使用WebSockets，我們的前端應用程式可以聽到這些事件并使緩存無效或隻更新緩存。
客戶到供應商系統
這種緩存需要我們這邊的工作來檢查緩存并處理可能使其失效或更新的事件等，但非常适合六邊形架構，其中使用端口擴充卡（存儲庫）從 API 使用資料可以聽到域事件以對更改做出反應并使某些緩存無效或更新。
自定義本地緩存優缺點
這不是緩存通用解決方案。我們需要考慮它是否适合我們的用例，因為它需要在前端應用程式端工作以使緩存無效或發出和處理資料更改事件。在大多數情況下，HTTP 緩存就足夠了。
結論
擁有緩存解決方案和良好的政策應該是任何軟體架構中必須的， 但我們的解決方案将是不完整的，并且可能沒有優化。 緩存是我們最好的朋友，主要是在高性能場景中。看起來技術失效緩存過程是挑戰，但 最大的挑戰是了解業務場景和用例，以确定在資料新鮮度和一緻性方面的要求，使我們能夠設計和選擇最佳政策。