成立緩存

㈠ 嗶哩嗶哩音樂緩存怎麼用

1首先打開嗶哩嗶哩，點擊【頻道】—【音頻】；如圖所示

（拓展回答）

嗶哩嗶哩（bilibili）現為國內領先的年輕人文化社區，該網站於2009年6月26日創建，被粉絲們親切的為「B站」， 根據數據公司QuestMobile發布的《移動互聯網 2017 年Q2 夏季報告》，B站位列24歲及以下年輕用戶偏愛的十大APP榜首，

同時，在網路發布的2016熱搜榜中，B站在00後十大新鮮關注APP中排名第一。 B站在2017年3月成立了『國創』（國產原創）專區，致力於國產原創動畫的推廣與生態維護。截止2018年4月，國產原創動畫播放量累計達到18億。

㈡ 緩存靜態資源，不知怎麼解決

之前看過apach及nginx對於靜態資源（含js，圖片，css等）部分的緩存，用於加速並減輕後台實際web伺服器的壓力。
靜態資源緩存是WEB伺服器優化的一種手段，基本原理如下：
1.客戶端瀏覽器請求伺服器一個服務(該服務含有圖片，js等靜態資源)，通常會對於每一個網頁中的獨立圖片或js文件發送一個http請求
2.WEB伺服器對於每個資源HTTP請求進行解析，並生成一個資源修改時間的唯一值（可以是etag或last_modified參數），放入伺服器端map，key為資源url，value為資源修改時間。最後將此資源修改時間的唯一值包含在http頭上返回，因為是首次請求，所以會將所有內容放在http body中一並返回給客戶瀏覽器端
3.客戶瀏覽器接收服伺服器響應，並將伺服器返回的資源修改時間作為key放入瀏覽器客戶端，value為http body中的實際資源內容
4.客戶瀏覽器再次請求靜態資源時，會將資源修改時間一並發送給伺服器
5.服務端會從最新的map中取出該資源url對應的修改時間，如果值晚於客戶端請求的資源修改時間，這時會返回最新的已經修改過的資源給客戶端。否則返回304 not modifed

這里記錄資源修改時間的方式有etag及last_modified。最先有的是last_modified，它的工作方式就是上述介紹的，但缺點是只能精確到秒級別。也就是說當你在一秒中修改資源兩次，而客戶端拿到的是第一次修改，那之後就算客戶端第二次再次請求也不會拿到最新的資源。
而etag的出現正是為了解決last_modified的秒級問題，於http 1.1被提出。

今天測試了下，在沒有nginx等前端反向代理伺服器時，tomcat竟然默認對靜態資源做了緩存。
tomcat默認運用etag及last_modifed。etag與if_no_match(客戶端瀏覽器上傳時在http head中應該放的屬性名)一起使用，last_modified與If-Modified-Since一起使用。

客戶端首次請求時，得到請求響應數據如下：

GET http://localhost:8080/webTest/jsp/index.jsp [HTTP/1.1 200 OK 1ms]
GET http://localhost:8080/webTest/js/hello.js [HTTP/1.1 200 OK 1ms]
GET http://localhost:8080/webTest/img/a.jpg [HTTP/1.1 200 OK 2ms]
我們看一下Hello.js這個請求響應具體信息：
server Apache-Coyote/1.1 (表明伺服器是tomcat)
Last-Modified: Sun, 11 May 2014 10:54:33 GMT
Etag: W/"175-1399805673000"
Date: Sun, 11 May 2014 10:59:23 GMT
Content-Type: application/javascript;charset=UTF-8
Content-Length: 175
Accept-Ranges: bytes

從上面可以看到tomcat即返回了last_modified也返回了etag。

客戶端再次請求時，請求數據如下：
If-None-Match: W/"175-1399805673000"
If-Modified-Since: Sun, 11 May 2014 10:54:33 GMT
響應如下：

GET http://localhost:8080/webTest/jsp/index.jsp [HTTP/1.1 200 OK 1ms]
GET http://localhost:8080/webTest/js/hello.js [HTTP/1.1 304 Not Modified 1ms]
GET http://localhost:8080/webTest/img/a.jpg [HTTP/1.1 304 Not Modified 1ms]
從中我們可以看到tomcat對於靜態數據作了緩存。

接著我們分析tomcat對於這部分靜態緩存的判斷處理，這部分邏輯是寫在DefaultServlet類中，
我們可以在doGet方法中進入ServiceContext方法中找到以下源碼：
// Check if the conditions specified in the optional If headers are
// satisfied.
if (cacheEntry.context == null) {

// Checking If headers
boolean included =
(request.getAttribute(Globals.INCLUDE_CONTEXT_PATH_ATTR) != null);
if (!included
&& !checkIfHeaders(request, response, cacheEntry.attributes)) { //這句判斷是否需要返回整個資源請求
return;
}

}
上面源碼的 if (!included
&& !checkIfHeaders(request, response, cacheEntry.attributes))
用於判斷是否需要返回整個資源，如果indcluded與checkIfHeaders方法返回的都是false，這時就直接返回，說明資源未修改，或者是緩存不支持的請求方式。
我們接著查看checkIfHeaders方法：
/**
* Check if the conditions specified in the optional If headers are
* satisfied.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
* @param resourceAttributes The resource information
* @return boolean true if the resource meets all the specified conditions,
* and false if any of the conditions is not satisfied, in which case
* request processing is stopped
*/
protected boolean checkIfHeaders(HttpServletRequest request,
HttpServletResponse response,
ResourceAttributes resourceAttributes)
throws IOException {

return checkIfMatch(request, response, resourceAttributes)
&& checkIfModifiedSince(request, response, resourceAttributes)
&& checkIfNoneMatch(request, response, resourceAttributes)
&& checkIfUnmodifiedSince(request, response, resourceAttributes);

}

可以看到tomcat只有當這四個屬性全部返回true(也就是說全部認為資源已經改變)才會返回true，這樣最終會將整個資源（最新修改過的）返回客戶端。
在這里，我們從上面實際過程當中看到，瀏覽器第二次請求資源時在http請求header中放了
If-None-Match: W/"175-1399805673000"
If-Modified-Since: Sun, 11 May 2014 10:54:33 GMT
這兩個屬性。
因此我們查看
&& checkIfModifiedSince(request, response, resourceAttributes)
&& checkIfNoneMatch(request, response, resourceAttributes)
這兩個方法
checkIfModifiedSince源碼如下：
/**
* Check if the if-modified-since condition is satisfied.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
* @param resourceInfo File object
* @return boolean true if the resource meets the specified condition,
* and false if the condition is not satisfied, in which case request
* processing is stopped
*/
protected boolean checkIfModifiedSince(HttpServletRequest request,
HttpServletResponse response,
ResourceAttributes resourceAttributes) {
try {
long headerValue = request.getDateHeader("If-Modified-Since");
long lastModified = resourceAttributes.getLastModified();
if (headerValue != -1) {

// If an If-None-Match header has been specified, if modified since
// is ignored.
if ((request.getHeader("If-None-Match") == null)
&& (lastModified < headerValue + 1000)) {
// The entity has not been modified since the date
// specified by the client. This is not an error case.
response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
response.setHeader("ETag", resourceAttributes.getETag());

return false;
}
}
} catch (IllegalArgumentException illegalArgument) {
return true;
}
return true;

}
源碼中可以看到:
if ((request.getHeader("If-None-Match") == null)
&& (lastModified < headerValue + 1000)) {
這句話表明只有在客戶端瀏覽器發送的請求頭中不包含If-None-Match，IfModifiedSince才會生效。
我們接著看checkIfNoneMatch，源碼如下：
/**
* Check if the if-none-match condition is satisfied.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
* @param resourceInfo File object
* @return boolean true if the resource meets the specified condition,
* and false if the condition is not satisfied, in which case request
* processing is stopped
*/
protected boolean checkIfNoneMatch(HttpServletRequest request,
HttpServletResponse response,
ResourceAttributes resourceAttributes)
throws IOException {

String eTag = resourceAttributes.getETag();
String headerValue = request.getHeader("If-None-Match");
if (headerValue != null) {

boolean conditionSatisfied = false;

if (!headerValue.equals("*")) {

StringTokenizer commaTokenizer =
new StringTokenizer(headerValue, ",");

while (!conditionSatisfied && commaTokenizer.hasMoreTokens()) {
String currentToken = commaTokenizer.nextToken();
if (currentToken.trim().equals(eTag))
conditionSatisfied = true;
}

} else {
conditionSatisfied = true;
}

if (conditionSatisfied) {

// For GET and HEAD, we should respond with
// 304 Not Modified.
// For every other method, 412 Precondition Failed is sent
// back.
if ( ("GET".equals(request.getMethod()))
|| ("HEAD".equals(request.getMethod())) ) {
response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
response.setHeader("ETag", eTag);

return false;
}
response.sendError(HttpServletResponse.SC_PRECONDITION_FAILED);
return false;
}
}
return true;

}
這里：
String eTag = resourceAttributes.getETag();
String headerValue = request.getHeader("If-None-Match");
這兩句比較簡單，就是分別從伺服器緩存和http請求頭中中取出etag。
接著判斷這兩個etag如果相等，則conditionSatisfied為true，會執行到以下語句：
if (conditionSatisfied) {

// For GET and HEAD, we should respond with
// 304 Not Modified.
// For every other method, 412 Precondition Failed is sent
// back.
if ( ("GET".equals(request.getMethod()))
|| ("HEAD".equals(request.getMethod())) ) {
response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
response.setHeader("ETag", eTag);

return false;
}
response.sendError(HttpServletResponse.SC_PRECONDITION_FAILED);
return false;
}
這段語句中可以發現，如果資源未改變的情況下，並且請求方式為GET或者HEAD時，會返回304狀態碼。否則返回一個412狀態碼，同樣不會返回資源內容。
如果上述最終
if ((request.getHeader("If-None-Match") == null)
&& (lastModified < headerValue + 1000))
條件不成立，即資源更新了或者是第一次請求，這里會讀取當前請求資源文件，並最終放入http響應中。

㈢ 嗶哩嗶哩手機版如何緩存視頻

1、打開手機上的嗶哩嗶哩應用軟體。

拓展資料

嗶哩嗶哩（bilibili）是中國領先的年輕人文化社區，該網站於2009年6月26日創建，被粉絲們親切的稱為「B站」。 根據數據公司QuestMobile發布的《移動互聯網2017年Q2夏季報告》，B站位列24歲及以下年輕用戶偏愛的十大APP榜首。同時，在網路發布的2016熱搜榜中，B站在00後十大新鮮關注APP中排名第一。

㈣ 如何保證資料庫緩存的最終一致性

對於互聯網業務來說，傳統的直接訪問資料庫方式，主要通過數據分片、一主多從等方式來扛住讀寫流量，但隨著數據量的積累和流量的激增，僅依賴資料庫來承接所有流量，不僅成本高、效率低、而且還伴隨著穩定性降低的風險。

鑒於大部分業務通常是讀多寫少（讀取頻率遠遠高於更新頻率），甚至存在讀操作數量高出寫操作多個數量級的情況。因此， 在架構設計中，常採用增加緩存層來提高系統的響應能力 ，提升數據讀寫性能、減少資料庫訪問壓力，從而提升業務的穩定性和訪問體驗。

根據 CAP 原理，分布式系統在可用性、一致性和分區容錯性上無法兼得，通常由於分區容錯無法避免，所以一致性和可用性難以同時成立。對於緩存系統來說， 如何保證其數據一致性是一個在應用緩存的同時不得不解決的問題 。

需要明確的是，緩存系統的數據一致性通常包括持久化層和緩存層的一致性、以及多級緩存之間的一致性，這里我們僅討論前者。持久化層和緩存層的一致性問題也通常被稱為雙寫一致性問題，「雙寫」意為數據既在資料庫中保存一份，也在緩存中保存一份。

對於一致性來說，包含強一致性和弱一致性 ，強一致性保證寫入後立即可以讀取，弱一致性則不保證立即可以讀取寫入後的值，而是盡可能的保證在經過一定時間後可以讀取到，在弱一致性中應用最為廣泛的模型則是最終一致性模型，即保證在一定時間之後寫入和讀取達到一致的狀態。對於應用緩存的大部分場景來說，追求的則是最終一致性，少部分對數據一致性要求極高的場景則會追求強一致性。

為了達到最終一致性，針對不同的場景，業界逐步形成了下面這幾種應用緩存的策略。

— 1 —

Cache-Aside

Cache-Aside 意為旁路緩存模式，是應用最為廣泛的一種緩存策略。下面的圖示展示了它的讀寫流程，來看看它是如何保證最終一致性的。在讀請求中，首先請求緩存，若緩存命中（cache hit），則直接返回緩存中的數據；若緩存未命中（cache miss），則查詢資料庫並將查詢結果更新至緩存，然後返回查詢出的數據（demand-filled look-aside ）。在寫請求中，先更新資料庫，再刪除緩存（write-invalidate）。

1、為什麼刪除緩存，而不是更新緩存？

在 Cache-Aside 中，對於讀請求的處理比較容易理解，但在寫請求中，可能會有讀者提出疑問，為什麼要刪除緩存，而不是更新緩存？站在符合直覺的角度來看，更新緩存是一個容易被理解的方案，但站在性能和安全的角度，更新緩存則可能會導致一些不好的後果。

首先是性能 ，當該緩存對應的結果需要消耗大量的計算過程才能得到時，比如需要訪問多張資料庫表並聯合計算，那麼在寫操作中更新緩存的動作將會是一筆不小的開銷。同時，當寫操作較多時，可能也會存在剛更新的緩存還沒有被讀取到，又再次被更新的情況（這常被稱為緩存擾動），顯然，這樣的更新是白白消耗機器性能的，會導致緩存利用率不高。

而等到讀請求未命中緩存時再去更新，也符合懶載入的思路，需要時再進行計算。刪除緩存的操作不僅是冪等的，可以在發生異常時重試，而且寫-刪除和讀-更新在語義上更加對稱。

其次是安全 ，在並發場景下，在寫請求中更新緩存可能會引發數據的不一致問題。參考下面的圖示，若存在兩個來自不同線程的寫請求，首先來自線程 1 的寫請求更新了資料庫（step 1），接著來自線程 2 的寫請求再次更新了資料庫（step 3），但由於網路延遲等原因，線程 1 可能會晚於線程 2 更新緩存（step 4 晚於 step 3），那麼這樣便會導致最終寫入資料庫的結果是來自線程 2 的新值，寫入緩存的結果是來自線程 1 的舊值，即緩存落後於資料庫，此時再有讀請求命中緩存（step 5），讀取到的便是舊值。

2、為什麼先更新資料庫，而不是先刪除緩存？

另外，有讀者也會對更新資料庫和刪除緩存的時序產生疑問，那麼為什麼不先刪除緩存，再更新資料庫呢？在單線程下，這種方案看似具有一定合理性，這種合理性體現在刪除緩存成功。

但更新資料庫失敗的場景下，盡管緩存被刪除了，下次讀操作時，仍能將正確的數據寫回緩存，相對於 Cache-Aside 中更新資料庫成功，刪除緩存失敗的場景來說，先刪除緩存的方案似乎更合理一些。那麼，先刪除緩存有什麼問題呢？

問題仍然出現在並發場景下，首先來自線程 1 的寫請求刪除了緩存（step 1），接著來自線程 2 的讀請求由於緩存的刪除導致緩存未命中，根據 Cache-Aside 模式，線程 2 繼而查詢資料庫（step 2），但由於寫請求通常慢於讀請求，線程 1 更新資料庫的操作可能會晚於線程 2 查詢資料庫後更新緩存的操作（step 4 晚於 step 3），那麼這樣便會導致最終寫入緩存的結果是來自線程 2 中查詢到的舊值，而寫入資料庫的結果是來自線程 1 的新值，即緩存落後於資料庫，此時再有讀請求命中緩存（ step 5 ），讀取到的便是舊值。

另外，先刪除緩存，由於緩存中數據缺失，加劇資料庫的請求壓力，可能會增大緩存穿透出現的概率。

3、如果選擇先刪除緩存，再更新資料庫，那如何解決一致性問題呢？

為了避免「先刪除緩存，再更新資料庫」這一方案在讀寫並發時可能帶來的緩存臟數據，業界又提出了延時雙刪的策略，即在更新資料庫之後，延遲一段時間再次刪除緩存，為了保證第二次刪除緩存的時間點在讀請求更新緩存之後，這個延遲時間的經驗值通常應稍大於業務中讀請求的耗時。

延遲的實現可以在代碼中 sleep 或採用延遲隊列。顯而易見的是，無論這個值如何預估，都很難和讀請求的完成時間點准確銜接，這也是延時雙刪被詬病的主要原因。

4、那麼 Cache-Aside 存在數據不一致的可能嗎？

在 Cache-Aside 中，也存在數據不一致的可能性。在下面的讀寫並發場景下，首先來自線程 1 的讀請求在未命中緩存的情況下查詢資料庫（step 1），接著來自線程 2 的寫請求更新資料庫（step 2），但由於一些極端原因，線程 1 中讀請求的更新緩存操作晚於線程 2 中寫請求的刪除緩存的操作（step 4 晚於 step 3），那麼這樣便會導致最終寫入緩存中的是來自線程 1 的舊值，而寫入資料庫中的是來自線程 2 的新值，即緩存落後於資料庫，此時再有讀請求命中緩存（step 5），讀取到的便是舊值。

這種場景的出現，不僅需要緩存失效且讀寫並發執行，而且還需要讀請求查詢資料庫的執行早於寫請求更新資料庫，同時讀請求的執行完成晚於寫請求。足以見得，這種 不一致場景產生的條件非常嚴格，在實際的生產中出現的可能性較小 。

除此之外，在並發環境下，Cache-Aside 中也存在讀請求命中緩存的時間點在寫請求更新資料庫之後，刪除緩存之前，這樣也會導致讀請求查詢到的緩存落後於資料庫的情況。

雖然在下一次讀請求中，緩存會被更新，但如果業務層面對這種情況的容忍度較低，那麼可以採用加鎖在寫請求中保證「更新資料庫&刪除緩存」的串列執行為原子性操作（同理也可對讀請求中緩存的更新加鎖）。 加鎖勢必會導致吞吐量的下降，故採取加鎖的方案應該對性能的損耗有所預期。

— 2 —

補償機制

我們在上面提到了，在 Cache-Aside 中可能存在更新資料庫成功，但刪除緩存失敗的場景，如果發生這種情況，那麼便會導致緩存中的數據落後於資料庫，產生數據的不一致的問題。

其實，不僅 Cache-Aside 存在這樣的問題，在延時雙刪等策略中也存在這樣的問題。針對可能出現的刪除失敗問題，目前業界主要有以下幾種補償機制。

1、刪除重試機制

由於同步重試刪除在性能上會影響吞吐量，所以常通過引入消息隊列，將刪除失敗的緩存對應的 key 放入消息隊列中，在對應的消費者中獲取刪除失敗的 key ，非同步重試刪除。這種方法在實現上相對簡單，但由於刪除失敗後的邏輯需要基於業務代碼的 trigger 來觸發 ，對業務代碼具有一定入侵性。

鑒於上述方案對業務代碼具有一定入侵性，所以需要一種更加優雅的解決方案，讓緩存刪除失敗的補償機制運行在背後，盡量少的耦合於業務代碼。一個簡單的思路是通過後台任務使用更新時間戳或者版本作為對比獲取資料庫的增量數據更新至緩存中，這種方式在小規模數據的場景可以起到一定作用，但其擴展性、穩定性都有所欠缺。

一個相對成熟的方案是基於 MySQL 資料庫增量日誌進行解析和消費，這里較為流行的是阿里巴巴開源的作為 MySQL binlog 增量獲取和解析的組件 canal（類似的開源組件還有 Maxwell、Databus 等）。

canal sever 模擬 MySQL slave 的交互協議，偽裝為 MySQL slave，向 MySQL master 發送 mp 協議，MySQL master 收到 mp 請求，開始推送 binary log 給 slave （即 canal sever ），canal sever 解析 binary log 對象（原始為 byte 流），可由 canal client 拉取進行消費，同時 canal server 也默認支持將變更記錄投遞到 MQ 系統中，主動推送給其他系統進行消費。

在 ack 機制的加持下，不管是推送還是拉取，都可以有效的保證數據按照預期被消費。當前版本的 canal 支持的 MQ 有 Kafka 或者 RocketMQ。另外， canal 依賴 ZooKeeper 作為分布式協調組件來實現 HA ，canal 的 HA 分為兩個部分：

那麼，針對緩存的刪除操作便可以在 canal client 或 consumer 中編寫相關業務代碼來完成。這樣，結合資料庫日誌增量解析消費的方案以及 Cache-Aside 模型，在讀請求中未命中緩存時更新緩存（通常這里會涉及到復雜的業務邏輯），在寫請求更新資料庫後刪除緩存，並基於日誌增量解析來補償資料庫更新時可能的緩存刪除失敗問題，在絕大多數場景下，可以有效的保證緩存的最終一致性。

另外需要注意的是，還應該隔離事務與緩存，確保資料庫入庫後再進行緩存的刪除操作。 比如考慮到資料庫的主從架構，主從同步及讀從寫主的場景下，可能會造成讀取到從庫的舊數據後便更新了緩存，導致緩存落後於資料庫的問題，這就要求對緩存的刪除應該確保在資料庫操作完成之後。所以，基於 binlog 增量日誌進行數據同步的方案，可以通過選擇解析從節點的 binlog，來避免主從同步下刪除緩存過早的問題。

3、數據傳輸服務 DTS

— 3 —

Read-Through

Read-Through 意為讀穿透模式，它的流程和 Cache-Aside 類似，不同點在於 Read-Through 中多了一個訪問控制層，讀請求只和該訪問控制層進行交互，而背後緩存命中與否的邏輯則由訪問控制層與數據源進行交互，業務層的實現會更加簡潔，並且對於緩存層及持久化層交互的封裝程度更高，更易於移植。

— 4 —

Write-Through

Write-Through 意為直寫模式，對於 Write-Through 直寫模式來說，它也增加了訪問控制層來提供更高程度的封裝。不同於 Cache-Aside 的是，Write-Through 直寫模式在寫請求更新資料庫之後，並不會刪除緩存，而是更新緩存。

這種方式的 優勢在於讀請求過程簡單 ，不需要查詢資料庫更新緩存等操作。但其劣勢也非常明顯，除了上面我們提到的更新資料庫再更新緩存的弊端之外，這種方案還會造成更新效率低，並且兩個寫操作任何一次寫失敗都會造成數據不一致。

如果要使用這種方案， 最好可以將這兩個操作作為事務處理，可以同時失敗或者同時成功，支持回滾，並且防止並發環境下的不一致 。另外，為了防止緩存擾動的頻發，也可以給緩存增加 TTL 來緩解。

站在可行性的角度，不管是 Write-Through 模式還是 Cache-Aside 模式，理想狀況下都可以通過分布式事務保證緩存層數據與持久化層數據的一致性，但在實際項目中，大多都對一致性的要求存在一些寬容度，所以在方案上往往有所折衷。

Write-Through 直寫模式適合寫操作較多，並且對一致性要求較高的場景，在應用 Write-Through 模式時，也需要通過一定的補償機制來解決它的問題。首先，在並發環境下，我們前面提到了先更新資料庫，再更新緩存會導致緩存和資料庫的不一致，那麼先更新緩存，再更新資料庫呢？

這樣的操作時序仍然會導致下面這樣線程 1 先更新緩存，最後更新資料庫的情況，即由於線程 1 和 線程 2 的執行不確定性導致資料庫和緩存的不一致。這種由於線程競爭導致的緩存不一致，可以通過分布式鎖解決，保證對緩存和資料庫的操作僅能由同一個線程完成。對於沒有拿到鎖的線程，一是通過鎖的 timeout 時間進行控制，二是將請求暫存在消息隊列中順序消費。

在下面這種並發執行場景下，來自線程 1 的寫請求更新了資料庫，接著來自線程 2 的讀請求命中緩存，接著線程 1 才更新緩存，這樣便會導致線程 2 讀取到的緩存落後於資料庫。同理，先更新緩存後更新資料庫在寫請求和讀請求並發時，也會出現類似的問題。面對這種場景，我們也可以加鎖解決。

另在，在 Write-Through 模式下，不管是先更新緩存還是先更新資料庫，都存在更新緩存或者更新資料庫失敗的情況，上面提到的重試機制和補償機制在這里也是奏效的。

— 5 —

Write-Behind

Write behind 意為非同步回寫模式，它也具有類似 Read-Through/Write-Through 的訪問控制層，不同的是，Write behind 在處理寫請求時，只更新緩存而不更新資料庫，對於資料庫的更新，則是通過批量非同步更新的方式進行的，批量寫入的時間點可以選在資料庫負載較低的時間進行。

在 Write-Behind 模式下，寫請求延遲較低，減輕了資料庫的壓力，具有較好的吞吐性。但資料庫和緩存的一致性較弱，比如當更新的數據還未被寫入資料庫時，直接從資料庫中查詢數據是落後於緩存的。同時，緩存的負載較大，如果緩存宕機會導致數據丟失，所以需要做好緩存的高可用。顯然，Write behind 模式下適合大量寫操作的場景，常用於電商秒殺場景中庫存的扣減。

— 6 —

Write-Around

如果一些非核心業務，對一致性的要求較弱，可以選擇在 cache aside 讀模式下增加一個緩存過期時間，在寫請求中僅僅更新資料庫，不做任何刪除或更新緩存的操作，這樣，緩存僅能通過過期時間失效。這種方案實現簡單，但緩存中的數據和資料庫數據一致性較差，往往會造成用戶的體驗較差，應慎重選擇。

— 7 —

總結

在解決緩存一致性的過程中，有多種途徑可以保證緩存的最終一致性，應該根據場景來設計合適的方案，讀多寫少的場景下，可以選擇採用「Cache-Aside 結合消費資料庫日誌做補償」的方案，寫多的場景下，可以選擇採用「Write-Through 結合分布式鎖」的方案 ，寫多的極端場景下，可以選擇採用「Write-Behind」的方案。

㈤ 如何設置適當的磁碟緩存

當然，如果同時下載的任務增大了，下載的總吞吐量提高了，也有必要查看一下緩存，根據調整原則，在需要的時候且有空閑內存的時候，將緩存上限加大。
一般的原則是：
在「全局統計」中可以看到：
當前磁碟緩存大小: 0 B (最少: 6 MB, 最多: 96 MB ), 數據共佔用內存: 0 B
當前空閑物理內存: 400.97 MB (最少保證: 50 MB)
磁碟讀請求次數總計: 0 (頻率:0.0次每秒), 實際磁碟讀次數:0 (頻率:0.0次每秒), 讀命中率:0.0%
磁碟寫請求次數總計: 0 (頻率:0.0次每秒), 實際磁碟寫次數:0 (頻率:0.0次每秒), 寫命中率:0.0%
如果「當前磁碟緩存大小」基本等於「最多：」，說明緩存幾乎用盡，可以考慮增大緩存上限，當增大時，一般也會看到「當前磁碟緩存大小」隨之上升，同時看到「實際磁碟讀次數」和「實際磁碟寫次數」有降低，說明增加的緩存對減少磁碟訪問起了作用，這時往往你可以看到硬碟燈閃的頻率明顯降低，而且附帶結果應當也看到「命中率」有提高，說明增加緩存對保護磁碟起了作用。當增加緩存上限，到了「當前磁碟緩存大小」小於「最多：」的狀態，且「當前磁碟緩存大小」並未持續提高，說明緩存已經足夠大，這時也沒有必要降低上限，因為BitComet對用不到的容量不會無故佔用。
其實BitComet提供了根據以上原則自動調整緩存的功能，只需將你希望一定保證系統預留的的內存設置出來，比如上面的樣本，我如果希望內存至少預留128MB，「主菜單→選項→磁碟緩存→減小緩存當空閑物理內存低於」設置為128MB，「主菜單→選項→磁碟緩存→磁碟緩存最大值」可以設置得很大，反正128MB的限制是存在的
所以有人說設置得高一點是有道理的，前提是你把預留的空閑物理內存留夠了，上限設置得比較大基本上只有好處沒有壞處，我能想到的唯一壞處就是：如果你在BT的時候頻繁進行佔用、釋放、佔用、釋放內存的操作，比如啟動一個程序，然後很快又退出，然後啟動另一個程序，又退出，這種情況下如果BT的緩存又佔用比較滿，會根據你設置的預留空間，頻繁降低緩存、增大緩存，在降低緩存的時候，就會導致強行將需要騰出來的緩存中的數據寫到磁碟，反而增加了磁碟訪問頻繁度。
但這個壞處需要同時滿足3個條件才成立：
1、頻繁進行佔用、釋放內存的操作
2、緩存佔用比較滿
3、空餘內存接近BT中設置的預留數
所以還是比較難於碰到的