摘要:Oracle Coherence是一個企業級的分佈式集羣緩存框架。具備自管理,自恢復,高可用性,高擴展性等優良特色,在電信BOSS等項目中有很大的應用價值。本文對它的特色,架構,基本使用方法,JMX管理,調優等進行簡要但快捷的介紹,並對於Hibernate的集成過程進行說明,爲BOSS,CMP等移動項目提供一個的參考。
關鍵詞:分佈式緩存 Coherence
網上除了官方用戶指南,關於Coherence的介紹文章資料不多,所以總結出此文,從原理到快速指南和基本最佳實踐,但願對須要的人提供一個參考。
1 Coherence 概述
1.1 Coherence是什麼
Oracle官方網站的描述是:Coherence 在可靠的、高度可伸縮的對等集羣協議之上提供了複製的、分佈式的(分區的)數據管理和緩存服務。Coherence 不存在單點故障,當某臺服務器沒法操做或從網絡斷開時,它能夠自動且透明地進行故障切換並從新分佈它的集羣化數據管理服務。當新服務器加入或故障服務器重 啓時,它會自動加入集羣,Coherence 會將服務切回到該服務器,透明地從新分佈集羣負載。Coherence 包含網絡級的容錯特性和透明的軟重啓功能,以支持服務器自我修復。
----來自Oracle Coherence 專區
http://www.oracle.com/technology/global/cn/products/coherence/index.html
一個典型的Hibernate應用 + Coherence集羣以下圖所示:
1.2 Coherence的特色
1.2.1 分佈式集羣緩存
Coherence是一個分佈式的緩存方案,而且經過集羣爲應用提供強大的緩存後備支持。Coherence主要是內存緩存,即存儲區域主要在內存當中。
與通常的分佈式緩存方案如JBossCache, Memcache 等相同,分佈式緩存的價值基於網絡IO性能高於DB查詢的磁盤IO性能這樣一個特色。
Coherence全部的設計都是基於多個(能夠是很是多)的JVM,不少Coherence的測試都是使用幾十甚至上百個節點來進行的。
下圖展現了一個典型的WAS項目架構:WAS集羣 + Near型Coherence集羣架構。對於大型Web2.0網站(PHP或其餘),集成Coherence也是相似的。
1.2.2自管理
Coherence使用的網絡協議是TCMP ,是對UDP,TCP/IP的組合使用。Coherence能將啓動的實例節點(Node)自動組成爲集羣(Cluster)。在一個局域網環境中,經過多播(Multicast)機制,第1個啓動的Node能自動發現後啓動的Node,第1,2個Node一樣能發現以後啓動的其餘Node,依次類推,自動組成集羣; 而且也能自動檢測到死亡節點。集羣各節點間經過單播(Unicast)機制進行數據複製,同步及發送通知消息。
Coherence集羣以統一的邏輯試圖對外提供緩存的讀寫接口,看起來使用Coherence Client就像在使用一個緩存同樣。
1.2.3 自動容錯和恢復
基於自管理的特色,一個Node掛掉後,集羣能自動監測到,並作好死亡節點的數據恢復機制,客戶端依然能正確的讀出在死亡節點上存儲的數據,容錯和恢復對客戶端來講是透明的。
1.2.4 分區緩存(Partitioned Cache)
這是Coherence不同凡響的地方。通常集羣如:JBossCache, Websphere 集羣等,每一個Node都有數據的完整拷貝,Node間經過複製來實現數據同步和一致性,通常來講採用全複製模式,即一份數據在各節點上都有一份拷貝。這種模式下,節點要存儲了較多的數據,同步複製時比較消耗網絡帶寬。
而Coherence的分區緩存只將一個Node上的數據在另外一節點上作1個備份,有效下降複製的消耗好時間,並節省內存總需求,只需複製模式的1/N (N爲緩存節點個數)。
1.2.5 線性擴展
假如你的Coherence集羣已經有4個Node,當系統數據量過大引發Cache容量滿員,致使緩存性能降低時,能夠經過啓動新的Node來擴容,改善集羣的性能。
這一點也是源自分區緩存技術,集羣有N個Node,每一個Node只存放1/N的數據,這種設計讓Coherence可以處理很是多的數據,只須要經過增長節點的數量,就能夠處理更多的數據。
下圖爲例,當兩臺機器,4個存儲Node不夠用時,經過新增機器,新增Node實例便可自動加入集羣,提高Coherence緩存性能。
線性擴展更重要體如今性能上,下圖展現了,Coherence集羣經過增長機器,增長Node實例使得交易耗時大幅下降,並且隨着集羣規模呈線性降低。
1.2.6易用性
雖然上述特色看起來彷佛很複雜,但那都是Coherence本身內部的事兒。對於客戶端來講,與最簡單的Map 操做同樣,僅僅是 put(key,value), get(key) 等。 html
正是基於以上技術和特色,Coherence成爲一個高可用性,高擴展性,高性能但使用很是簡單的網格型(Data Grid)分佈式緩存框架。 前端
Coherence企業級緩存(二) QuickStart和編程 java
2. Quick start
2.1 安裝
Coherence是純Java的框架,不須要額外的安裝。首先在Oracle網站上下載開發包,最新爲3.4版,只有13M,能夠說是很小很強大。
SDK解壓便可,包含 bin, doc, example, lib 四個目錄。Doc下包含了完整的user-guide,只是有點長,有350多頁。
2.2 運行
Coherence集羣是由Node構成的,每一個Node既存儲數據,又能夠查詢數據。
運行 bin/coherence.cmd 命令就能啓動一個Node實例。
運行屢次,就能啓動多個實例,各Node能自動檢測到網路內新啓動的Node,並加入集羣。
第一個節點啓動信息大體爲: 程序員
第二個節點啓動信息大體爲: web
最後會出現命令行提示符,經過Coherence控制檯命令就能夠執行Cache的基本操做。 算法
最經常使用命令有:
建立或切換到一個cache: sql
Put一個數據: 數據庫
Get一個數據: 編程
查看有哪些cache: 後端
查看一個cache下的全部key:
你沒必要關心數據存在哪裏,能夠在Node1上 put一個數據,在Node2上get出來。
默認啓動Node使用的是 Coherence.jar中的緩存配置文件 coherence-cache-config.xml ,使用的是DistributedCache 分區緩存。
3. 編程
正如第一節所說,使用Coherence進行數據管理的應用程序中的API調用很是簡單,不管集羣有多少個物理機器,多少個節點實例,客戶端只邏輯上面對集羣。
記得在你的應用中(例如:BOSS,CRM等)中包含 coherence.jar, tangosol.jar 等必要的類庫文件。
Coherence企業級緩存(三) 四種緩存類型
4. 基本緩存類型及適用狀況
Coherence 支持四種Cache類型(Cache Type),也可看做四種緩存系統架構:
4.1 複製緩存(Replicated Cache)
數據在集羣成員中進行全複製,每一個節點都有一個完整的數據拷貝。這種集羣下,read性能最高( cache.get(key) 操做),容錯性好,但cache.put(key,value) 操做性能較低。若是Node不少,每次put操做都要在全部成員上執行一次。
cache.get(key)
cache.put(key,value)
這是一種傳統的集羣技術,不是Coherence的亮點。
4.1 樂觀緩存 (Optimistic Cache)
它相似於複製緩存,但不提供併發控制(Concurrency Control)。這種集羣數據吞吐量最高,各節點容易出現數據不一致的狀況。
4.1 分區緩存 (Distributed (Partitioned) Cache)
Coherence 的亮點。默認狀況下,一份數據A只在兩個節點上有拷貝,第二份做爲備份數據(Backup),用於容錯。
從總體上看,假設應用須要的Cache總內存爲 M,該模式將數據分散到N個節點上,每一個JVM只佔用 M/N 的內存消耗,與複製緩存每節點消耗 M量的內存造成對比,它能夠極大節省內存資源。
cache.get(key)
cache.put(key,value)
4.1 Near緩存 (NearCache)
分區緩存的改進版。分區緩存將數據所有存到Cache Node上,而Near緩存將緩存數據中使用頻率最高的數據(熱點數據Hotspot)放到應用的本地緩存(Local Cache)區域。因爲本地內存訪問的高效性,它能夠有效提高分區緩存的read性能。
四種緩存類型的基本特色對好比下表所示:
幾個重要因素:
JVM數量(N): 即啓動的Node數量,每一個節點爲一個JVM進程;
數據大小(M):要緩存的數據總量的佔用空間大小,如10M,120M等;
冗餘度(R) :緩存的secondary備份個數。分區緩存默認爲1,能夠配置2,3,…
本地緩存大小(L):(僅對Near緩存而言)應用所在的本地緩存的空間大小字節數。
幾種類型的對比
Coherence企業級緩存(四) 數據管理模式
Coherence提供了四種Cache數據管理模式:
Read-Through,
Write-Through,
Refresh-Ahead
Write-Behind
數據管理模式體如今CacheStore 接口的功能上。
CacheStore負責直接和數據源交互,進行增刪改查操做;並也負責和Coherence Cache交互,向其中寫數據(put),讀數據(get)和刪除數據(remove)。CacheStore至關於 數據源和Cache間的橋樑。
對於不一樣的應用,因爲數據源不一樣,如:DB,WebService ,FileSystem等, CacheStore有不一樣的實現。它通常做爲應用的一部分。Coherence也爲 Hibernate,Toplink等實現了一個CacheStore。
5.1 Read-Through
Read-Through 的基本特色是同步讀取。步驟爲:
1)應用調用 CacheStore 查詢數據X;
2)CacheStore 去Cache中查詢,未發現數據時,向數據庫執行查詢操做,並將查詢結果放到 Cache中, 並將結果返回給應用;
3)若是發現Cache中有數據,則直接從Cache讀取,並返回給應用。
其特色體如今第二步,CacheStore調用 cache.get(X) 到 CacheStore 給應用返回數據,是同步操做。 也就是要在一個同步過程當中先等待數據查詢,Cache被填充,才能得到數據。 這種模式的性能比較低,不及 Refresh-Ahead。
5.2 Write-Through
Write-Through 對應於數據修改操做,如 update,也具備同步的特色。
1)應用調用 CacheStore update數據X;
2)CacheStore 先update Cache中的數據,而後再向數據庫執行update操做;
這種模式在一個同步過程當中,先改Cache,再改數據庫。所以性能也不是最理想的。
5.2 Refresh-Ahead
與Read-Through相對,它是異步的。
Coherence在Cache數據過時前,有CacheStore自動從新從數據庫加載數據。而前臺應用在查詢數據時,CacheStore 僅調用Cache.get(X)。所以這種模式的效率明顯高於read-through。 自動重載數據的時間能夠設定。
5.2 Write-behind
與write-through相對,它是異步的。
應用調用CacheStore進行update時,CacheStore不去操做數據庫,直接返回結果。而Coherence集羣自動對操做進行排隊(queue),在間隔一段時間後(interval), CacheStore在執行隊列中的 update 操做。 這樣,減小的同步操做數據庫的時間被節省,修改類功能的性能就能獲得大幅提升。這也是Coherence的一大特點。
Coherence企業級緩存(五)與Hibernate集成(1)
3. Cache客戶端配置:Hibernate配置
3.1) hibernate.cfg.xml
3.2) 啓用查詢緩存的代碼
要確保代碼中使用查詢,即在建立 query 後,打開開關,並設置cacheRegion,本例中使用統一的 cacheRegion 「HIBERNATE_QUERY_CACHE」
3.3) 啓用實體L2緩存
在 hbm.xml 中配置 節點,爲VO類啓用實體緩存。
3.4) 客戶端緩存配置
客戶端要使用與服務端一樣的緩存配置 hibernate-cache-config.xml, 不然可能沒法進行存儲。 本例將其複製過來,放到classpath 下的 config目錄中,所以,客戶端啓動命令(若是是tomcat,weblogic,websphere,修改相應cmd或bat文件)中也要加java參數:
4. 啓動客戶端Hibernate應用程序
執行數據查詢操做,觀察日誌,以肯定數據存儲到了M2的三個節點中。
4.1) Coherence客戶端啓動日誌
4.2) 觀察Hibernate SQL輸出
記得在log4j.xml 中打開相應的日誌開關:
觀察日誌輸出
第一次執行了sql,
後面sql都未執行,而且查詢結果數爲1,和第一次執行sql的結果相同。代表以後從Coherence中獲取了數據, 緩存生效。
4.3) 查看M2 上的cache數據:
在M2上的節點控制檯切換到 HIBERNATE_QUERY_CACHE cache下面,執行:
並執行Coherence命令
命令查看全部已在Cache中存儲的數據。 下面的日誌每一個 sql:開頭的就是一個對Query的緩存項。
OK, 大功告成,成功將Coherence與Hibernate集成,Hibernate經過Coherence進行實體數據,查詢數據的緩存。
Coherence企業級緩存(五)與Hibernate集成(2)
3. Cache客戶端配置:Hibernate配置
3.1) hibernate.cfg.xml
3.2) 啓用查詢緩存的代碼
要確保代碼中使用查詢,即在建立 query 後,打開開關,並設置cacheRegion,本例中使用統一的 cacheRegion 「HIBERNATE_QUERY_CACHE」
3.3) 啓用實體L2緩存
在 hbm.xml 中配置 節點,爲VO類啓用實體緩存。
3.4) 客戶端緩存配置
客戶端要使用與服務端一樣的緩存配置 hibernate-cache-config.xml, 不然可能沒法進行存儲。 本例將其複製過來,放到classpath 下的 config目錄中,所以,客戶端啓動命令(若是是tomcat,weblogic,websphere,修改相應cmd或bat文件)中也要加java參數:
4. 啓動客戶端Hibernate應用程序
執行數據查詢操做,觀察日誌,以肯定數據存儲到了M2的三個節點中。
4.1) Coherence客戶端啓動日誌
4.2) 觀察Hibernate SQL輸出
記得在log4j.xml 中打開相應的日誌開關:
觀察日誌輸出
第一次執行了sql,
後面sql都未執行,而且查詢結果數爲1,和第一次執行sql的結果相同。代表以後從Coherence中獲取了數據, 緩存生效。
4.3) 查看M2 上的cache數據:
在M2上的節點控制檯切換到 HIBERNATE_QUERY_CACHE cache下面,執行:
並執行Coherence命令
命令查看全部已在Cache中存儲的數據。 下面的日誌每一個 sql:開頭的就是一個對Query的緩存項。
OK, 大功告成,成功將Coherence與Hibernate集成,Hibernate經過Coherence進行實體數據,查詢數據的緩存。
Coherence企業級緩存(六) JMX 管理和監控
7.1 概述
Coherence支持集羣JMX管理和監控,方便在多Node環境下的統一管理。
根據Coherence官方的推薦,通常一個集羣中只設置一個JMX管理服務器(MBeanServer),而且管理服務器不存儲數據(設置啓動參數storage_enabled=false);其餘Node爲受管節點,存儲數據。
7.2 啓動參數
要爲節點啓用JMX管理,啓動時只要加入必要的java property便可。通常能夠JDK5+自帶的JConsole工具作管理和監控。
JMX Server:
JMX Node:
7.3 JMX Server監控
經過JConsole鏈接Coherence JMX Server後的界面以下圖所示:
圖中,
Cluster表明整個集羣
Node節點下表明各節點,圖中有1,2 兩個節點;
Cache目錄表明當前集羣中建立的的NamedCache,圖中展現了集羣中有一個分區緩存 cache1,存儲在節點2 中。
其餘還有Server,StorageManager,PointToPoint等管理項。
右側列出了所選項目的詳細屬性,圖中爲Node 2 上數據存儲的信息,比較有用的是
命中次數CacheHits,
失誤次數CacheMisses,
緩存訪問次數:TotalGets,經過 CacheHits/ TotalGets 就可獲得命中率
緩存元素上限:HighUnits等。
經過觀察各節點Cache的主要指標,就能夠監控Coherence的運行狀況,分析緩存的利用效率。見下圖例:
圖顯示了在JOP號碼資源應用下,號碼資源VO的CacheHits變化狀況,命中數在逐步提升,爲2800,說明緩存有效發揮了其做用;固然命中率是反映Cache利用率更爲直觀的指標。
7.4 Node監控
經過鏈接不一樣Node,還能夠監控各存儲節點的內存變化等信息,爲調優提供必要依據。
Coherence企業級緩存(七) 性能調優
Coherence調優是很關鍵的一環,特別是對大型企業級應用,海量數據型應用,它將決定Coherence集羣可否將效能最大化的發揮出來。
調優一般分三步:基礎調優,運行前常規調優,運行後調優
8.1基礎調優
包括操做系統調優,網絡調優
操做系統的一些參數,對Coherence集羣的數據傳輸有影響。
如:非Wins系統下Socket緩衝大小,應該至少增長到2M;Windows上的Datagram大小等,這些在官方指南中有詳細的說明。
網絡調優主要對交換機緩衝(Switch Buffer), Path MTU 等因素,比較常見的狀況是,交換機緩存若是過小,Coherence在作Node通訊時會發生延遲,Node日誌通常爲:
此時就須要增長交換機緩衝大小。
8.2運行前常規調優
指根據Coherence通常經驗原則和最佳實踐,在應用系統運行前分析緩存數據總量大小,計算Node個數,設置Node JVM內存等。
緩存數據總量大小(DataSize, M):根據應用規模,數據量規模,業務頻度,預先估計應該歸入緩存的數據量的大小(總字節數)。對大型系統來講,多是1G – xG。
計算節點個數:分區和Near緩存每節點只承擔 M/N 的數據量,Coherence的原則是,儘可能多節點,而不要將Node的內存設置過大,避免GC時間過長,通常不要超過 1G;所以,獲得估計的數據總量大小M後,就能夠估計須要配置的節點數,假設JVM mx爲512M,則N=M/512,並據此推測須要的物理機器的數量。
JVM內存:Coherence默認爲64M,每節點最大不要超過1G。而且最小和最大值設置爲相同。固然能夠根據項目狀況,設置爲 384m, 128m等。
例如:
GC 參數:通常應用Coherence的多爲大型系統,多CPU;且緩存數據變化可能比較頻繁。
8.3運行後調優
系統上線後,在運行過程當中,可能會出現性能不如預期的狀況,或者不按期出現緩慢狀況。除了對JVM 垃圾回收問題進行分析,還能夠對應用進行分析,對緩存配置進行優化。
JVM 垃圾回收問題:節點GC時,會致使Node間的傳輸暫停,須要重傳,引發集羣性能降低。可能夠經過Node的日誌觀察到,相似於:
除了以前的優化交換機緩衝,還要考慮垃圾回收引發此問題的具體緣由,能夠經過打開垃圾回收日誌進行觀察,這一般可能會定位到程序代碼的算法等問題。
應用分析:
若是爲了簡便,在Coherence配置中使用 * 配置NamedCache的存儲屬性,那麼意味着,全部NamedCache或者說一部分Cache 使用了相同的設置,如元素個數,超時時間,清除策略,前端緩存大小等。
但不一樣業務功能其數據量大小,查詢頻率,查詢條件的多樣性,數據修改的頻率都是不一樣的,若是配置相同,則Cache機制在不一樣業務上體現的性能是不一樣的,應該區別對待,例如:
1) 數據字典修改頻率極低,能夠只採用local cache, 超時時間設置長一些,例如12h 。
2) 鑑權操做頻率很高,所以要求高性能。鑑權數據中權限點修改頻率低,但角色受權數據修改頻率略高,但比通常業務也低不少,能夠將 front cache設置大一些,或者只採用local訪問。
3) 在Hibernate中,低頻修改數據緩存配置爲 nonstrict-read-write 類型;只讀數據採用 read-only 型。
4) 至於業務數據,狀況比較複雜。
例如:手機號碼錶,數據量極大,而且服務於BOSS大部分業務,而且手機號碼的用戶資料變動較少,所以緩存能夠設置大些, 超時時間設置長些。而相似的渠道數據,數據量略小一些,HighUnits可設置稍小一些。
而對於一些修改頻繁,或新增頻繁的數據,超時時間(Expiry Delay) 應當設置小一些。
此類分析應該跟蹤生產環境的運行狀況,業務頻率,修改操做頻率等,進行調整優化,並跟蹤調優後的結果。
9. 結束
Oracle Coherence具備通常緩存框架的極不同的強大特性,自管理,分區緩存,線性擴展等使得它能有效提高應用,特別是大型企業級應用的性能。Coherence也是一個網格計算方案,其線性擴展也體現了「另類」的系統架構,能發揮出強大的功能。
參考資料:
1. Oracle. Coherence User-guide.htm
2. http://www.oracle.com/technology/global/cn/products/coherence/index.html
3. iniu blog http://iniu.net/iwork/2008/02/oracle-coherence.html
Coherence企業級緩存(一) 特色
Coherence企業級緩存(二) QuickStart和編程
Coherence企業級緩存(三) 四種緩存類型
Coherence企業級緩存(四) 數據管理模式
Coherence企業級緩存(五)與Hibernate集成(1)
Coherence企業級緩存(五)與Hibernate集成(2)
Coherence企業級緩存(六) JMX 管理和監控
Coherence企業級緩存(七) 性能調優
轉載自:http://raymondhekk.iteye.com/blog/256831
程序員的基礎教程:菜鳥程序員