上一篇 <<<動靜分離架構(gòu)模式
下一篇 >>>后端服務(wù)的雪崩效應(yīng)及解決思路
1.瀏覽器緩存
瀏覽器自帶緩存304：圖片的默認(rèn)緩存時間為7天
客戶端（瀏覽器）發(fā)送請求到服務(wù)器端 第一次請求的時候會緩存所有的靜態(tài)資源到瀏覽器；
客戶端發(fā)送第二次請求的時候 如果本地瀏覽器有緩存瞧省，就使用本地瀏覽器的司致；
Key：訪問的url
value：具體的值信息
原理：
a梢灭、第一次下載資源的時候笨奠，客戶端會保存修改時間
b者冤、第二次下載資源的時候无宿，客戶端上傳修改時間日矫，服務(wù)端決定返回200還304.
----這種時間不一定準(zhǔn)赂弓，所以請求的時候一般會加上一個時間戳或版本號信息強制刷新。http://www.baidu.com?v=20200202
動態(tài)資源：
需要手動在響應(yīng)頭里加上最后修改時間哪轿，默認(rèn)不會自動緩存
2.Nginx靜態(tài)頁面緩存
配置nginx的緩存策略盈魁，含名稱、存放位置窃诉、存放大小限制杨耙、有效期和狀態(tài)信息，其中key為url信息飘痛。
如果url不變珊膜，就算上游服務(wù)器掛了，也能從nginx中直接獲取宣脉。缺點是上游服務(wù)器變了车柠，由于url沒變，緩存數(shù)據(jù)無法刷新。所以解決nginx緩存刷新的關(guān)鍵在于url的變更竹祷，可以加上時間戳介蛉。
# 代理緩存配置
proxy_cache_path "./meite_cachedata" levels=1:2 keys_zone=meitecache:256m inactive=1d max_size=1000g;
server {
listen 80;
server_name localhost;
location /details {
#使用緩存名稱
proxy_cache meitecache;
#對以下狀態(tài)碼實現(xiàn)緩存
proxy_cache_valid 200 206 304 301 302 1d;
#緩存的key
proxy_cache_key $request_uri;
add_header X-Cache-Status $upstream_cache_status;
proxy_pass http://127.0.0.1:8080;
index index.html index.htm;
}
location /all {
proxy_pass http://127.0.0.1:8080;
index index.html index.htm;
}
}
3.CDN內(nèi)容分發(fā)緩存
CDN的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)，是一組分布在多個不同地理位置的Web服務(wù)器迟蜜，目的是使用戶能就近地獲取請求數(shù)據(jù)员凝，解決網(wǎng)絡(luò)擁塞，提高訪問速度精钮，解決由于網(wǎng)絡(luò)帶寬小、用戶訪問量大、網(wǎng)點分布不均等原因?qū)е碌脑L問速度慢的問題彭则。CDN能夠緩存JavaScript腳本、CSS樣式表占遥、圖片俯抖、圖標(biāo)、Flash等靜態(tài)資源文件（不包括html頁面）瓦胎，這些靜態(tài)資源文文件的訪問頻率很高芬萍，將其緩存在CDN可以極大地提高網(wǎng)站的訪問速度。
原理：能夠?qū)㈧o態(tài)資源緩存到全國各地節(jié)點能夠減少客戶端與cdn帶寬距離傳輸提高響應(yīng)速度搔啊； 就近原則
為什么將靜態(tài)資源存放到第三方服務(wù)器效率非常高呢柬祠？
1M公網(wǎng)帶寬的理論下載速度是128k/s，一張圖如果2M负芋，則需要16s,如果并發(fā)量很高漫蛔，則速度會非常的慢，而且非常的占用帶寬旧蛾，而且還和傳輸?shù)木嚯x有關(guān)系莽龟。
如果圖片過大的情況下，建議將一張大圖拆分n多個小圖加載锨天；
為了解決以上問題毯盈，可以使用第三方服務(wù)器，因為
1绍绘、云服務(wù)器簽訂帶寬都是將T算的奶镶，價格更便宜
2、CDN內(nèi)容分發(fā)陪拘，能夠?qū)㈧o態(tài)資源緩存到全國各地節(jié)點能夠減少客戶端與cdn帶寬距離傳輸提高響應(yīng)速度厂镇； 就近原則。
傳統(tǒng)方式架構(gòu)弊端左刽？
a.帶寬傳輸壓力大
b.因為所有用戶全部聚集到同一個地區(qū)服務(wù)器上訪問捺信，無法保證整體的系統(tǒng)高可用
c.因為如果客戶端與服務(wù)器端傳輸距離越遠(yuǎn)，那么寬帶傳輸非常耗資源，導(dǎo)致用戶體驗非常差迄靠，響應(yīng)慢秒咨。
CDN安全控制或還提供了其他什么服務(wù)？
防止DDOS攻擊掌挚、DNS負(fù)載均衡雨席、實現(xiàn)WEB安全防御功能，比如黑名單和白名單
4.服務(wù)端SpringBoot整合Redis緩存
a吠式、啟動的配置文件上加上注解@EnableCaching
b陡厘、使用的地方加上注解
@Cacheable(cacheNames = "case",key = "'caseDetail'")
cachenames相當(dāng)于文件夾，后面的key為具體的key特占，key一定要加上單引號糙置，不加會報錯
緩存的內(nèi)容必須要實現(xiàn)序列化
----存在數(shù)據(jù)庫和redis同步性問題。
@SpringBootApplication
@EnableCaching
@MapperScan("com.jarye.mapper")
public class App {
public static void main(String[] args) {
SpringApplication.run(App.class);
}
}
@Cacheable(cacheNames = "members", key = "'getListMembers'")
@RequestMapping("/getListMembers")
public List<MemberEntity> getListMembers() {
return userMapper.findMemberAll();
}
5.其他緩存
和redis緩存一樣的Ehcache是目、Memcache等第三方緩存谤饭、JVM自帶內(nèi)置緩存、數(shù)據(jù)庫緩存
6.緩存需要考慮的問題
1懊纳、Redis與數(shù)據(jù)庫一致性問題：mq訂閱binlog揉抵，可同步數(shù)據(jù)一致性問題
2、JVM與Redis保持一致性問題：出現(xiàn)不一致的時候嗤疯，同步數(shù)據(jù)庫的值為一致功舀。
3、Nginx緩存與服務(wù)器端真實緩存一致問題：
a. 使用版本號控制
b. 手動清除Nginx緩存身弊，需要物理刪除
c. 使用lua+openresty實現(xiàn)動態(tài)商品詳情頁面
推薦閱讀：
<<<高并發(fā)架構(gòu)的整體思路
<<<一個網(wǎng)站訪問慢的真正原因
<<<高并發(fā)情況下辟汰，接口的代碼會存在哪些問題
<<<壓縮靜態(tài)資源減少帶寬傳輸?shù)姆绞?/a>
<<<動靜分離架構(gòu)模式
<<<后端服務(wù)的雪崩效應(yīng)及解決思路
<<<服務(wù)的隔離、降級和熔斷
<<<服務(wù)限流之計數(shù)器方式
<<<服務(wù)限流之滑動窗口計數(shù)
<<<服務(wù)限流之令牌桶算法
<<<服務(wù)限流之漏桶算法
<<<漏桶算法和令牌桶算法的區(qū)別
<<<自定義封裝限流算法
<<<應(yīng)用級限流
<<<接入層限流
