緩存版本號

Ⅰ 如何自動給CSS、JS添加版本號防止客戶端緩存。

怎麼說呢，個人有個笨點的辦法，就是在代碼中加上JS版本號的全局變數，應用JS時利用後台代碼添加。
這樣更改過JS時，將JS的文件名後邊帶上個自定義的版本號，再將JS版本號的變數修改一下就好了。其他程序由於是動態的讀取JS文件名，所以不用再修改，也不用怕漏改。

Ⅱ 認識HTTP----緩存篇

本文內容大多參考 《圖解HTTP》一書

所以講緩存為什麼要先扯代理伺服器？別急，讓我們看一下一個請求的簡單示意圖。

我們看到客戶端(用戶)發送了一個請求並不是直接發給源伺服器的而是經過了代理伺服器，然後經由代理伺服器再發送給源伺服器，響應也同樣遵循這個順序。
那麼代理伺服器在這中間擔任了什麼角色？

緩存是指代理伺服器或客戶端本地磁碟內保存的資源副本。利用緩存可減少對源伺服器的訪問，因此也就節省了通信流量和通信時間。
緩存伺服器是代理伺服器的一種，並歸類在緩存代理類型中。換句話說，當代理轉發從伺服器返回的響應時，代理伺服器將會保存一份資源的副本。

緩存伺服器的優勢在於利用緩存可避免多次從源伺服器轉發資源。因此客戶端可就近從緩存伺服器上獲取資源，而源伺服器也不必多次處理相同的請求了。

即便緩存伺服器和客戶端內有緩存，也不能每次都給我返回緩存吧，如果是這樣，源伺服器更新了我也不知道，因為我每次都是看緩存的資源。
為了解決這個問題，針對緩存設計了時效性的概念：
即使存在緩存，也會因為客戶端的要求、緩存的有效期等因素，向源伺服器確認資源的有效性。若判斷緩存失效，緩存伺服器將會再次從源伺服器上獲取「新」資源。

緩存不僅可以存在於緩存伺服器內，還可以存在客戶端瀏覽器中。以Internet Explorer 程序為例，把客戶端緩存稱為臨時網路文件（Temporary Internet File）。
瀏覽器緩存如果有效，就不必再向伺服器請求相同的資源了，可以直接從本地磁碟內讀取。
另外，和緩存伺服器相同的一點是，當判定緩存過期後，會向源伺服器確認資源的有效性。若判斷瀏覽器緩存失效，瀏覽器會再次請求新資源。

Pragma 是HTTP/1.1 之前版本的歷史遺留欄位，僅作為與HTTP/1.0的向後兼容而定義。
規范定義的形式唯一，如下所示。
Pragma: no-cache
該首部欄位屬於通用首部欄位，但只用在客戶端發送的請求中。客戶端會要求所有的中間伺服器不返回緩存的資源。

通過指定首部欄位Cache-Control 的指令，就能操作緩存的工作機制。

可用的指令按請求和響應分類如下所示:

public指令
Cache-Control: public
當指定使用public 指令時，則明確表明其他用戶也可利用緩存。
private指令

no-store指令
Cache-Control: no-store
當使用no-store 指令時，暗示請求（和對應的響應）或響應中包含機密信息。
因此，該指令規定緩存不能在本地存儲請求或響應的任一部分。

ps:從字面意思上很容易把no-cache誤解成為不緩存，但事實上no-cache代表不緩存過期的資源，緩存會向源伺服器進行有效期確認後處理資源，也許稱為do-not-serve-from-cache-without-revalidation更合適。no-store 才是真正地不進行緩存，請讀者注意區別理解。

s-maxage指令
Cache-Control: s-maxage=604800 //（單位：秒）
s-maxage 指令的功能和max-age 指令的功能相同， 它們的不同點是s-maxage 指令只適用於供多位用戶使用的公共緩存伺服器(這里指代理伺服器)。也就是說，對於向同一用戶重復返回響應的伺服器來說，這個指令沒有任何作用。
另外，當使用s-maxage 指令後，則直接忽略對Expires 首部欄位及max-age 指令的處理。
max-age指令

cache-extension token
Cache-Control: private, community="UCI"
通過 cache-extension 標記（token），可以擴展Cache-Control 首部欄位內的指令。
如上例，Cache-Control 首部欄位本身沒有community 這個指令。藉助extension tokens 實現了該指令的添加。如果緩存伺服器不能理community 這個新指令，就會直接忽略。因此，extension tokens 僅對能理解它的緩存伺服器來說是有意義的。

If-Unmodified-Since: Thu, 03 Jul 2012 00:00:00 GMT
首部欄位If-Unmodified-Since 和首部欄位If-Modified-Since 的作用相反。它的作用的是告知伺服器，指定的請求資源只有在欄位值內指定的日期時間之後，未發生更新的情況下，才能處理請求。如果在指定日期時間後發生了更新，則以狀態碼412 Precondition Failed 作為響應返回。

ps:Last-Modified 存在一定問題，如果在伺服器上，一個資源被修改了，但其實際內容根本沒發生改變，會因為Last-Modified時間匹配不上而返回了整個實體給客戶端（即使客戶端緩存里有個一模一樣的資源）。

首部欄位If-None-Match 屬於附帶條件之一。它和首部欄位If-Match 作用相反。用於指定If-None-Match 欄位值的實體標記（ETag）值與請求資源的ETag 不一致時，它就告知伺服器處理該請求。
在GET 或HEAD 方法中使用首部欄位If-None-Match 可獲取最新的資源。因此，這與使用首部欄位If-Modified-Since 時有些類似。

不與伺服器確認，而是直接使用瀏覽器緩存的內容。其中響應內容和之前的響應內容一模一樣，例如其中的Date時間是上一次響應的時間。

F5的作用和直接在URI輸入欄中輸入然後回車是不一樣的，F5會讓瀏覽器無論如何都發一個HTTP Request給Server，即使先前的響應中有Expires頭部。

Ctrl+F5要的是徹底的從Server拿一份新的資源過來，所以不光要發送HTTP request給Server，而且這個請求裡面連If-Modified-Since/If-None-Match都沒有，這樣就逼著Server不能返回304，而是把整個資源原原本本地返回一份，這樣，Ctrl+F5引發的傳輸時間變長了，自然網頁Refresh的也慢一些。

Cache-Control 是 HTTP1.1 才有的，不適用於 HTTP1.0，而 Expires 既適用於 HTTP1.0，也適用於 HTTP1.1，所以說在大多數情況下同時發送這兩個頭會是一個更好的選擇，當客戶端兩種頭都能解析的時候，會優先使用 Cache-Control。

二者都是通過某個標識值來請求資源， 如果伺服器端的資源沒有變化，則自動返回 HTTP 304 （Not Changed）狀態碼，內容為空，這樣就節省了傳輸數據量。當資源變化後則返回新資源。從而保證不向客戶端重復發出資源，也保證當伺服器有變化時，客戶端能夠得到最新的資源。
其中Last-Modified使用文件最後修改作為文件標識值，它無法處理文件一秒內多次修改的情況，而且只要文件修改了哪怕文件實質內容沒有修改，也會重新返回資源內容；ETag作為「被請求變數的實體值」，其完全可以解決Last-Modified頭部的問題，但是其計算過程需要耗費伺服器資源。

Expires和Cache-Control都有一個問題就是服務端的修改，如果還在緩存時效里，那麼客戶端是不會去請求服務端資源的（非刷新），這就存在一個資源版本不符的問題，而強制刷新一定會發起HTTP請求並返回資源內容，無論該內容在這段時間內是否修改過；而Last-Modified和Etag每次請求資源都會發起請求，哪怕是很久都不會有修改的資源，都至少有一次請求響應的消耗。
對於所有可緩存資源，指定一個Expires或Cache-Control max-age以及一個Last-Modified或ETag至關重要。同時使用前者和後者可以很好的相互適應。
前者不需要每次都發起一次請求來校驗資源時效性，後者保證當資源未出現修改的時候不需要重新發送該資源。而在用戶的不同刷新頁面行為中，二者的結合也能很好的利用HTTP緩存控制特性，無論是在地址欄輸入URI然後輸入回車進行訪問，還是點擊刷新按鈕，瀏覽器都能充分利用緩存內容，避免進行不必要的請求與數據傳輸。

做法很簡單，就是把可能會更新的資源以版本形式發布，常用的方法是在文件名或參數帶上一串md5或時間標記符：

可以看到上面的例子中有不同的做法，有的在URI後面加上了md5參數，有的將md5值作為文件名的一部分，有的將資源放在特性版本的目錄中。
那麼在文件沒有變動的時候，瀏覽器不用發起請求直接可以使用緩存文件；而在文件有變化的時候，由於文件版本號的變更，導致文件名變化，請求的url變了，自然文件就更新了。這樣能確保客戶端能及時從伺服器收取到新修改的文件。通過這樣的處理，增長了靜態資源，特別是圖片資源的緩存時間，避免該資源很快過期，客戶端頻繁向服務端發起資源請求，伺服器再返回304響應的情況（有Last-Modified/Etag）。

Ⅲ sass構建CSS時，如何給文件隨機加版本號，以防止老文件緩存

1、線上的時候：在模板文件里對css跟js的引入路徑後面追加一個類似於常量來做版本號
<link rel="stylesheet" href="style.css?version=20150828" />
2、線下測試的時候：對css跟js的引入路徑後面追加隨機數，時時刻刻更新，避免緩存影響了調試。
3、線下測試後：升級常量的版本號，把代碼更新上去，這樣用戶的瀏覽器刷新就用到了新的樣式，而又用到了緩存。

Ⅳ 【瀏覽器緩存問題】HTML靜態文件中，css和js可以添加版本號來刷新緩存，但是只是修改的文字了呢

給網址後面添加一個隨機數（或者是任意的字元串）即可，比如原來的網址是這樣的：
http....../.../1.htm
改為
http....../.../1.htm?1234
即可（注意問號不能省）。
瀏覽器是根據網址來緩存的，所以只要給網址接個尾巴，瀏覽器就會認為是新網址，就會從網上重新下載數據了。當然，如果下次再次改變了網頁內容，這個尾巴就要再次修改。
給css和js添加所謂版本號其實也是同一個原理。這個版本號其實就是給css和js的網址接個尾巴而已。
這個也同樣適用網頁裡面的圖片、音樂等資源，事實上只要是http協議的元素都可以利用這個辦法來避開緩存實時刷新。

Ⅳ Tair 分布式緩存簡介

Tair是由阿里巴巴自主研發的高性能高可用的分布式Key/Value結構數據存儲系統，在阿里內部有著大規模的應用。

作為一個分布式系統，Tair由一個中心控制節點（config server）和一系列的服務節點（data server）組成，

Tair主要有下面三種存儲引擎：

根據CAP理論，在分布式存儲系統中，最多隻能實現一致性、可靠性和分區容錯性三點中的兩點。而由於網路硬體肯定會出現延遲丟包等問題，所以分區容錯性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡。

Tair 選擇了一致性，同時採用復制技術來提高可靠性，並且為了提高效率做了一些優化。事實上在沒有錯誤發生的時候，tair 提供的是一種強一致性，但是在有data server發生故障的時候，客戶有可能在一定時間窗口內讀不到最新的數據，甚至發生最新數據丟失的情況。

Tair中的每個數據都包含版本號，版本號在每次更新後都會遞增。這個特性可以幫助防止數據的並發更新導致的問題。version 機制是樂觀鎖常用的實現方式。

tair 的存儲引擎可以是 MDB、LDB 或 RDB。它們使用緩存、內存或 SSD 硬碟（LDB） 來提升性能。

configserver 不是傳統的中心節點，掛了對集群的服務無影響

Tair 使用一致性哈希作為負載均衡策略。

當有某台data server故障不可用的時候， config server會發現這個情況， config server負責重新計算一張新的桶在data server上的分布表， 將原來由故障機器服務的桶的訪問重新指派到其它的data server中。這個時候， 可能會發生數據的遷移。比如原來由data server A負責的桶，在新表中需要由 B負責。而B上並沒有該桶的數據， 那麼就將數據遷移到B上來。同時config server會發現哪些桶的備份數目減少了， 然後根據負載情況在負載較低的data server上增加這些桶的備份。當系統增加data server的時候， config server根據負載，協調data server將他們控制的部分桶遷移到新的data server上。遷移完成後調整路由。當然系統中可能出現減少了某些data server 同時增加另外的一些data server。處理原理同上。 每次路由的變更，config server都會將新的配置信息推給data server。在客戶端訪問data server的時候， 會發送客戶端緩存的路由表的版本號。如果data server發現客戶端的版本號過舊，則會通知客戶端去config server取一次新的路由表。如果客戶端訪問某台data server 發生了不可達的情況(該 data server可能宕機了)，客戶端會主動去config server取新的路由表。

當遷移發生的時候， 我們舉個例子， 假設data server A 要把桶 3，4，5 遷移給data server B。因為遷移完成前，客戶端的路由表沒有變化，客戶端對 3， 4， 5 的訪問請求都會路由到A。現在假設 3還沒遷移， 4 正在遷移中， 5已經遷移完成。那麼如果是對3的訪問， 則沒什麼特別， 跟以前一樣。如果是對5的訪問， 則A會把該請求轉發給B，並且將B的返回結果返回給客戶，如果是對4的訪問，在A處理，同時如果是對4的修改操作會記錄修改log。當桶4遷移完成的時候，還要把log發送到B，在B上應用這些log。最終A B上對於桶4來說， 數據完全一致才是真正的遷移完成。當然如果是因為某data server宕機而引發的遷移， 客戶端會收到一張中間臨時狀態的分配表。這張表中，把宕機的data server所負責的桶臨時指派給有其備份data server來處理。 這個時候服務是可用的，但是負載可能不均衡。當遷移完成之後，才能重新達到一個新的負載均衡的狀態。

https://yq.aliyun.com/articles/52059

https://www.cnblogs.com/jiangxiulian/p/8027739.html