Ehcache 分散式快取 -springMVC
開發環境:
System:Windows
JavaEE Server:tomcat5.0.2.8、tomcat6
JavaSDK: jdk6+
IDE:eclipse、MyEclipse 6.6
開發依賴庫:
JDK6、 JavaEE5、ehcache-core-2.5.2.jar
Email:[email protected]
一、快取系統簡介
EhCache 是一個純 Java 的程序內快取框架,具有快速、精幹等特點,是 Hibernate 中預設的 CacheProvider。
EhCache 應用
EhCache 的主要特性有:
1. 快速、精幹;
2. 簡單;
3. 多種快取策略;
4. 快取資料有兩級:記憶體和磁碟,因此無需擔心容量問題;
5. 快取資料會在虛擬機器重啟的過程中寫入磁碟;
6. 可以通過 RMI、可插入 API 等方式進行分散式快取;
7. 具有快取和快取管理器的偵聽介面;
8. 支援多快取管理器例項,以及一個例項的多個快取區域;
9. 提供 Hibernate 的快取實現;
由於 EhCache 是程序中的快取系統,一旦將應用部署在叢集環境中,每一個節點維護各自的快取資料,當某個節點對快取資料進行更新,這些更新的資料無法在其它節點中共享,這不僅會降低節點執行的效率,而且會導致資料不同步的情況發生。例如某個網站採用 A、B 兩個節點作為叢集部署,當 A 節點的快取更新後,而 B 節點快取尚未更新就可能出現使用者在瀏覽頁面的時候,一會是更新後的資料,一會是尚未更新的資料,儘管我們也可以通過 Session Sticky 技術來將使用者鎖定在某個節點上,但對於一些互動性比較強或者是非 Web 方式的系統來說,Session Sticky 顯然不太適合。
所以就需要用到 EhCache 的叢集解決方案。
從1.2版本開始,Ehcache可以使用分散式的快取了。EhCache 從 1.7 版本開始,支援五種叢集方案,分別是:
• 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的配置檔案中指定cacheManagerPeerProviderFactory元素的class屬性為
net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory。
自動的成員發現
自動的發現方式用TCP廣播機制來確定和維持一個廣播組。它只需要一個簡單的配置可以自動的在組中新增和移除成員。在叢集中也不需要什麼優化伺服器的知識,這是預設推薦的。
成員每秒向群組傳送一個“心跳”。如果一個成員 5秒種都沒有發出訊號它將被群組移除。如果一個新的成員傳送了一個“心跳”它將被新增進群組。
任何一個用這個配置安裝了複製功能的cache都將被其他的成員發現並標識為可用狀態。
要設定自動的成員發現,需要指定ehcache配置檔案中cacheManagerPeerProviderFactory元素的properties屬性,就像下面這樣:
peerDiscovery=automaticmulticastGroupAddress=multicast address | multicast host name
multicastGroupPort=port
timeToLive=0-255 (timeToLive屬性詳見常見問題部分的描述)
示例
假設你在叢集中有兩臺伺服器。你希望同步sampleCache1和sampleCache2。每臺獨立的伺服器都要有這樣的配置:
配置server1和server2<cacheManagerPeerProviderFactoryclass="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"properties="peerDiscovery=automatic, multicastGroupAddress=230.0.0.1,multicastGroupPort=4446, timeToLive=32"/>
手動進行成員發現
進行手動成員配置要知道每個監聽器的IP地址和埠。成員不能在執行時動態地新增和移除。在技術上很難使用廣播的情況下就可以手動成員發現,例如在叢集的伺服器之間有一個不能傳送廣播報文的路由器。你也可以用手動成員發現進行單向的資料複製,只讓server2知道server1,而server1不知道server2。
配置手動成員發現,需要指定ehcache配置檔案中cacheManagerPeerProviderFactory的properties屬性,像下面這樣:
peerDiscovery=manual rmiUrls=//server:port/cacheName, //server:port/cacheName ...
rmiUrls配置的是伺服器cache peers的列表。注意不要重複配置。
示例
假設你在叢集中有兩臺伺服器。你要同步sampleCache1和sampleCache2。下面是每個伺服器需要的配置:
配置server1<cacheManagerPeerProviderFactoryclass="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"properties="peerDiscovery=manual,rmiUrls=//server2:40001/sampleCache11|//server2:40001/sampleCache12"/>
配置server2
<cacheManagerPeerProviderFactoryclass="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"properties="peerDiscovery=manual,rmiUrls=//server1:40001/sampleCache11|//server1:40001/sampleCache12"/>
配置CacheManagerPeerListener
每個CacheManagerPeerListener監聽從成員們發向當前CacheManager的訊息。配置CacheManagerPeerListener需要指定一個CacheManagerPeerListenerFactory,它以外掛的機制實現,用來建立CacheManagerPeerListener。
cacheManagerPeerListenerFactory的屬性有:
class – 一個完整的工廠類名。
properties – 只對這個工廠有意義的屬性,使用逗號分隔。Ehcache有一個內建的基於RMI的分佈系統。它的監聽器是RMICacheManagerPeerListener,這個監聽器可以用
RMICacheManagerPeerListenerFactory來配置。
<cacheManagerPeerListenerFactoryclass="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory"properties="hostName=localhost, port=40001,socketTimeoutMillis=2000"/>
有效的屬性是:
hostname (可選) – 執行監聽器的伺服器名稱。標明瞭做為叢集群組的成員的地址,同時也是你想要控制的從叢集中接收訊息的介面。在CacheManager初始化的時候會檢查hostname是否可用。
如果hostName不可用,CacheManager將拒絕啟動並丟擲一個連線被拒絕的異常。
如果指定,hostname將使用InetAddress.getLocalHost().getHostAddress()來得到。
警告:不要將localhost配置為本地地址127.0.0.1,因為它在網路中不可見將會導致不能從遠端伺服器接收資訊從而不能複製。在同一臺機器上有多個CacheManager的時候,你應該只用localhost來配置。
port – 監聽器監聽的埠。
socketTimeoutMillis (可選) – Socket超時的時間。預設是2000ms。當你socket同步快取請求地址比較遠,不是本地區域網。你可能需要把這個時間配置大些,不然很可能延時導致同步快取失敗。
配置CacheReplicators
每個要進行同步的cache都需要設定一個用來向CacheManagerr的成員複製訊息的快取事件監聽器。這個工作要通過為每個cache的配置增加一個cacheEventListenerFactory元素來完成。
<!-- Sample cache named sampleCache2. -->
<cache name="sampleCache2"maxElementsInMemory="10"eternal="false"timeToIdleSeconds="100"timeToLiveSeconds="100"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 sampleCache4. All missing RMICacheReplicatorFactory properties default to true -->
<cache name="sampleCache4"maxElementsInMemory="10"eternal="true"overflowToDisk="false"memoryStoreEvictionPolicy="LFU"><cacheEventListenerFactory class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"/></cache>
常見的問題
Windows上的Tomcat
有一個Tomcat或者是JDK的bug,在tomcat啟動時如果tomcat的安裝路徑中有空格的話,在啟動時RMI監聽器會失敗。參見http://archives.java.sun.com/cgi-bin/wa?A2=ind0205&L=rmi-users&P=797和http://www.ontotext.com/kim/doc/sys-doc/faq-howto-bugs/known-bugs.html。
由於在Windows上安裝Tomcat預設是裝在“Program Files”資料夾裡的,所以這個問題經常發生。
廣播阻斷
自動的peer discovery與廣播息息相關。廣播可能被路由阻攔,像Xen和VMWare這種虛擬化的技術也可以阻攔廣播。如果這些都打開了,你可能還在要將你的網絡卡的相關配置開啟。一個簡單的辦法可以告訴廣播是否有效,
那就是使用ehcache remote debugger來看“心跳”是否可用。
廣播傳播的不夠遠或是傳得太遠
你可以通過設定badly misnamed time to live來控制廣播傳播的距離。用廣播IP協議時,timeToLive的值指的是資料包可以傳遞的域或是範圍。約定如下:
0是限制在同一個伺服器
1是限制在同一個子網
32是限制在同一個網站
64是限制在同一個region
128是限制在同一個大洲
255是不限制
譯者按:上面這些資料翻譯的不夠準確,請讀者自行尋找原文理解吧。
在Java實現中預設值是1,也就是在同一個子網中傳播。改變timeToLive屬性可以限制或是擴充套件傳播的範圍。
三、 RMI方式快取叢集/配置分散式快取
RMI 是 Java 的一種遠端方法呼叫技術,是一種點對點的基於 Java 物件的通訊方式。EhCache 從 1.2 版本開始就支援 RMI 方式的快取叢集。在叢集環境中 EhCache 所有快取物件的鍵和值都必須是可序列化的,也就是必須實現 java.io.Serializable 介面,這點在其它叢集方式下也是需要遵守的。
下圖是 RMI 叢集模式的結構圖:
採用 RMI 叢集模式時,叢集中的每個節點都是對等關係,並不存在主節點或者從節點的概念,因此節點間必須有一個機制能夠互相認識對方,必須知道其它節點的資訊,包括主機地址、埠號等。EhCache 提供兩種節點的發現方式:手工配置和自動發現。手工配置方式要求在每個節點中配置其它所有節點的連線資訊,一旦叢集中的節點發生變化時,需要對快取進行重新配置。
由於 RMI 是 Java 中內建支援的技術,因此使用 RMI 叢集模式時,無需引入其它的 Jar 包,EhCache 本身就帶有支援 RMI 叢集的功能。使用 RMI 叢集模式需要在 ehcache.xml 配置檔案中定義 cacheManagerPeerProviderFactory 節點。
分散式同步快取要讓這邊的cache知道對方的cache,叫做Peer Discovery(成員發現) EHCache實現成員發現的方式有兩種:
1、手動查詢
A、 在ehcache.xml中配置PeerDiscovery成員發現物件
Server1配置,配置本地hostName、port是400001,分別監聽192.168.8.32:400002的mobileCache和192.168.5.231:400003 的mobileCache。注意這裡的mobileCache是快取的名稱,分別對應著server2、server3的cache的配置。
<?xml version="1.0" encoding="gbk"?><ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ehcache.xsd"><diskStore path="java.io.tmpdir"/><!--
叢集多臺伺服器中的快取,這裡是要同步一些伺服器的快取
server1 hostName:192.168.8.9 port:400001 cacheName:mobileCache
server2 hostName:192.168.8.32 port:400002 cacheName:mobileCache
server3 hostName:192.168.8.231 port:400003 cacheName:mobileCache
注意:每臺要同步快取的伺服器的RMI通訊socket埠都不一樣,在配置的時候注意設定
-->
<!-- server1 的cacheManagerPeerProviderFactory配置 -->
<cacheManagerPeerProviderFactoryclass="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"properties="hostName=localhost,port=400001,socketTimeoutMillis=2000,peerDiscovery=manual,rmiUrls=//192.168.8.32:400002/mobileCache|//192.168.5.231:400003/mobileCache"/>
</ehcache>以上注意cacheManagerPeerProviderFactory元素出現的位置在diskStore下
同樣在你的另外2臺伺服器上增加配置
Server2,配置本地host,port為400002,分別同步192.168.8.9:400001的mobileCache和192.168.5.231:400003的mobileCache
<!-- server2 的cacheManagerPeerProviderFactory配置 -->
<cacheManagerPeerProviderFactoryclass="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"properties="hostName=localhost,port=400002,socketTimeoutMillis=2000,peerDiscovery=manual,rmiUrls=//192.168.8.9:400001/mobileCache|//192.168.5.231:400003/mobileCache"/>
Server3,配置本地host,port為400003,分別同步192.168.8.9:400001的mobileCache快取和192.168.8.32:400002的mobileCache快取
<!-- server3 的cacheManagerPeerProviderFactory配置 -->
<cacheManagerPeerProviderFactoryclass="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"properties="hostName=localhost,port=400003,socketTimeoutMillis=2000,peerDiscovery=manual,rmiUrls=//192.168.8.9:400001/mobileCache|//192.168.8.32:400002/mobileCache"/>
這樣就在三臺不同的伺服器上配置了手動查詢cache的PeerProvider成員發現的配置了。 值得注意的是你在配置rmiUrls的時候要特別注意url不能重複出現,並且埠、地址都是對的。
如果指定,hostname將使用InetAddress.getLocalHost().getHostAddress()來得到。
警告:不要將localhost配置為本地地址127.0.0.1,因為它在網路中不可見將會導致不能從遠端伺服器接收資訊從而不能複製。在同一臺機器上有多個CacheManager的時候,你應該只用localhost來配置。
B、 下面配置快取和快取同步監聽,需要在每臺伺服器中的ehcache.xml檔案中增加cache配置和cacheEventListenerFactory、cacheLoaderFactory的配置
<defaultCache maxElementsInMemory="10000" eternal="false" timeToIdleSeconds="30" timeToLiveSeconds="30" overflowToDisk="false"/><!--
配置自定義快取
maxElementsInMemory:快取中允許建立的最大物件數
eternal:快取中物件是否為永久的,如果是,超時設定將被忽略,物件從不過期。
timeToIdleSeconds:快取資料空閒的最大時間,也就是說如果有一個快取有多久沒有被訪問就會被銷燬,如果該值是 0 就意味著元素可以停頓無窮長的時間。
timeToLiveSeconds:快取資料存活的時間,快取物件最大的的存活時間,超過這個時間就會被銷燬,這隻能在元素不是永久駐留時有效,如果該值是0就意味著元素可以停頓無窮長的時間。
overflowToDisk:記憶體不足時,是否啟用磁碟快取。
memoryStoreEvictionPolicy:快取滿了之後的淘汰演算法。
每一個小時更新一次快取(1小時過期)
-->
<cache name="mobileCache"maxElementsInMemory="10000"eternal="false"overflowToDisk="true"timeToIdleSeconds="1800"timeToLiveSeconds="3600"memoryStoreEvictionPolicy="LFU"><!--
RMI快取分佈同步查詢 class使用net.sf.ehcache.distribution.RMICacheReplicatorFactory
這個工廠支援以下屬性:
replicatePuts=true | false – 當一個新元素增加到快取中的時候是否要複製到其他的peers。預設是true。
replicateUpdates=true | false – 當一個已經在快取中存在的元素被覆蓋時是否要進行復制。預設是true。
replicateRemovals= true | false – 當元素移除的時候是否進行復制。預設是true。
相關推薦
Ehcache 分散式快取 -springMVC
開發環境: System:Windows JavaEE Server:tomcat5.0.2.8、tomcat6 JavaSDK: jdk6+ IDE:eclipse、MyEclipse 6.6 開發依賴庫: JDK6、 JavaEE5、ehcache-core
EhCache 分散式快取物件的同步
為了提升目前開發產品的效能,專案組內考慮將一些常用的資料放入快取,並且今後要將系統分散式部署,以達到負載均衡的目的,因此快取同步問題就不得不需要考慮,該專案中主要用EhCache產品,EhCache的優勢和劣勢這裡就不做介紹,網上可以搜尋,單從這次專案出發,說說他在專案中的應用,Hibernate和Spri
java ehcache 分散式快取配置例項
下面我們動手通過專案來實踐下吧.[RMI方式]; 基本環境:A 分別建立兩個web專案,C1和C2 分別倒入echcache的jar包; B 本例使用了兩個tomcat 分別部署C1和C2 專案配置:C1配置 A e
Ehcache 分散式快取
自從Ehcache 到了1.2+的版本,就支援分散式快取了。我們考慮到Spring + Hibernate的結構 ,ehcache的對這幾個框架的支援較好,就一直採用這個快取方案。 地址:http://ehcache.sourceforge.net/ 先介紹沒有分散式快取需
mybatis整合ehcache分散式快取框架
mybatis提供了一個cache介面,如果要實現自己的快取邏輯,實現cache介面開發即可。 mybatis和ehcache整合,mybatis和ehcache整合包中提供了一個cache介面的實現類。 1.4.3 第一步加入ehcache包 1.4
《深入分散式快取 》第4章Ehcache 與guava cache
一 序 本文屬於《深入分散式快取 》讀書筆記,第一章:快取為王主要介紹快取概念,以及引入快取的背景:提升使用者體驗。還介紹了快取的分類,第二章主要介紹分散式理論。個人覺得第二章可以去掉,畢竟是泛泛的介紹。還是專門去看有主題的書比較好,比如《<從PAXOS
mybatis中二級快取整合ehcache實現分散式快取
mybatis自帶二級快取,但是這個快取是單伺服器工作,無法實現分散式快取。那麼什麼是分散式快取呢?假設現在有兩個伺服器1和2,使用者訪問的時候訪問了1伺服器,查詢後的快取就會放在1伺服器上,假設現在有個使用者訪問的是2伺服器,那麼他在2伺服器上就無法獲取剛剛那個快取
SpringMVC中EhCache實現快取資料
EhCache 是一個純Java的程序內快取框架,具有快速、精幹等特點,是Hibernate中預設CacheProvider。Ehcache是一種廣泛使用的開源Java分散式快取。主要面向通用快取,Java EE和輕量級容器。它具有記憶體和磁碟儲存,快取載入器,
memcached分散式快取和hibernate結合-- Hibernate+ehcache二級快取技術
Memcached是由Danga Interactive開發的,高效能的,分散式的記憶體物件快取系統,用於在動態應用中減少資料庫負載,提升訪問速度。Memcached 的快取是一種分散式的,可以讓不同主機上的多個使用者同時訪問, 因此解決了共享記憶體只能單機應用的侷限,更
Hibernate中使用分散式快取ehcache-core-1.3.0
前言 廢話不多說,來這看的,不管你是會ehcache或者從來沒接觸過的,保證看過之後,都能構建一個自己的ehcache專案。因為我在寫這篇部落格的時候,是一邊在配置一邊在記錄過程中遇到的問題,等於是在手把手教學。下面直入正題。 一、下載相關jar包 網上下載ehcache-
ehcache作為分散式快取的研究
ehcache支援兩種拓撲結構,一種是Distributed Caching,另一種是Replicated CachingDistributed Caching這和一般意義上的分散式快取非常類似,這一型別的快取是有client-server之分的,application通過c
springMVC整合ehcache,快取失敗
這兩天在用springMVC整合ehcache,把所有的東西都配置完成之後,發現@Cacheable這個放在Service上的註解根本就不好使,於是乎,用junit測試Dao發現放在Dao上的@Cacheable是好使的,也沒再測試Service因為肯定也是好用的。這樣肯定
【開源專案系列】如何基於 Spring Cache 實現多級快取(同時整合本地快取 Ehcache 和分散式快取 Redis)
## 一、快取 當系統的併發量上來了,如果我們頻繁地去訪問資料庫,那麼會使資料庫的壓力不斷增大,在高峰時甚至可以出現數據庫崩潰的現象。所以一般我們會使用快取來解決這個資料庫併發訪問問題,使用者訪問進來,會先從快取裡查詢,如果存在則返回,如果不存在再從資料庫裡查詢,最後新增到快取裡,然後返回給使用者,當然了,接
redis→分散式快取
簡介 1. redis 是什麼? REmote DIctionary Server(遠端字典伺服器) 是完全開源免費的,用 C 語言編寫的,遵守 BSD 協議,是一個高效能的 (key/value)分散式記憶體資料庫,基於記憶體執行並支援
大資料(十三):MapJoin(DistributedCache分散式快取)、資料清理例項與計數器應用
一、在map端表合併(DistributedCache分散式快取) 1.適用場景 適合用於關聯表中有小表的情形。 可以將小表分發到所有的
分散式快取架構設計
零、 題記在高併發場景下,需要通過快取來減少資料庫的壓力,使得大量的訪問進來能夠命中快取,只有少量的需要到資料庫層。由於快取基於記憶體,可支援的併發量遠遠大於基於硬碟的資料庫。所以對於高併發設計,快取的設計是必不可少的一環。一、為什麼要使用快取為什麼要使用快取呢?源於人類的一個夢想,就是多快好省的建設社會
分散式快取:Memcached, Redis, MongoDB區別
分散式快取學習之一:Memcached, Redis, MongoDB區別 Redis是一個開源(BSD許可),記憶體儲存的資料結構伺服器,可用作資料庫,快取記憶體和訊息佇列代理。 Memcached是一個自由開源的,高效能,分散式記憶體物件快取系統。 MongoDB是一個基
mybatis整合分散式快取框架
什麼是分散式快取 為了提高系統的併發效能,通常會對系統進行分散式部署(如叢集部署方式) 如上圖,伺服器1上的mybatis的二級快取位於伺服器1上,伺服器2上的mybatis的二級快取位於伺服器2上。 所以如果不使用分散式快取,快取的資料就會在各個伺服器上單獨儲存,因此,需
mybatis 整合ehcache實現快取
mybatis 整合ehcache實現快取 mybatis 一級快取和二級快取的區別: 1、一級快取:基於PerpetualCache的HashMap本地快取,其儲存作用域為同一個SqlSession,當Session flush或close之後,該
Flink分散式快取Distributed Cache應用案例實戰-Flink牛刀小試
版權宣告:本套技術專欄是作者(秦凱新)平時工作的總結和昇華,通過從真實商業環境抽取案例進行總結和分享,並給出商業應用的調優建議和叢集環境容量規劃等內容,請持續關注本套部落格。版權宣告:禁止轉載,歡迎學習。QQ郵箱地址:[email protected],如有任何問題,可隨時聯絡。 1 分散式快取