緩存集群
❶ Hibernate的緩存技術有哪些
緩存是資料庫數據在內存中的臨時容器,它包含了庫表數據在內存中的臨時拷貝,位於資料庫與應用程序之間,其作用是為了降低應用程序對物理數據源訪問的頻次,從而提高應用的運行性能。
Hibernate的緩存機制
1.1持久化層的緩存的范圍
持久層設計中,往往需要考慮幾個不同層次中的數據緩存策略。這些層次的劃分標准針對不同情況有所差異,一般而言,ORM的數據緩存應包含如下幾個層次:
事務級緩存(Transaction Layer Cache)
緩存只能被當前事務訪問。緩存的生命周期依賴於事務的生命周期,當事務結束時,緩存也就結束生命周期。在此范圍下,緩存的介質是內存。事務可以是資料庫事務或者應用事務,每個事務都有獨自的緩存,緩存內的數據通常採用相互關聯的對象形式。
應用級/進程級緩存(Application/Process Layer Cache)
緩存被進程內的所有事務共享。這些事務有可能是並發訪問緩存,因此必須對緩存採取必要的事務隔離機制。緩存的生命周期依賴於進程的生命周期,進程結束時,緩存也就結束了生命周期。進程范圍的緩存可能會存放大量的數據,所以存放的介質可以是內存或硬碟。緩存內的數據既可以是相互關聯的對象形式也可以是對象的鬆散數據形式。對象的鬆散數據形式有點類似於對象的序列化數據,但是對象分解為鬆散的演算法比對象序列化的演算法要求更快。
集群級緩存(Cluster Layer Cache)
在集群環境中,緩存被一個機器或者多個機器的進程共享。緩存中的數據被復制到集群環境中的每個進程節點,進程間通過遠程通信來保證緩存中的數據的一致性,緩存中的數據通常採用對象的鬆散數據形式。對大多數應用來說,應該慎重地考慮是否需要使用集群范圍的緩存,因為訪問的速度不一定會比直接訪問資料庫數據的速度快多少。
持久層提供以上多種層次的緩存。如果在事務級緩存中沒有查到相應的數據,還可以到進程級或集群級緩存內查詢,如果還是沒有查到,那麼只有到資料庫中查詢。事務級緩存是持久化層的第一級緩存,通常它是必需的;進程級或集群級緩存是持久化層的第二級緩存,通常是可選的。
1.2 hibernate緩存機制
Hibernate提供了兩種緩存,第一種是Session的緩存,又稱為一級緩存。由於Session對象的生命周期通常對應一個資料庫事務或者一個應用事務,因此它的緩存是事務范圍的緩存。第一級緩存是必需的,不允許而且事實上也無法卸除。在第一級緩存中,持久化類的每個實例都具有唯一的OID。
❷ 將緩存數據分片到集群的不同節點,分片規則可以使用什麼演算法
以每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 定義
❸ 超詳細MySQL資料庫優化
資料庫優化一方面是找出系統的瓶頸,提高MySQL資料庫的整體性能,而另一方面需要合理的結構設計和參數調整,以提高用戶的相應速度,同時還要盡可能的節約系統資源,以便讓系統提供更大的負荷.
1. 優化一覽圖
2. 優化
筆者將優化分為了兩大類,軟優化和硬優化,軟優化一般是操作資料庫即可,而硬優化則是操作伺服器硬體及參數設置.
2.1 軟優化
2.1.1 查詢語句優化
1.首先我們可以用EXPLAIN或DESCRIBE(簡寫:DESC)命令分析一條查詢語句的執行信息.
2.例:
顯示:
其中會顯示索引和查詢數據讀取數據條數等信息.
2.1.2 優化子查詢
在MySQL中,盡量使用JOIN來代替子查詢.因為子查詢需要嵌套查詢,嵌套查詢時會建立一張臨時表,臨時表的建立和刪除都會有較大的系統開銷,而連接查詢不會創建臨時表,因此效率比嵌套子查詢高.
2.1.3 使用索引
索引是提高資料庫查詢速度最重要的方法之一,關於索引可以參高筆者<MySQL資料庫索引>一文,介紹比較詳細,此處記錄使用索引的三大注意事項:
2.1.4 分解表
對於欄位較多的表,如果某些欄位使用頻率較低,此時應當,將其分離出來從而形成新的表,
2.1.5 中間表
對於將大量連接查詢的表可以創建中間表,從而減少在查詢時造成的連接耗時.
2.1.6 增加冗餘欄位
類似於創建中間表,增加冗餘也是為了減少連接查詢.
2.1.7 分析表,,檢查表,優化表
分析表主要是分析表中關鍵字的分布,檢查表主要是檢查表中是否存在錯誤,優化表主要是消除刪除或更新造成的表空間浪費.
1. 分析表: 使用 ANALYZE 關鍵字,如ANALYZE TABLE user;
2. 檢查表: 使用 CHECK關鍵字,如CHECK TABLE user [option]
option 只對MyISAM有效,共五個參數值:
3. 優化表:使用OPTIMIZE關鍵字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;
LOCAL|NO_WRITE_TO_BINLOG都是表示不寫入日誌.,優化表只對VARCHAR,BLOB和TEXT有效,通過OPTIMIZE TABLE語句可以消除文件碎片,在執行過程中會加上只讀鎖.
2.2 硬優化
2.2.1 硬體三件套
1.配置多核心和頻率高的cpu,多核心可以執行多個線程.
2.配置大內存,提高內存,即可提高緩存區容量,因此能減少磁碟I/O時間,從而提高響應速度.
3.配置高速磁碟或合理分布磁碟:高速磁碟提高I/O,分布磁碟能提高並行操作的能力.
2.2.2 優化資料庫參數
優化資料庫參數可以提高資源利用率,從而提高MySQL伺服器性能.MySQL服務的配置參數都在my.cnf或my.ini,下面列出性能影響較大的幾個參數.
2.2.3 分庫分表
因為資料庫壓力過大,首先一個問題就是高峰期系統性能可能會降低,因為資料庫負載過高對性能會有影響。另外一個,壓力過大把你的資料庫給搞掛了怎麼辦?所以此時你必須得對系統做分庫分表 + 讀寫分離,也就是把一個庫拆分為多個庫,部署在多個資料庫服務上,這時作為主庫承載寫入請求。然後每個主庫都掛載至少一個從庫,由從庫來承載讀請求。
2.2.4 緩存集群
如果用戶量越來越大,此時你可以不停的加機器,比如說系統層面不停加機器,就可以承載更高的並發請求。然後資料庫層面如果寫入並發越來越高,就擴容加資料庫伺服器,通過分庫分表是可以支持擴容機器的,如果資料庫層面的讀並發越來越高,就擴容加更多的從庫。但是這里有一個很大的問題:資料庫其實本身不是用來承載高並發請求的,所以通常來說,資料庫單機每秒承載的並發就在幾千的數量級,而且資料庫使用的機器都是比較高配置,比較昂貴的機器,成本很高。如果你就是簡單的不停的加機器,其實是不對的。所以在高並發架構里通常都有緩存這個環節,緩存系統的設計就是為了承載高並發而生。所以單機承載的並發量都在每秒幾萬,甚至每秒數十萬,對高並發的承載能力比資料庫系統要高出一到兩個數量級。所以你完全可以根據系統的業務特性,對那種寫少讀多的請求,引入緩存集群。具體來說,就是在寫資料庫的時候同時寫一份數據到緩存集群里,然後用緩存集群來承載大部分的讀請求。這樣的話,通過緩存集群,就可以用更少的機器資源承載更高的並發。
一個完整而復雜的高並發系統架構中,一定會包含:各種復雜的自研基礎架構系統。各種精妙的架構設計.因此一篇小文頂多具有拋磚引玉的效果,但是資料庫優化的思想差不多就這些了.
❹ JAVA幾種緩存技術介紹說明
1、TreeCache / JBossCache
JBossCache是一個復制的事務處理緩存,它允許你緩存企業級應用數據來更好的改善性能。緩存數據被自動復制,讓你輕松進行JBoss伺服器之間 的集群工作。JBossCache能夠通過JBoss應用服務或其他J2EE容器來運行一個MBean服務,當然,它也能獨立運行。
2、WhirlyCache
Whirlycache是一個快速的、可配置的、存在於內存中的對象的緩存。它能夠通過緩存對象來加快網站或應用程序的速度,否則就必須通過查詢資料庫或其他代價較高的處理程序來建立。
3、SwarmCache
SwarmCache是一個簡單且有效的分布式緩存,它使用IP multicast與同一個區域網的其他主機進行通訊,是特別為集群和數據驅動web應用程序而設計的。SwarmCache能夠讓典型的讀操作大大超過寫操作的這類應用提供更好的性能支持。
4、JCache
JCache是個開源程序,正在努力成為JSR-107開源規范,JSR-107規范已經很多年沒改變了。這個版本仍然是構建在最初的功能定義上。
5、ShiftOne
ShiftOne Java Object Cache是一個執行一系列嚴格的對象緩存策略的Java lib,就像一個輕量級的配置緩存工作狀態的框架。
❺ 高性能高並發網站架構,教你搭建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
吉海波