溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要為大家展示了“java緩存核心技術的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“java緩存核心技術的示例分析”這篇文章吧。
緩存對于每個開發者來說是相當熟悉了，為了提高程序的性能我們會去加緩存，但是在什么地方加緩存，如何加緩存呢？
假設一個網站，需要提高性能，緩存可以放在瀏覽器，可以放在反向代理服務器，還可以放在應用程序進程內，同時可以放在分布式緩存系統中。
從用戶請求數據到數據返回，數據經過了瀏覽器，CDN，代理服務器，應用服務器，以及數據庫各個環節。每個環節都可以運用緩存技術。
從瀏覽器/客戶端開始請求數據，通過 HTTP 配合 CDN 獲取數據的變更情況，到達代理服務器（Nginx）可以通過反向代理獲取靜態資源。
再往下來到應用服務器可以通過進程內（堆內）緩存，分布式緩存等遞進的方式獲取數據。如果以上所有緩存都沒有命中數據，才會回源到數據庫。
緩存的請求順序是：用戶請求 → HTTP 緩存 → CDN 緩存 → 代理服務器緩存 → 進程內緩存 → 分布式緩存 → 數據庫。
看來在技術的架構每個環節都可以加入緩存，看看每個環節是如何應用緩存技術的。
當用戶通過瀏覽器請求服務器的時候，會發起 HTTP 請求，如果對每次 HTTP 請求進行緩存，那么可以減少應用服務器的壓力。
當第一次請求的時候，瀏覽器本地緩存庫沒有緩存數據，會從服務器取數據，并且放到瀏覽器的緩存庫中，下次再進行請求的時候會根據緩存的策略來讀取本地或者服務的信息。
一般信息的傳遞通過 HTTP 請求頭 Header 來傳遞。目前比較常見的緩存方式有兩種，分別是：
強制緩存
對比緩存
當瀏覽器本地緩存庫保存了緩存信息，在緩存數據未失效的情況下，可以直接使用緩存數據。否則就需要重新獲取數據。
這種緩存機制看上去比較直接，那么如何判斷緩存數據是否失效呢？這里需要關注 HTTP Header 中的兩個字段 Expires 和 Cache-Control。
Expires 為服務端返回的過期時間，客戶端第一次請求服務器，服務器會返回資源的過期時間。如果客戶端再次請求服務器，會把請求時間與過期時間做比較。
如果請求時間小于過期時間，那么說明緩存沒有過期，則可以直接使用本地緩存庫的信息。
反之，說明數據已經過期，必須從服務器重新獲取信息，獲取完畢又會更新最新的過期時間。
這種方式在 HTTP 1.0 用的比較多，到了 HTTP 1.1 會使用 Cache-Control 替代。
Cache-Control 中有個 max-age 屬性，單位是秒，用來表示緩存內容在客戶端的過期時間。
例如：max-age 是 60 秒，當前緩存沒有數據，客戶端第一次請求完后，將數據放入本地緩存。
那么在 60 秒以內客戶端再發送請求，都不會請求應用服務器，而是從本地緩存中直接返回數據。如果兩次請求相隔時間超過了 60 秒，那么就需要通過服務器獲取數據。
需要對比前后兩次的緩存標志來判斷是否使用緩存。瀏覽器第一次請求時，服務器會將緩存標識與數據一起返回，瀏覽器將二者備份至本地緩存庫中。瀏覽器再次請求時，將備份的緩存標識發送給服務器。
服務器根據緩存標識進行判斷，如果判斷數據沒有發生變化，把判斷成功的 304 狀態碼發給瀏覽器。
這時瀏覽器就可以使用緩存的數據來。服務器返回的就只是 Header，不包含 Body。
下面介紹兩種標識規則：
在客戶端第一次請求的時候，服務器會返回資源最后的修改時間，記作 Last-Modified。客戶端將這個字段連同資源緩存起來。
Last-Modified 被保存以后，在下次請求時會以 Last-Modified-Since 字段被發送。
當客戶端再次請求服務器時，會把 Last-Modified 連同請求的資源一起發給服務器，這時 Last-Modified 會被命名為 If-Modified-Since，存放的內容都是一樣的。
服務器收到請求，會把 If-Modified-Since 字段與服務器上保存的 Last-Modified 字段作比較：
若服務器上的 Last-Modified 最后修改時間大于請求的 If-Modified-Since，說明資源被改動過，就會把資源（包括 Header+Body）重新返回給瀏覽器，同時返回狀態碼 200。
若資源的最后修改時間小于或等于 If-Modified-Since，說明資源沒有改動過，只會返回 Header，并且返回狀態碼 304。瀏覽器接受到這個消息就可以使用本地緩存庫的數據。
注意：Last-Modified 和 If-Modified-Since 指的是同一個值，只是在客戶端和服務器端的叫法不同。
客戶端第一次請求的時候，服務器會給每個資源生成一個 ETag 標記。這個 ETag 是根據每個資源生成的唯一 Hash 串，資源如何發生變化 ETag 隨之更改，之后將這個 ETag 返回給客戶端，客戶端把請求的資源和 ETag 都緩存到本地。
ETag 被保存以后，在下次請求時會當作 If-None-Match 字段被發送出去。
在瀏覽器第二次請求服務器相同資源時，會把資源對應的 ETag 一并發送給服務器。在請求時 ETag 轉化成 If-None-Match，但其內容不變。
服務器收到請求后，會把 If-None-Match 與服務器上資源的 ETag 進行比較：
如果不一致，說明資源被改動過，則返回資源（Header+Body），返回狀態碼 200。
如果一致，說明資源沒有被改過，則返回 Header，返回狀態碼 304。瀏覽器接受到這個消息就可以使用本地緩存庫的數據。
注意：ETag 和 If-None-Match 指的是同一個值，只是在客戶端和服務器端的叫法不同。
HTTP 緩存主要是對靜態數據進行緩存，把從服務器拿到的數據緩存到客戶端/瀏覽器。
如果在客戶端和服務器之間再加上一層 CDN，可以讓 CDN 為應用服務器提供緩存，如果在 CDN 上緩存，就不用再請求應用服務器了。并且 HTTP 緩存提到的兩種策略同樣可以在 CDN 服務器執行。
CDN 的全稱是 Content Delivery Network，即內容分發網絡。
讓我們來看看它是如何工作的吧：
客戶端發送 URL 給 DNS 服務器。
DNS 通過域名解析，把請求指向 CDN 網絡中的 DNS 負載均衡器。
DNS 負載均衡器將最近 CDN 節點的 IP 告訴 DNS，DNS 告之客戶端最新 CDN 節點的 IP。
客戶端請求最近的 CDN 節點。
CDN 節點從應用服務器獲取資源返回給客戶端，同時將靜態信息緩存。注意：客戶端下次互動的對象就是 CDN 緩存了，CDN 可以和應用服務器同步緩存信息。
CDN 接受客戶端的請求，它就是離客戶端最近的服務器，它后面會鏈接多臺服務器，起到了緩存和負載均衡的作用。
說完客戶端（HTTP）緩存和 CDN 緩存，我們離應用服務越來越近了，在到達應用服務之前，請求還要經過負載均衡器。
雖說它的主要工作是對應用服務器進行負載均衡，但是它也可以作緩存。可以把一些修改頻率不高的數據緩存在這里，例如：用戶信息，配置信息。通過服務定期刷新這個緩存就行了。
以 Nginx 為例，我們看看它是如何工作的：
用戶請求在達到應用服務器之前，會先訪問 Nginx 負載均衡器，如果發現有緩存信息，直接返回給用戶。
如果沒有發現緩存信息，Nginx 回源到應用服務器獲取信息。
另外，有一個緩存更新服務，定期把應用服務器中相對穩定的信息更新到 Nginx 本地緩存中。
通過了客戶端，CDN，負載均衡器，我們終于來到了應用服務器。應用服務器上部署著一個個應用，這些應用以進程的方式運行著，那么在進程中的緩存是怎樣的呢？
進程內緩存又叫托管堆緩存，以APC為例，同時會受到托管堆回收算法的影響。
由于其運行在內存中，對數據的響應速度很快，通常我們會把熱點數據放在這里。
在進程內緩存沒有命中的時候，我們會去搜索進程外的緩存或者分布式緩存。這種緩存的好處是沒有序列化和反序列化，是最快的緩存。缺點是緩存的空間不能太大，對垃圾回收器的性能有影響。
這里我們需要關注幾個緩存的回收策略，具體的實現架構的回收策略會有所不同，但大致的思路都是一致的：
FIFO（First In First Out）：先進先出算法，最先放入緩存的數據最先被移除。
LRU（Least Recently Used）：最近最少使用算法，把最久沒有使用過的數據移除緩存。
LFU（Least Frequently Used）：最不常用算法，在一段時間內使用頻率最小的數據被移除緩存。
在分布式架構的今天，多應用中如果采用進程內緩存會存在數據一致性的問題。
這里推薦兩個方案：
消息隊列修改方案
Timer 修改方案
應用在修改完自身緩存數據和數據庫數據之后，給消息隊列發送數據變化通知，其他應用訂閱了消息通知，在收到通知的時候修改緩存數據。
為了避免耦合，降低復雜性，對“實時一致性”不敏感的情況下。每個應用都會啟動一個 Timer，定時從數據庫拉取最新的數據，更新緩存。
不過在有的應用更新數據庫后，其他節點通過 Timer 獲取數據之間，會讀到臟數據。這里需要控制好 Timer 的頻率，以及應用與對實時性要求不高的場景。
進程內緩存有哪些使用場景呢？
場景一：只讀數據，可以考慮在進程啟動時加載到內存。當然，把數據加載到類似 Redis 這樣的進程外緩存服務也能解決這類問題。
場景二：高并發，可以考慮使用進程內緩存，例如：秒殺。
說完進程內緩存，自然就過度到進程外緩存了。與進程內緩存不同，進程外緩存在應用運行的進程之外，它擁有更大的緩存容量，并且可以部署到不同的物理節點，通常會用分布式緩存的方式實現。
分布式緩存是與應用分離的緩存服務，最大的特點是，自身是一個獨立的應用/服務，與本地應用隔離，多個應用可直接共享一個或者多個緩存應用/服務。
既然是分布式緩存，緩存的數據會分布到不同的緩存節點上，每個緩存節點緩存的數據大小通常也是有限制的。
數據被緩存到不同的節點，為了能方便的訪問這些節點，需要引入緩存代理，類似 Twemproxy。他會幫助請求找到對應的緩存節點。
同時如果緩存節點增加了，這個代理也會只能識別并且把新的緩存數據分片到新的節點，做橫向的擴展。
為了提高緩存的可用性，會在原有的緩存節點上加入 Master/Slave 的設計。當緩存數據寫入 Master 節點的時候，會同時同步一份到 Slave 節點。
一旦 Master 節點失效，可以通過代理直接切換到 Slave 節點，這時 Slave 節點就變成了 Master 節點，保證緩存的正常工作。
每個緩存節點還會提供緩存過期的機制，并且會把緩存內容定期以快照的方式保存到文件上，方便緩存崩潰之后啟動預熱加載。
當緩存做成分布式的時候，數據會根據一定的規律分配到每個緩存應用/服務上。
如果我們把這些緩存應用/服務叫做緩存節點，每個節點一般都可以緩存一定容量的數據，例如：Redis 一個節點可以緩存 2G 的數據。
如果需要緩存的數據量比較大就需要擴展多個緩存節點來實現，這么多的緩存節點，客戶端的請求不知道訪問哪個節點怎么辦？緩存的數據又如何放到這些節點上？
緩存代理服務已經幫我們解決這些問題了，例如：Twemproxy 不但可以幫助緩存路由，同時可以管理緩存節點。
這里有介紹三種緩存數據分片的算法，有了這些算法緩存代理就可以方便的找到分片的數據了。
Hash 表是最常見的數據結構，實現方式是，對數據記錄的關鍵值進行 Hash，然后再對需要分片的緩存節點個數進行取模得到的余數進行數據分配。
例如：有三條記錄數據分別是 R1，R2，R3。他們的 ID 分別是 01，02，03，假設對這三個記錄的 ID 作為關鍵值進行 Hash 算法之后的結果依舊是 01，02，03。
我們想把這三條數據放到三個緩存節點中，可以把這個結果分別對 3 這個數字取模得到余數，這個余數就是這三條記錄分別放置的緩存節點。
Hash 算法是某種程度上的平均放置，策略比較簡單，如果要增加緩存節點，對已經存在的數據會有較大的變動。
一致性 Hash 是將數據按照特征值映射到一個首尾相接的 Hash 環上，同時也將緩存節點映射到這個環上。
如果要緩存數據，通過數據的關鍵值（Key）在環上找到自己存放的位置。這些數據按照自身的 ID 取 Hash 之后得到的值按照順序在環上排列。
如果這個時候要插入一條新的數據其 ID 是 115，那么就應該插入到如下圖的位置。
同理如果要增加一個緩存節點 N4 150，也可以放到如下圖的位置。
這種算法對于增加緩存數據，和緩存節點的開銷相對比較小。
這種方式是按照關鍵值（例如 ID）將數據劃分成不同的區間，每個緩存節點負責一個或者多個區間。跟一致性哈希有點像。
例如：存在三個緩存節點分別是 N1，N2，N3。他們用來存放數據的區間分別是，N1(0, 100]， N2(100, 200]， N3(300, 400]。
那么數據根據自己 ID 作為關鍵字做 Hash 以后的結果就會分別對應放到這幾個區域里面了。
以上是“java緩存核心技術的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
