㈠ 該怎麼解決 Redis 緩存穿透和緩存雪崩問題
緩存雪崩： 由於緩存層承載著大量請求，有效地 保護了存儲層，但是如果緩存層由於某些原因不能提供服務，比如 Redis 節點掛掉了，熱點 key 全部失效了，在這些情況下，所有的請求都會直接請求到資料庫，可能會造成資料庫宕機的情況。
預防和解決緩存雪崩問題，可以從以下三個方面進行著手：
1、使用 Redis 高可用架構：使用 Redis 集群來保證 Redis 服務不會掛掉
2、緩存時間不一致： 給緩存的失效時間，加上一個隨機值，避免集體失效
3、限流降級策略：有一定的備案，比如個性推薦服務不可用了，換成熱點數據推薦服務
緩存穿透： 緩存穿透是指查詢一個根本不存在的數據，這樣的數據肯定不在緩存中，這會導致請求全部落到資料庫上，有可能出現資料庫宕機的情況。
預防和解決緩存穿透問題，可以考慮以下兩種方法：
1、緩存空對象： 將空值緩存起來，但是這樣就有一個問題，大量無效的空值將佔用空間，非常浪費。
2、布隆過濾器攔截： 將所有可能的查詢key 先映射到布隆過濾器中，查詢時先判斷key是否存在布隆過濾器中，存在才繼續向下執行，如果不存在，則直接返回。布隆過濾器有一定的誤判，所以需要你的業務允許一定的容錯性。
㈡ 集成部署對redis緩存失效有影響嗎
expires查找key期間存說明應key沒設置期間直接返
slave機器則直接返Redis保證數據致性且實現簡單緩存失效主權交給Master機器slave機器沒許可權key失效
前Master機器且key期則master做兩件重要事情：1）刪除命令寫入AOF文件2）通知Slave前key失效刪除
master本字典key於值刪除
主失效機制
主失效機制叫積極失效機制即服務端定檢查失效緩存失效則進行相應操作
我都知道Redis單線程基於事件驅RedisEventLoopEventLoop負責兩類事件進行處理：
類IO事件類事件底層路復用器離
類定事件類事件主要用事件某任務定執行
㈢ Nginx緩存什麼時候失效
location ~.*\.(js|css|html|png|jpg)$ 這個是設置類型
{
expires 3d;
}
expires 3d;//表示緩存3天
expires 3h;//表示緩存3小時
expires max;//表示緩存10年
expires -1;//表示永遠過期。
如果設置為-1在js、css等靜態文件在沒有修改的情況下返回的是http 304，如果修改返回http 200
http 304：自從上次請求後，請求的網頁未修改過。伺服器返回此響應時，不會返回網頁內容。
http 200：伺服器已成功處理了請求，這表示伺服器提供了請求的內容。
=======
如果不想讓代理或瀏覽器緩存，加no-cache參數
add_header Cache-Control no-cache;
這樣瀏覽器F5刷新時，返回的就是http 200，而不是http 304
㈣ 緩存內容已過期請重新打開頁面
摘要 在onedrive將「文件協作」功能關閉，然後重啟Office軟體。
㈤ 什麼叫緩存命中率
其中很多人談到了緩存命中率的問題，應用緩存的命中率取決於很多的因素：
1、應用場景
是OLTP還是OLAP應用，即使是OLTP，也要看訪問的頻度，一個極少被訪問到的緩存等於沒有什麼效果。一般來說，互聯網網站是非常適合緩存應用的場景。
2、緩存的粒度
毫無疑問，緩存的粒度越小，命中率就越高，對象緩存是目前緩存粒度最小的，因此被命中的幾率更高。舉個例子來說吧：你訪問當前這個頁面，瀏覽帖子，那麼對於ORM來說，需要發送n條SQL，取各自帖子user的對象。很顯然，如果這個user在其他帖子裡面也跟貼了，那麼在訪問那個帖子的時候，就可以直接從緩存裡面取這個user對象了。
3、架構的設計
架構的設計對於緩存命中率也有至關重要的影響。例如你應該如何去盡量避免緩存失效的問題，如何盡量提供頻繁訪問數據的緩存問題，這些都是考驗架構師水平的地方。再舉個例子來說，對於論壇，需要記錄每個topic的瀏覽次數，所以每次有人訪問這個topic，那麼topic表就要update一次，這意味著什麼呢？對於topic的對象緩存是無效的，每次訪問都要更新緩存。那麼可以想一些辦法，例如增加一個中間變數記錄點擊次數，每累計一定的點擊，才更新一次資料庫，從而減低緩存失效的頻率。
4、緩存的容量和緩存的有效期
緩存太小，造成頻繁的LRU，也會降低命中率，緩存的有效期太短也會造成緩存命中率下降。
所以緩存命中率問題不能一概而論，一定說命中率很低或者命中率很高。但是如果你對於緩存的掌握很精通，有意識的去調整應用的架構，去分解緩存的粒度，總是會帶來很高的命中率的。
這里我可以舉一個實際的案例，JavaEye2.0網站在使用對象緩存之前，通過MySQL的監控工具進行觀察，在連續24小時的平均每秒發送SQL條數超過了200條，在使用對象緩存之後，連續24小時的平均每秒發送SQL條數下降到了120條左右，幾乎下降了一半。
考慮到很多SQL都是分頁語句，關聯查詢，條件查詢，集合操作，都是不能被緩存的SQL，而真正能夠被緩存的SQL只有根據主鍵查詢對象和對象關聯對象的查詢。所以真正能夠被緩存的SQL估計最多佔所有SQL的60%。所以換算下來，應用緩存的命中率之高，已經相當驚人了。
不過這里要提醒的一點，有將近一半的SQL都被緩存，不意味著性能可以提升一倍。這是因為能夠被緩存的都是按照主鍵查詢單條記錄的SQL，這些SQL本身即使發送到資料庫，對資料庫造成的壓力也沒有想像的那麼大。真正對資料庫造成龐大壓力的正是那些沒有索引的大表查詢，和造成了全表掃描的關聯查詢，這些一旦涉及到全表掃描的查詢，才是性能的真正殺手。當然了，不管怎麼說，通過使用對象緩存，是毫無疑問可以大幅度降低資料庫的負載壓力的，有效提升web應用的性能的。
關於這一點，我再給出一組數據來加深大家的印象，通過使用操作系統網路工具進行統計：
JavaEye網站web server的埠每秒數據流量是2MB；
JavaEye網站的MySQL資料庫埠的每秒數據流量是1.2MB；
而網站的memcached的埠每秒的數據流量高達5MB
㈥ ajax 緩存強制使用緩存無效
1.設置header的Context-Type為application/x-www-form-urlencode確保伺服器知道實體中有參數變數. 通常使用XmlHttpRequest對象的SetRequestHeader("Context-Type","application/x-www- form-urlencoded;")。例：
xmlHttp.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
2.參數是名/值一一對應的鍵值對,每對值用&號隔開.如 var name=abc&sex=man&age=18，注意var name=update.php?
abc&sex=man&age=18以及var name=?abc&sex=man&age=18的寫法都是錯誤的;
3.參數在Send(參數)方法中發送,例： xmlHttp.send(name); 如果是get方式，直接 xmlHttp.send(null);
4.伺服器端請求參數區分Get與Post。如果是get方式則$username = $_GET["username"]; 如果是post方式，則$username = $_POST["username"];
㈦ 一個頁面禁止緩存，在點擊返回之後會提示改頁面一失效之類的提示語，我們如何自定義提示語呢
如果是頁面中的返回按鈕，可以連接到之前返回頁面的url，而不使用histroy.go(-1)，如果是點擊ie的返回出現了頁面過期，對於部分功能也是正常的吧，例如網上銀行的支付就都是不允許後退的阿
㈧ 設置頁面在失效前被緩存的時間是什麼意思
你應該是說的頁面緩存失效時間，比如你改了頁面引入的js，刷新的時候並不會生效，因為實際上瀏覽的是緩存的頁面，並沒有載入新寫的JS，緩存失效過了之後會重新讀一遍就會把新寫的js讀進去了，這個一般都是項目和伺服器配置，跟前端無關
㈨ java緩存失效判斷，緩存一般是存放在Hashtable中，並且有個失效時間。怎麼判斷這個時間。
用一個單獨的線程,定時檢查HashTable里的時間,過期就刪除