協商緩存集群

A. 靜態資源常用的一種緩存方式

http緩存分為強緩存和協商緩存。
強緩存並不會請求伺服器，同時響應碼會返回200。比如使用的配置cache-control:max-age=1200

在項目中緩存圖片等靜態資源常用的是協商緩存。
在第一次請求靜態資源的時候，伺服器會根據資源內容生成etag， 在響應頭里返回給瀏覽器，在下次請求的時候瀏覽器會在頭部配置If-None-Match，攜帶etag來向伺服器詢問資源是否發生改變。若是沒有發生改變會返回304，這樣瀏覽器就不會從伺服器重新獲取資源而是直接使用本地緩存。採用etag可以解決文件名沒有發生變化但是文件內容被修改的問題。

通常會跟cache-control: no-cache 在一起配合使用。no-cache是指瀏覽器可以緩存響應，但是必須要向原始伺服器提交驗證請求。

參考：
https://www.imperva.com/learn/performance/cache-control/
https://blog.csdn.net/aimeimeiTS/article/details/105731709
https://www.zoo.team/article/http-cache
https://imweb.io/topic/5795dcb6fb312541492eda8c
https://aotu.io/notes/2016/09/22/http-caching/index.html

B. 高性能高並發網站架構，教你搭建Redis5緩存集群

一、Redis集群介紹

Redis真的是一個優秀的技術，它是一種key-value形式的Nosql內存資料庫，由ANSI C編寫，遵守BSD協議、支持網路、可基於內存亦可持久化的日誌型、Key-Value資料庫，並提供多種語言的API。 Redis最大的特性是它會將所有數據都放在內存中，所以讀寫速度性能非常好。Redis是基於內存進行操作的，性能較高，可以很好的在一定程度上解決網站一瞬間的並發量，例如商品搶購秒殺等活動。

網站承受高並發訪問壓力的同時，還需要從海量數據中查詢出滿足條件的數據，需要快速響應，前端發送請求、後端和mysql資料庫交互，進行sql查詢操作，讀寫比較慢，這時候引入Redis ,把從mysql 的數據緩存到Redis 中，下次讀取時候性能就會提高；當然，它也支持將內存中的數據以快照和日誌的形式持久化到硬碟，這樣即使在斷電、機器故障等異常情況發生時數據也不會丟失，Redis能從硬碟中恢復快照數據到內存中。

Redis 發布了穩定版本的 5.0 版本，放棄 Ruby的集群方式，改用 C語言編寫的 redis-cli的方式，是集群的構建方式復雜度大大降低。Redis-Cluster集群採用無中心結構，每個節點保存數據和整個集群狀態，每個節點都和其他所有節點連接。

為了保證數據的高可用性，加入了主從模式，一個主節點對應一個或多個從節點，主節點提供數據存取，從節點則是從主節點拉取數據備份，當這個主節點掛掉後，就會有這個從節點選取一個來充當主節點，從而保證集群不會掛掉。

redis-cluster投票:容錯，投票過程是集群中所有master參與,如果半數以上master節點與master節點通信超過(cluster-node-timeout),認為當前master節點掛掉。

集群中至少應該有奇數個節點，所以至少有三個節點，每個節點至少有一個備份節點，所以下面使用6節點（主節點、備份節點由redis-cluster集群確定）。6個節點分布在一台機器上，採用三主三從的模式。實際應用中，最好用多台機器，比如說6個節點分布到3台機器上，redis在建立集群時為自動的將主從節點進行不同機器的分配。

二、單機redis模式

下載源碼redis5.0並解壓編譯

wget http://download.redis.io/releases/redis-5.0.0.tar.gz

tar xzf redis-5.0.0.tar.gz

cd redis-5.0.0

make

redis前端啟動需要改成後台啟動.

修改redis.conf文件,將daemonize no -> daemonize yes

vim redis.conf

啟動redis

/www/server/redis/src/redis-server /www/server/redis/redis.conf

查看redis是否在運行

ps aux|grep redis

現在是單機redis模式完成。

三、redis集群模式：

1.創建6個Redis配置文件

cd /usr/local/

mkdir redis_cluster //創建集群目錄

cd redis_cluster

mkdir 7000 7001 7002 7003 7004 7005//分別代表6個節點

其對應埠 7000 7001 7002 70037004 7005

2.復制配置文件到各個目錄

cp /www/server/redis/redis.conf /usr/local/redis_cluster/7000/

cp /www/server/redis/redis.conf /usr/local/redis_cluster/7001/

cp /www/server/redis/redis.conf /usr/local/redis_cluster/7002/

cp /www/server/redis/redis.conf /usr/local/redis_cluster/7003/

cp /www/server/redis/redis.conf /usr/local/redis_cluster/7004/

cp /www/server/redis/redis.conf /usr/local/redis_cluster/7005/

3.分別修改配置文件

vim /usr/local/redis_cluster/7000/redis.conf

vim /usr/local/redis_cluster/7001/redis.conf

vim /usr/local/redis_cluster/7002/redis.conf

vim /usr/local/redis_cluster/7003/redis.conf

vim /usr/local/redis_cluster/7004/redis.conf

vim /usr/local/redis_cluster/7005/redis.conf

如下

port 7000 #埠

cluster-enabled yes #啟用集群模式

cluster-config-file nodes_7000.conf ＃集群的配置 配置文件首次啟動自動生成

cluster-node-timeout 5000 #超時時間 5秒

appendonly yes ＃aof日誌開啟 它會每次寫操作都記錄一條日誌

daemonize yes #後台運行

protected-mode no #非保護模式

pidfile /var/run/redis_7000.pid

//下面可以不寫

#若設置密碼，master和slave需同時配置下面兩個參數：

masterauth "jijiji" #連接master的密碼

requirepass "jijiji" #自己的密碼

cluster-config-file，port，pidfile對應數字

4.啟動節點

cd /www/server/redis/src/

./redis-server /usr/local/redis_cluster/7000/redis.conf

./redis-server /usr/local/redis_cluster/7001/redis.conf

./redis-server /usr/local/redis_cluster/7002/redis.conf

./redis-server /usr/local/redis_cluster/7003/redis.conf

./redis-server /usr/local/redis_cluster/7004/redis.conf

./redis-server /usr/local/redis_cluster/7005/redis.conf

查看redis運行

ps aux|grep redis

5.啟動集群

/www/server/redis/src/redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1

這里使用的命令是create，因為我們要創建一個新的集群。 該選項--cluster-replicas 1意味著我們希望每個創建的主伺服器都有一個從服。

輸入yes

至此，Reids5 集群搭建完成。

6.檢查Reids5集群狀態

可以執行redis-cli --cluster check host:port檢查集群狀態slots詳細分配。

redis-cli --cluster info 127.0.0.1:7000

7.停止Reids5集群

（1）.因為Redis可以妥善處理SIGTERM信號，所以直接kill -9也是可以的，可以同時kill多個,然後再依次啟動。

kill -9 PID PID PID

（2）.redis5 提供了關閉集群的工具，修改文件： /www/server/redis/utils/create-cluster/create-cluster

埠PROT設置為6999，NODES為6，工具會生成 7000-7005 六個節點 用於操作。

修改後，執行如下命令關閉集群：

/www/server/redis/utils/create-cluster/create-cluster stop

重新啟動集群：

/www/server/redis/utils/create-cluster/create-cluster start

8.幫助信息

執行redis-cli --cluster help,查看更多幫助信息

redis-cli --cluster help

吉海波

C. 緩存是什麼 深入解析網頁緩存機制

緩存是指在計算機系統中，將數據暫時存儲在高速緩存中，以提高數據訪問速度的一種技術。在網頁瀏覽器中，也存在著網頁緩存機制，它可以使用戶在訪問同一網頁時，不必每次都從伺服器重新獲取數據，而是從本地緩存中讀取數據，從而提高網頁的訪問速度。

緩存是指在計算機系統中，將數據暫時存儲在高速緩存中，以提高數據訪問速度的一種技術。在網頁瀏覽器中，也存在著網頁緩存機制，它可以使用戶在訪問同一網頁時，不必每次都從伺服器重新獲取數據，而是從本地緩存中讀取數據，從而提高網頁的訪問速度。

協商緩存是指在第一次訪問網頁時，伺服器返回的響應頭中包含了緩存標識，瀏覽器會將該網頁緩存在本地，並在下次訪問時將該緩存標識發送給伺服器，詢問伺服器該網頁是否有更新。如果伺服器返回的響應頭中包含了「304 Not Modified」配咐的狀培森純態碼，則表示該網頁沒有更新，瀏覽器會直接從本地緩存中讀取數據，否則就從伺服器上重新獲取數據。

網頁緩存是指將已經訪問過的網頁內容保存在用戶的本地存儲中，以便下次訪問時可以更快速地載入頁面。當用戶訪問一個網頁時，瀏覽器會首先查看本地緩存中是否存在該網頁的春枝副本，如果存在，則直接從緩存中讀取，否則就從伺服器上重新獲取數據。

強制緩存是指在第一次訪問網頁時，伺服器返回的響應頭中包含了緩存時間，瀏覽器會將該網頁緩存在本地，並在緩存時間內不會向伺服器發送請求。當緩存時間過期後，瀏覽器會再次向伺服器發送請求，重新獲取數據。

緩存是指在計算機系統中，將數據暫時存儲在高速緩存中，以提高數據訪問速度的一種技術。在網頁瀏覽器中，也存在著網頁緩存機制，它可以使用戶在訪問同一網頁時，不必每次都從伺服器重新獲取數據，而是從本地緩存中讀取數據，從而提高網頁的訪問速度。

D. 瀏覽器緩存原理簡述

緩存文件存儲方式有2種：內存和硬碟。為了提高文件讀取速度，瀏覽器優先讀內存中的緩存文件（如果存在的話）。

按照本地緩存階段和協商緩存階段分類：

緩存的策略由http消息頭Cache-Control確定，以下為各個值對應的效果：
Cache-Control：public ：所有內容都將被緩存（客戶端和代理伺服器都可緩存）
Cache-Control：private ：所有內容只有客戶端可以緩存
Cache-Control：no-cache ：默認值。客戶端緩存內容，但是是否使用緩存則需要經過協商緩存來驗證決定
Cache-Control：no-store ：所有內容都不會被緩存，即不使用強制緩存，也不使用協商緩存
Cache-Control：max-age=xxx (xxx is numeric) ：緩存內容將在xxx秒後失效

HTTP1.0 的特性，標識該資源過期的時間點，它是一個絕對值，格林威治時間（Greenwich Mean Time, GMT），即在這個時間點之後，緩存的資源過期； 優先順序：Cache-Control 優先順序高於 Expires ，為了兼容，通常兩個頭部同時設置；瀏覽器默認行為：其實就算 Response Header 中沒有設置 Cache-Control 和 Expires，瀏覽器仍然會緩存某些資源，這是瀏覽器的默認行為，是為了提升性能進行的優化，每個瀏覽器的行為可能不一致，有些瀏覽器甚至沒有這樣的優化。

Last-Modified (Response Header)與 If-Modified-Since (Request Header)是一對報文頭，屬於 http 1.0。

If-Modified-Since 是一個請求首部欄位，並且只能用在 GET 或者 HEAD 請求中。Last-Modified 是一個響應首部欄位，包含伺服器認定的資源作出修改的日期及時間。當帶著 If-Modified-Since 頭訪問伺服器請求資源時，伺服器會檢查 Last-Modified，如果 Last-Modified 的時間早於或等於 If-Modified-Since 則會返回一個不帶主體的 304 響應，否則將重新返回資源。

ETag 與 If-None-Match 是一對報文頭，屬於 http 1.1。

ETag 是一個響應首部欄位，它是根據實體內容生成的一段 hash 字元串，標識資源的狀態，由服務端產生。If-None-Match 是一個條件式的請求首部。如果請求資源時在請求首部加上這個欄位，值為之前伺服器端返回的資源上的 ETag，則當且僅當伺服器上沒有任何資源的 ETag 屬性值與這個首部中列出的時候，伺服器才會返回帶有所請求資源實體的 200 響應，否則伺服器會返回不帶實體的 304 響應。

E. 如何理解redis+tomcat+nginx集群緩存

Nginx是一款輕量級兼備高性能的Http和反向代理伺服器。
所謂反向代理就是指在用戶發起訪問請求，由代理伺服器接收，然後將請求轉發給正式伺服器，並且將正式伺服器處理完的數據返回給客戶端，此時代理伺服器就表現為一個伺服器。

F. EhCache 分布式緩存/緩存集群

一 緩存系統簡介 EhCache 是一個純 Java 的進程內緩存框架 具有快速 精乾等特點 是 Hibernate 中默認的 CacheProvider EhCache 應用架構圖 下圖是 EhCache 在應用程序中的位置

EhCache 的主要特性有 快速 精幹 簡單 多種緩存策略 緩存數據有兩級 內存和磁碟 因此無需擔心容量問題 緩存數據會在虛擬機重啟的過程中寫入磁碟 可以通過 RMI 可插入 API 等方式進行分布式緩存 具有緩存和緩存管理器的偵聽介面 支持多緩存管理器實例 以及一個實例的多個緩存區域 提供 Hibernate 的緩存實現 由於 EhCache 是進程中的緩存系統 一旦將應用部署在集群環境中 每一個節點維護各自的緩存數據 當某個節點對緩存數據進行更新 這些更新的數據無法在其它節點 *** 享 這不僅會降低節點運行的效率 而且會導致數據不同步的情況發生 例如某個網站採用 A B 兩個節點作為集群部署 當 A 節點的緩存更新後 而 B 節點緩存尚未更新就可能出現用戶在瀏覽頁面的時候 一會是更新後的數據 一會是尚未更新的數據 盡管我們也可以通過 Session Sticky 技術來將用戶鎖定在某個節點上 但對於一些交互性比較強或者是非 Web 方式的系統來說 Session Sticky 顯然不太適合 所以就需要用到 EhCache 的集群解決方案 從 版本開始 Ehcache可以使用分布式的緩存了 EhCache 從 版本開始 支持五種集群方案 分別是 ? Terracotta ? RMI ? JMS ? JGroups ? EhCache Server 其中的三種最為常用集群方式 分別是 RMI JGroups 以及 EhCache Server 本文主要介紹RMI的方式 分布式這個特性是以plugin的方式實現的 Ehcache自帶了一些默認的分布式緩存插件實現 這些插件可以滿足大部分應用的需要 如果需要使用其他的插件那就需要自己開發了 開發者可以通過查看distribution包里的源代碼及JavaDoc來實現它 盡管不是必須的 在使用分布式緩存時理解一些ehcahce的設計思想也是有幫助的 這可以參看分布式緩存設計的頁面 以下的部分將展示如何讓分布式插件同ehcache一起工作 下面列出的是一些分布式緩存中比較重要的方面 ? 你如何知道集群環境中的其他緩存？ ? 分布式傳送的消息是什麼形式？ ? 什麼情況需要進行復制？增加（Puts） 更新（Updates）或是失效（Expiries）？ ? 採用什麼方式進行復制？同步還是非同步方式？ 為了安裝分布式緩存 你需要配置一個PeerProvider 一個CacheManagerPeerListener 它們對於一個CacheManager來說是全局的 每個進行分布式操作的cache都要添加一個cacheEventListener來傳送消息

二 集群緩存概念及其配置 正確的元素類型 只有可序列化的元素可以進行復制 一些操作 比如移除 只需要元素的鍵值而不用整個元素 在這樣的操作中即使元素不是可序列化的但鍵值是可序列化的也可以被復制 成員發現（Peer Discovery） Ehcache進行集群的時候有一個cache組的概念 每個cache都是其他cache的一個peer 沒有主cache的存在 剛才我們問了一個問題 你如何知道集群環境中的其他緩存？這個問題可以命名為成員發現（Peer Discovery） Ehcache提供了兩種機制用來進行成員發現 就像一輛汽車 手動檔和自動檔 要使用一個內置的成員發現機制要在ehcache的配置文件中指定元素的class屬性為 net sf ehcache distribution 自動的成員發現 自動的發現方式用TCP廣播機制來確定和維持一個廣播組 它只需要一個簡單的配置可以自動的在組中添加和移除成員 在集群中也不需要什麼優化伺服器的知識 這是默認推薦的 成員每秒向群組發送一個 心跳 如果一個成員 秒種都沒有發出信號它將被群組移除 如果一個新的成員發送了一個 心跳 它將被添加進群組 任何一個用這個配置安裝了復制功能的cache都將被其他的成員發現並標識為可用狀態 要設置自動的成員發現 需要指定ehcache配置文件中元素的properties屬性 就像下面這樣 peerDiscovery=automatic multicastGroupAddress=multicast address | multicast host name multicastGroupPort=port timeToLive= （timeToLive屬性詳見常見問題部分的描述） 示例 假設你在集群中有兩台伺服器 你希望同步sampleCache 和sampleCache 每台獨立的伺服器都要有這樣的配置 配置server 和server <class= net sf ehcache distribution properties= peerDiscovery=automatic multicastGroupAddress= />multicastGroupPort= timeToLive= 手動進行成員發現 進行手動成員配置要知道每個監聽器的IP地址和埠 成員不能在運行時動態地添加和移除 在技術上很難使用廣播的情況下就可以手動成員發現 例如在集群的伺服器之間有一個不能傳送廣播報文的路由器 你也可以用手動成員發現進行單向的數據復制 只讓server 知道server 而server 不知道server 配置手動成員發現 需要指定ehcache配置文件中的properties屬性 像下面這樣 peerDiscovery=manual rmiUrls=//server:port/cacheName //server:port/cacheName … rmiUrls配置的是伺服器cache peers的列表 注意不要重復配置 示例 假設你在集群中有兩台伺服器 你要同步sampleCache 和sampleCache 下面是每個伺服器需要的配置 配置server <class= net sf ehcache distribution properties= peerDiscovery=manual />rmiUrls=//server : /sampleCache |//server : /sampleCache 配置server <class= net sf ehcache distribution properties= peerDiscovery=manual />rmiUrls=//server : /sampleCache |//server : /sampleCache 配置CacheManagerPeerListener 每個CacheManagerPeerListener監聽從成員們發向當前CacheManager的消息 配置CacheManagerPeerListener需要指定一個 它以插件的機制實現 用來創建CacheManagerPeerListener 的屬性有 class – 一個完整的工廠類名 properties – 只對這個工廠有意義的屬性 使用逗號分隔 Ehcache有一個內置的基於RMI的分布系統 它的監聽器是RMICacheManagerPeerListener 這個監聽器可以用 RMI來配置 <class= net sf ehcache distribution RMI properties= hostName=localhost port= />socketTimeoutMillis= 有效的屬性是 hostname （可選） – 運行監聽器的伺服器名稱 標明了做為集群群組的成員的地址 同時也是你想要控制的從集群中接收消息的介面

在CacheManager初始化的時候會檢查hostname是否可用 如果hostName不可用 CacheManager將拒絕啟動並拋出一個連接被拒絕的異常 如果指定 hostname將使用InetAddress getLocalHost（） getHostAddress（）來得到 警告 不要將localhost配置為本地地址 因為它在網路中不可見將會導致不能從遠程伺服器接收信息從而不能復制 在同一台機器上有多個CacheManager的時候 你應該只用localhost來配置 port – 監聽器監聽的埠 socketTimeoutMillis （可選） – Socket超時的時間 默認是 ms 當你socket同步緩存請求地址比較遠 不是本地區域網 你可能需要把這個時間配置大些 不然很可能延時導致同步緩存失敗 配置CacheReplicators 每個要進行同步的cache都需要設置一個用來向CacheManagerr的成員復制消息的緩存事件監聽器 這個工作要通過為每個cache的配置增加一個cacheEventListenerFactory元素來完成 <! Sample cache named sampleCache ><cache name= sampleCache maxElementsInMemory= eternal= false timeToIdleSeconds= timeToLiveSeconds= overflowToDisk= false ><cacheEventListenerFactory class= net sf ehcache distribution RMICacheReplicatorFactory properties= replicateAsynchronously=true replicatePuts=true replicateUpdates=true replicateUpdatesViaCopy=false replicateRemovals=true /></cache>class – 使用net sf ehcache distribution RMICacheReplicatorFactory 這個工廠支持以下屬性 replicatePuts=true | false – 當一個新元素增加到緩存中的時候是否要復制到其他的peers 默認是true replicateUpdates=true | false – 當一個已經在緩存中存在的元素被覆蓋時是否要進行復制 默認是true replicateRemovals= true | false – 當元素移除的時候是否進行復制 默認是true replicateAsynchronously=true | false – 復制方式是非同步的（指定為true時）還是同步的（指定為false時） 默認是true replicatePutsViaCopy=true | false – 當一個新增元素被拷貝到其他的cache中時是否進行復制指定為true時為復制 默認是true replicateUpdatesViaCopy=true | false – 當一個元素被拷貝到其他的cache中時是否進行復制（指定為true時為復制） 默認是true 你可以使用ehcache的默認行為從而減少配置的工作量 默認的行為是以非同步的方式復制每件事 你可以像下面的例子一樣減少RMICacheReplicatorFactory的屬性配置 <! Sample cache named sampleCache All missing RMICacheReplicatorFactory properties default to true ><cache name= sampleCache maxElementsInMemory= eternal= true overflowToDisk= false memoryStoreEvictionPolicy= LFU ><cacheEventListenerFactory class= net sf ehcache distribution RMICacheReplicatorFactory /></cache> 常見的問題 Windows上的Tomcat 有一個Tomcat或者是JDK的bug 在tomcat啟動時如果tomcat的安裝路徑中有空格的話 在啟動時RMI監聽器會失敗 參見 bin/wa?A =ind &L=rmi users&P= 和 doc/faq howto bugs/l 由於在Windows上安裝Tomcat默認是裝在 Program Files 文件夾里的 所以這個問題經常發生 廣播阻斷 自動的peer discovery與廣播息息相關 廣播可能被路由阻攔 像Xen和VMWare這種虛擬化的技術也可以阻攔廣播 如果這些都打開了 你可能還在要將你的網卡的相關配置打開 一個簡單的辦法可以告訴廣播是否有效 那就是使用ehcache remote debugger來看 心跳 是否可用 廣播傳播的不夠遠或是傳得太遠 你可以通過設置badly misnamed time to live來控制廣播傳播的距離 用廣播IP協議時 timeToLive的值指的是數據包可以傳遞的域或是范圍 約定如下 是限制在同一個伺服器 是限制在同一個子網 是限制在同一個網站 是限制在同一個region 是限制在同一個大洲 是不限制 譯者按 上面這些資料翻譯的不夠准確 請讀者自行尋找原文理解吧 在Java實現中默認值是 也就是在同一個子網中傳播 改變timeToLive屬性可以限制或是擴展傳播的范圍

三 RMI方式緩存集群/配置分布式緩存 RMI 是 Java 的一種遠程方法調用技術 是一種點對點的基於 Java 對象的通訊方式 EhCache 從 版本開始就支持 RMI 方式的緩存集群 在集群環境中 EhCache 所有緩存對象的鍵和值都必須是可序列化的 也就是必須實現 java io Serializable 介面 這點在其它集群方式下也是需要遵守的 下圖是 RMI 集群模式的結構圖

採用 RMI 集群模式時 集群中的每個節點都是對等關系 並不存在主節點或者從節點的概念 因此節點間必須有一個機制能夠互相認識對方 必須知道其它節點的信息 包括主機地址 埠號等 EhCache 提供兩種節點的發現方式 手工配置和自動發現 手工配置方式要求在每個節點中配置其它所有節點的連接信息 一旦集群中的節點發生變化時 需要對緩存進行重新配置 由於 RMI 是 Java 中內置支持的技術 因此使用 RMI 集群模式時 無需引入其它的 Jar 包 EhCache 本身就帶有支持 RMI 集群的功能 使用 RMI 集群模式需要在 ehcache xml 配置文件中定義 節點 分布式同步緩存要讓這邊的cache知道對方的cache 叫做Peer Discovery（成員發現） EHCache實現成員發現的方式有兩種 手動查找 A 在ehcache xml中配置PeerDiscovery成員發現對象 Server 配置 配置本地hostName port是 分別監聽 : 的mobileCache和 : 的mobileCache 注意這里的mobileCache是緩存的名稱 分別對應著server server 的cache的配置 <?xml version= encoding= gbk ?><ehcache xmlns:xsi= instance xsi:noNamespaceSchemaLocation= ehcache xsd > <diskStore path= java io tmpdir /> <! 集群多台伺服器中的緩存 這里是要同步一些伺服器的緩存 server hostName: port: cacheName:mobileCache server hostName: port: cacheName:mobileCache server hostName: port: cacheName:mobileCache 注意 每台要同步緩存的伺服器的RMI通信socket埠都不一樣 在配置的時候注意設置 > <! server 的配置 > < class= net sf ehcache distribution properties= hostName=localhost port= socketTimeoutMillis= peerDiscovery=manual rmiUrls=// : /mobileCache|// : /mobileCache /></ehcache>以上注意元素出現的位置在diskStore下

同樣在你的另外 台伺服器上增加配置 Server 配置本地host port為 分別同步 : 的mobileCache和 : 的mobileCache <! server 的配置 >< class= net sf ehcache distribution properties= hostName=localhost port= socketTimeoutMillis= peerDiscovery=manual rmiUrls=// : /mobileCache|// : /mobileCache />Server 配置本地host port為 分別同步 : 的mobileCache緩存和 : 的mobileCache緩存 <! server 的配置 >< class= net sf ehcache distribution properties= hostName=localhost port= socketTimeoutMillis= peerDiscovery=manual rmiUrls=// : /mobileCache|// : /mobileCache />這樣就在三台不同的伺服器上配置了手動查找cache的PeerProvider成員發現的配置了 值得注意的是你在配置rmiUrls的時候要特別注意url不能重復出現 並且埠 地址都是對的 如果指定 hostname將使用InetAddress getLocalHost（） getHostAddress（）來得到 警告 不要將localhost配置為本地地址 因為它在網路中不可見將會導致不能從遠程伺服器接收信息從而不能復制 在同一台機器上有多個CacheManager的時候 你應該只用localhost來配置 B 下面配置緩存和緩存同步監聽 需要在每台伺服器中的ehcache xml文件中增加cache配置和cacheEventListenerFactory cacheLoaderFactory的配置 <defaultCache maxElementsInMemory= eternal= false timeToIdleSeconds= timeToLiveSeconds= overflowToDisk= false /><! 配置自定義緩存 maxElementsInMemory:緩存中允許創建的最大對象數 eternal:緩存中對象是否為永久的 如果是 超時設置將被忽略 對象從不過期 timeToIdleSeconds:緩存數據空閑的最大時間 也就是說如果有一個緩存有多久沒有被訪問就會被銷毀 如果該值是 就意味著元素可以停頓無窮長的時間 timeToLiveSeconds:緩存數據存活的時間 緩存對象最大的的存活時間 超過這個時間就會被銷毀 這只能在元素不是永久駐留時有效 如果該值是 就意味著元素可以停頓無窮長的時間 overflowToDisk:內存不足時 是否啟用磁碟緩存 memoryStoreEvictionPolicy:緩存滿了之後的淘汰演算法 每一個小時更新一次緩存（ 小時過期） ><cache name= mobileCache maxElementsInMemory= eternal= false overflowToDisk= true timeToIdleSeconds= timeToLiveSeconds= memoryStoreEvictionPolicy= LFU > <! RMI緩存分布同步查找 class使用net sf ehcache distribution RMICacheReplicatorFactory 這個工廠支持以下屬性 replicatePuts=true | false – 當一個新元素增加到緩存中的時候是否要復制到其他的peers 默認是true replicateUpdates=true | false – 當一個已經在緩存中存在的元素被覆蓋時是否要進行復制 默認是true replicateRemovals= true | false – 當元素移除的時候是否進行復制 默認是true replicateAsynchronously=true | false – 復制方式是非同步的 指定為true時 還是同步的 指定為false時 默認是true replicatePutsViaCopy=true | false – 當一個新增元素被拷貝到其他的cache中時是否進行復制 指定為true時為復制 默認是true replicateUpdatesViaCopy=true | false – 當一個元素被拷貝到其他的cache中時是否進行復制 指定為true時為復制 默認是true = > <! 監聽RMI同步緩存對象配置 注冊相應的的緩存監聽類 用於處理緩存事件 如put remove update 和expire > <cacheEventListenerFactory class= net sf ehcache distribution RMICacheReplicatorFactory properties= replicateAsynchronously=true /> replicatePuts=true replicateUpdates=true replicateUpdatesViaCopy=false replicateRemovals=true <! 用於在初始化緩存 以及自動設置 > <bootstrapCacheLoaderFactory class= net sf ehcache bootstrap BootstrapCacheLoaderFactory /></cache> C 這樣就完成了 台伺服器的配置 下面給出server 的完整的ehcache xml的配置 <?xml version= encoding= gbk ?><ehcache xmlns:xsi= instance xsi:noNamespaceSchemaLocation= ehcache xsd > <diskStore path= java io tmpdir /> <!

集群多台伺服器中的緩存 這里是要同步一些伺服器的緩存 server hostName: port: cacheName:mobileCache server hostName: port: cacheName:mobileCache server hostName: port: cacheName:mobileCache 注意每台要同步緩存的伺服器的RMI通信socket埠都不一樣 在配置的時候注意設置 > <! server 的配置 > < class= net sf ehcache distribution properties= hostName=localhost port= socketTimeoutMillis= peerDiscovery=manual rmiUrls=// : /mobileCache|// : /mobileCache /> <defaultCache maxElementsInMemory= eternal= false timeToIdleSeconds= timeToLiveSeconds= overflowToDisk= false /> <! 配置自定義緩存 maxElementsInMemory:緩存中允許創建的最大對象數 eternal:緩存中對象是否為永久的 如果是 超時設置將被忽略 對象從不過期 timeToIdleSeconds:緩存數據空閑的最大時間 也就是說如果有一個緩存有多久沒有被訪問就會被銷毀 如果該值是 就意味著元素可以停頓無窮長的時間 timeToLiveSeconds:緩存數據存活的時間 緩存對象最大的的存活時間 超過這個時間就會被銷毀 這只能在元素不是永久駐留時有效 如果該值是 就意味著元素可以停頓無窮長的時間 overflowToDisk:內存不足時 是否啟用磁碟緩存 memoryStoreEvictionPolicy:緩存滿了之後的淘汰演算法 每一個小時更新一次緩存（ 小時過期） > <cache name= mobileCache maxElementsInMemory= eternal= false overflowToDisk= true timeToIdleSeconds= timeToLiveSeconds= memoryStoreEvictionPolicy= LFU > <! RMI緩存分布同步查找 class使用net sf ehcache distribution RMICacheReplicatorFactory 這個工廠支持以下屬性 replicatePuts=true | false – 當一個新元素增加到緩存中的時候是否要復制到其他的peers 默認是true replicateUpdates=true | false – 當一個已經在緩存中存在的元素被覆蓋時是否要進行復制 默認是true replicateRemovals= true | false – 當元素移除的時候是否進行復制 默認是true replicateAsynchronously=true | false – 復制方式是非同步的 指定為true時 還是同步的 指定為false時 默認是true replicatePutsViaCopy=true | false – 當一個新增元素被拷貝到其他的cache中時是否進行復制 指定為true時為復制 默認是true replicateUpdatesViaCopy=true | false – 當一個元素被拷貝到其他的cache中時是否進行復制 指定為true時為復制 默認是true = > <! 監聽RMI同步緩存對象配置 注冊相應的的緩存監聽類 用於處理緩存事件 如put remove update 和expire > <cacheEventListenerFactory class= net sf ehcache distribution RMICacheReplicatorFactory properties= replicateAsynchronously=true /> replicatePuts=true replicateUpdates=true replicateUpdatesViaCopy=false replicateRemovals=true <! 用於在初始化緩存 以及自動設置 > <bootstrapCacheLoaderFactory class= net sf ehcache bootstrap BootstrapCacheLoaderFactory /> </cache></ehcache> 自動發現 自動發現配置和手動查找的方式有一點不同 其他的地方都基本是一樣的 同樣在ehcache xml中增加配置 配置如下 <! 搜索某個網段上的緩存timeToLive 是限制在同一個伺服器 是限制在同一個子網 是限制在同一個網站 是限制在同一個region 是限制在同一個大洲 是不限制 >< class= net sf ehcache distribution properties= peerDiscovery=automatic multicastGroupAddress= multicastGroupPort= timeToLive= /> lishixin/Article/program/Java/hx/201311/25706

G. 將緩存數據分配到集群的不同節點，分片規則使用什麼演算法

以每24小時作為一份時間（而非自然日），根據用戶的配置有兩種工作模式：帶狀模式中，用戶僅定義開始日期時，從開始日期（含）開始，每份時間1個分片地無限增加下去；環狀模式中，用戶定義了開始日期和結束日期時，以結束日期（含）和開始日期（含）之間的時間份數作為分片總數（分片數量固定），以類似取模的方式路由到這些分片里。

1. DBLE 啟動時，讀取用戶在 rule.xml 配置的 sBeginDate 來確定起始時間
2. 讀取用戶在 rule.xml 配置的 sPartionDay 來確定每個 MySQL 分片承載多少天內的數據
3. 讀取用戶在 rule.xml 配置的 dateFormat 來確定分片索引的日期格式
4. 在 DBLE 的運行過程中，用戶訪問使用這個演算法的表時，WHERE 子句中的分片索引值（字元串），會被提取出來嘗試轉換成 Java 內部的時間類型
5. 然後求分片索引值與起始時間的差，除以 MySQL 分片承載的天數，確定所屬分片

1. DBLE 啟動時，讀取用戶在 rule.xml 配置的起始時間 sBeginDate、終止時間 sEndDate 和每個 MySQL 分片承載多少天數據 sPartionDay
2. 根據用戶設置，建立起以 sBeginDate 開始，每 sPartionDay 天一個分片，直到 sEndDate 為止的一個環，把分片串聯串聯起來
3. 讀取用戶在 rule.xml 配置的 defaultNode
4. 在 DBLE 的運行過程中，用戶訪問使用這個演算法的表時，WHERE 子句中的分片索引值（字元串），會被提取出來嘗試轉換成 Java 內部的日期類型
5. 然後求分片索引值與起始日期的差：如果分片索引值不早於 sBeginDate（哪怕晚於 sEndDate），就以 MySQL 分片承載的天數為模數，對分片索引值求模得到所屬分片；如果分片索引值早於 sBeginDate，就會被放到 defaultNode 分片上

與MyCat的類似分片演算法對比

中間件
DBLE
MyCat

分片演算法種類 date 分區演算法 按日期（天）分片
兩種中間件的取模範圍分片演算法使用上無差別

開發注意點
【分片索引】1. 必須是字元串，而且 java.text.SimpleDateFormat 能基於用戶指定的 dateFormat 來轉換成 java.util.Date
【分片索引】2. 提供帶狀模式和環狀模式兩種模式
【分片索引】3. 帶狀模式以 sBeginDate（含）起，以 86400000 毫秒（24 小時整）為一份，每 sPartionDay 份為一個分片，理論上分片數量可以無限增長，但是出現 sBeginDate 之前的數據而且沒有設定 defaultNode 的話，會路由失敗（如果有 defaultNode，則路由至 defaultNode）
【分片索引】4. 環狀模式以 86400000 毫秒（24 小時整）為一份，每 sPartionDay 份為一個分片，以 sBeginDate（含）到 sEndDate（含）的時間長度除以單個分片長度得到恆定的分片數量，但是出現 sBeginDate 之前的數據而且沒有設定 defaultNode 的話，會路由失敗（如果有 defaultNode，則路由至 defaultNode）
【分片索引】5. 無論哪種模式，分片索引欄位的格式化字元串 dateFormat 由用戶指定
【分片索引】6. 無論哪種模式，劃分不是以日歷時間為准，無法對應自然月和自然年，且會受閏秒問題影響

運維注意點
【擴容】1. 帶狀模式中，隨著 sBeginDate 之後的數據出現，分片數量的增加無需再平衡
【擴容】2. 帶狀模式沒有自動增添分片的能力，需要運維手工提前增加分片；如果路由策略計算出的分片並不存在時，會導致失敗
【擴容】3. 環狀模式中，如果新舊 [sBeginDate,sEndDate] 之間有重疊，需要進行部分數據遷移；如果新舊 [sBeginDate,sEndDate] 之間沒有重疊，需要數據再平衡

配置注意點
【配置項】1. 在 rule.xml 中，可配置項為 <propertyname="sBeginDate"> 、 <propertyname="sPartionDay"> 、 <propertyname="dateFormat"> 、 <propertyname="sEndDate"> 和 <propertyname="defaultNode">
【配置項】2.在 rule.xml 中配置 <propertyname="dateFormat">，符合 java.text.SimpleDateFormat 規范的字元串，用於告知 DBLE 如何解析sBeginDate和sEndDate

【配置項】3.在 rule.xml 中配置 <propertyname="sBeginDate">，必須是符合 dateFormat 的日期字元串

【配置項】4.在 rule.xml 中配置 <propertyname="sEndDate">，必須是符合 dateFormat 的日期字元串；配置了該項使用的是環狀模式，若沒有配置該項則使用的是帶狀模式

【配置項】5.在 rule.xml 中配置 <propertyname="sPartionDay">，非負整數，該分片策略以 86400000 毫秒（24 小時整）作為一份，而 sPartionDay 告訴 DBLE 把每多少份放在同一個分片

【配置項】6.在 rule.xml 中配置 <propertyname="defaultNode"> 標簽，非必須配置項，不配置該項的話，用戶的分片索引值沒落在 mapFile 定義

H. 瀏覽器緩存機制簡單概括和分析

對於訪問的頁面和請求，為了縮短網頁請求資源的距離，減少延遲，並且由於緩存文件可以重復利用，還可以減少帶寬，降低網路負荷，瀏覽器和伺服器都有可能會對請求資源進行緩存，接下來的文章就簡單介紹和分析瀏覽器的緩存機制。

深入理解瀏覽器的緩存機制：  https://www.jianshu.com/p/54cc04190252

這篇文章已經有詳細的講解，這里就概括一下：

以首頁的請求為例：

1、強制緩存策略(Expires和Cache-Control) ：當瀏覽器發起http請求的時候，如果配置了緩存策略且緩存在有效期內，會直接使用瀏覽器緩存。 不使用強制緩存 （ Cache-Control=no-chache， 或者 max-age=0  ）

    （1）、圖中請求伺服器：是 max-age=0 的情況，瀏覽器直接請求伺服器資源，而不是用本地緩存

    （2）、圖中磁碟緩存和內存緩存：就是瀏覽器使用了本地緩存而不再請求伺服器資源

2、協商緩存策略（Last-Modified和If-Modified-Since， ETag和If-None-Match）： 當瀏覽器發起http請求的時候，如果 強制緩存策略 失效，或者者禁用了強制緩存，這時候會根據 If-Modified-Since 中的值與伺服器中這個資源的最後修改時間對比，如果沒有變化，返回304和空的響應體，直接從緩存讀取，如果If-Modified-Since的時間小於伺服器中這個資源的最後修改時間，說明文件有更新，於是返回新的資源文件和200。

不使用協商緩存 （ Cache-Control=no-store ），這個參數同時也會 禁用強制緩存。

    （1）、伺服器資源返回無更新，瀏覽器使用上次請求的資源

（2）、伺服器資源有更新，返回200並返回最新的資源

3、不使用緩存策略（Cache-Control=no-store）： 所有內容都不會被緩存，即不使用強制緩存，也不使用協商緩存。當response head 設置了no-store，瀏覽器不會對返回的資源做緩存，每次請求都是直接請求伺服器。這可以保證瀏覽器每次都能拿最新的資源，即使資源對比上次請求沒有任何更新，但同時也降低了頁面的響應速度，和增加了網路的IO與伺服器的壓力。

可以明顯的看到請求時間，請求伺服器資源時間 >> 請求磁碟緩存 > 請求內存緩存，所以合適的緩存策略，可以在不影響業務的情況下，極大地提升客戶體驗和後台伺服器壓力。