本文目錄一覽：
redis集群角色切換java調用異常
redis集群角色切換java調用異常
一、Redis狀態檢查
唯一標記一個redis實例的是ip和埠，前端是用tcp方式來訪問redis的，我們提供給應用訪問的是一個ip+63379(一般使用63379) 埠。因此我們執行如下命令檢查redis狀態:
上面的role這個值一定是master的，只要保證vip在master上我們的Padis cache服務就是沒有問題的，如果不通或者role的角色是slave，那就得繼續查看是什麼問題.
二、兩個redis的角色都是slave的問題
當兩個主機都掛了或者我們自己不小心將兩個redis停了，並且我們用下面的命令檢查
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} info replication
發現無論是vip還是另外的兩個ip都是role:slave 的角色，這個時候需要對vip所在的主機執行slaveof no one 的操作,將vip 所在的redis變成master,如:
/wls/wls81/redis/bin/redis-cli -h {vip} -p {port} -a {password} slaveof no one
三、sentinel的配置參數
我們的sentinel 配置文件裡面有兩個重要的配置
sentinel monitor pds_jks-core-prd 10.33.94.65 63379 1 ———–配置的ip和埠任何時候都需要是master的ip埠,切換的時候程序自動會改 。另外，紅色所示部分pds_jks-core-prd為redis對外提供的主機名，一般Jedis在調用redis時會用到此名稱。如果配置多個哨兵則一般要求此名稱唯一標識
sentinel down-after-milliseconds pds_jks-core-prd 15000 ———-這個是sentinel連接master的超時時間，超過這個時間就認為master掛了，實現自動切換。這個默認是30秒，這個時間得調節好，大了會在真正出現故障的時候切換時間會長，小了有時候master由於持久化數據，繁忙不響應，會導致自動切換，實際只是瞬間不可用，現在認為設置為15秒為宜.
四、AOF日誌
這個日誌記錄了每一個寫入命令或者刪除命令的，這個對於我們審計功能是有用的，由於佔用很多磁碟，默認我們是關閉的
如果開啟會生成一個.aof的文件在data文件中. 如: /wls/apache/servers/pds_jks-core-prd/data
在redis運行中中開啟：
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config set appendonly yes
開啟了可以查看日誌，記錄每一個命令，如有必要可以開啟查完問題後關閉. 同時說明一下
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config set 可以在redis運行的時候設置多個它的參數
五、空閑連接的timeout
redis服務端不會自動斷開客戶端來的連接，redis服務端有設置客戶端空閑連接超時時間，可用命令
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config get timeout
查看當前timeout時間，默認是0，就是不斷開空閑的連接，如果不斷開空閑的連接，就會造成redis連接過多
所以一般情況下可以設置為3600秒:
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config set timeout 3600
也就是3600秒後將空閑的連接關閉掉. 可以用下面的命令查看某個連接空閑了多久:
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} client list
六、監控redis執行的命令
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} monitor
上述這個monitor命令可以查看redis執行了什麼命令，有時候查問題很有必要用到，我們可以知道那段時間redis執行了什麼，從而進行我們的問題診斷。
七、key的查找與執行
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} keys “*”
keys這個命令查找所有的key，但是最好慎用，因為它很耗redis的性能，每個key都遍歷一遍. 也可以進行模糊匹配如： keys “send*”
千萬記住在生產環境上不能隨便亂用，因為它會將redis性能耗盡，導致其他連接獲取不到響應.
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} dbsize
dbsize 這個命令可以看到整一個redis裡面有多少個key，當然和keys “*” | wc -l結果是一樣的。
當我們需要批量刪除key值時可以用如下命令即可:
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} keys “send*” | xargs /wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} del
我們需要將整個db都flush掉可以用:
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} -a MamcCorePrd flushdb
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} -a flushall
八、由於連接redis的客戶端使用jedisPool
如果設置了
redis.pool.testOnBorrow.REL=true
redis.pool.testOnReturn.REL=true
這兩個參數是說在或者pool中的連接和返回連接給pool的時候都需要檢查一下連接的有用性，也就是ping一下這個redis是不是好的，
這樣在高並發的時候，由於並發線程太多，ping操作相對線程啟動來說很慢，因此，應用會堵在類似如下線程dump的地方
“[ACTIVE] ExecuteThread: ’19’ for queue: ‘weblogic.kernel.Default (self-tuning)'” id=33 idx=0x9c tid=273669 prio=5 alive, native_blocked, daemon
at jrockit/net/SocketNativeIO.readBytesPinned(Ljava/io/FileDescriptor;[BIII)I(Native Method)
at jrockit/net/SocketNativeIO.socketRead(SocketNativeIO.java:32)
at java/net/SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I(SocketInputStream.java)
at java/net/SocketInputStream.read(SocketInputStream.java:129)
at java/net/SocketInputStream.read(SocketInputStream.java:90)
at redis/clients/util/RedisInputStream.fill(RedisInputStream.java:109)
at redis/clients/util/RedisInputStream.readByte(RedisInputStream.java:45)
at redis/clients/jedis/Protocol.process(Protocol.java:64)
at redis/clients/jedis/Protocol.read(Protocol.java:131)
at redis/clients/jedis/Jedis.ping(Jedis.java:35)
at redis/clients/jedis/JedisPool$JedisFactory.validateObject(JedisPool.java:104)
at org/apache/commons/pool/impl/GenericObjectPool.addObjectToPool(GenericObjectPool.java:922)
at org/apache/commons/pool/impl/GenericObjectPool.returnObject(GenericObjectPool.java:917)
^– Holding lock: org/apache/commons/pool/impl/GenericObjectPool@0xb8513338[fat lock]
at redis/clients/util/Pool.returnResourceObject(Pool.java:29)
at redis/clients/util/Pool.returnResource(Pool.java:41)
at com/paic/icore/mams/common/jedis/util/RedisPoolCacheTools.release(RedisPoolCacheTools.java:43)
雖然後面會自動恢復，不過導致應用響應緩慢.解決方法是將該兩個參數設置為false，並且定期檢查：
testOnBorrow.REL=false
testOnReturn.REL=false
timeBetweenEvictionRunsMillis=60000 ——-每隔60秒定期檢查空閑連接
minEvictableIdleTimeMillis=120000 ———連接在池中保持空閑而不被空閑連接回收器線程回收的最小時間值,單位毫秒
numTestsPerEvictionRun=-1 ———-空閑連接掃描時，每次最多掃描的連接數,一般設置為-1，全部掃描
設置成這樣之後就不用每次都測試了，這樣就提高了應用的性能
有時候由於持久化導致master變得緩慢，所以建議關閉master的持久化，讓slave持久化
關閉持久化 /wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} config set save “”
開通持久化 /wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} config set save “900 1 300 10 60 10000”
關閉持久化後如果發生主備切換了，請將master的持久化關閉，slave的持久化開啟
九、查詢每秒執行的命令個數
十、單位時間內Redis執行的命令次數
Java 集群鎖如何實現
1. 用資料庫，在資料庫建一張表，需要鎖的節點都可以嘗試用 select * from Lock where id=xx for update. 這個時候只有一個節點能拿到結果，其它的都會等待，就能實現一個簡單的悲觀鎖。
2. 用 Zookeeper 來做分散式鎖，具體可以搜一下。
3. 自己實現，搞個節點來做這個事情，所有要獲取鎖的都走 RPC 調用來請求鎖，用完以後記得釋放，不然其他的節點就會掛那裡。
java 集群
群集方法介乎兩種計算機系統結構之間。當把多台計算機配置或互連在一起時，可採取鬆散耦合或緊密耦合結構。網路就是一個鬆散耦合的系統，我們也稱其為異類系統結構。網路把由各種CPU、應用軟體、NIC（網路介面控制器）、甚至是操作系統組成的多台計算機連接在一起。計算機之間的地理距離可以近在咫尺，也可以遠在天邊。可以用實時和/或非同步方式耦合網路。
網際網路就是一個典型的極為鬆散與異類配置的例子。網際網路本身不能「實時」控制與它連接的任何主機。在鬆散耦合網路中，單機崩潰一般不會影響網路的其它部分。
相反，緊密耦合系統則高度依賴於構成系統的所有部件。當系統由相同部件組成，採用並行操作方式並共享所有子系統（存儲器）時，我們稱其為同類系統結構。緊密耦合系統最常見的例子是SMP（對稱多處理）。在SMP狀態下，根據工作量的多少把任務分給幾台處理器，這樣可均勻地分配工作量，以便提高數據吞吐量。
我們舉了兩個典型的鬆散和緊密耦合系統的例子，群集就介於鬆散和緊密耦合系統之間。根據系統的配置，在某些方面（比如操作系統），群集控制的系統也許更偏向緊密耦合的系統，或者偏向鬆散耦合的系統（比如獨立計算能力，通過公共存儲器連接）。
通常群集器放在同一設備區或同一辦公樓里。從理論上說，群集控制方法可應用於閉路廣域網環境中（現正在美國東北部地區進行試驗）。可是在考慮到視頻伺服器應用時，一般來說只能把設備放在主要設施運行所在地。
公共數據共享
群集允許共享幾個節點的數據。在此應用中，這些節點包括客戶工作站、中央或多伺服器。我們知道可以通過許多路徑（比如星形結構）連接節點，客戶可通過不同連接的節點路徑存取數據。當節點就是伺服器時便可共享公共存儲器，某個伺服器節點故障不會導致整個群集器系統癱瘓。
在12月專欄里，我們把群集描述成一個提供高可得性的系統。對廣播或有線電視操作來說，視頻伺服器必須要提供連續的或高可得性的數據。考慮到這一點，我們認為視頻伺服器體系結構採用群集是大有潛力的。
待命或無源伺服器結構就是一種群集形式。在這種結構下，一個或多個伺服器（或節點）平時保持在待命狀態，隨時可以啟動。利用後台控制系統管理待命伺服器內容數據。在未發生故障之前一般不啟用無源伺服器。
無源伺服器未必就是主伺服器的完全鏡像，它也可以有一些有限的數據源，包括存儲器，要經常清除這些數據，然後重新裝入最新的節目或廣告。通過這一循環過程把適量的數據（或視頻媒介）保持在待命狀態，在需要時隨時可以上線使用。
伺服器在待命狀態時通常由少量的部件組成，比如編解碼器，在出現故障或另一個伺服器需要它支持的時候，該伺服器可立即被集成到系統中應用。此時，伺服器進入負載均衡狀態。
數據共享
數據共享是群集器需要提供的最基本功能之一。我們還是以視頻伺服器的應用為例，多個編輯站在這裡獨立地工作，不過利用一組公共伺服器來管理數據和應用層的處理。
在這個例子中，多個新聞編輯站（或客戶工作站）可以選擇用哪個編輯伺服器（包括編輯用的軟體和硬體）來進行編輯。這些伺服器控制對公共媒體資料庫的存取，編輯站只是這些伺服器的簡單控制器GUI（圖形用戶界面）。編輯伺服器進一步控制接入另一個更大的數據存儲庫（通常是新聞檔案）。
這個概念可通過群集軟體實現。在獨立的編輯站通過群集器存取數據的過程中，編輯與數據存取或存儲處理自動進行，不會影響其它的客戶編輯站或預放站。通過提供連續的數據可得性，每個伺服器可以是有源的，也可以是無源的，視工作負荷而定。假如有一個伺服器發生了故障，該結構也可提供冗餘或保護方式。
共享一個操作系統和平台是群集的又一個共同特點。讓硬體與軟體平台同屬一類，也就是說，基本上是相同的，就可採用公用互連方案與公共文件格式結構。在SMP這樣的系統中，所有部件都依賴於公用硬體而像單獨部件一樣運行。正如我們已提到的，群集可以讓一部分系統保持同類結構，但脫離所有系統都有的依賴性，其它性能就會下降。
其它優點
我們現在還是回到基於群集伺服器的編輯環境中來，我們又發現了其它一些優點。伺服器硬體具有的冗餘性可對數據起保護作用。在新聞編輯環境中，當即將播放時，一個或更多的伺服器便可將客戶工作站的功能變成播出功能，直接把新聞播出去。這樣還能讓所有客戶和伺服器接入別的伺服器的數據，包括在最後一分鐘直接存取中央存儲庫的數據。
通過使用多個伺服器（每個伺服器收集、編輯、存檔和重放的資源是一個類型的），系統便可對硬體進行備份。在某個伺服器出現故障時，可把資源轉給或分給其它用戶，系統的其餘部分仍繼續工作。
除了上述的數據共享外，其它群集器結構也是可行的。在有些情況下，某些資源可被一個特定的節點「擁有」，在未接到指令前不會放棄。可將該系統的結構配置成一個節點有多個輸入編碼器，但只有一個輸出解碼器。另一個節點可能沒有輸入，但有好幾個輸出供放像和預看用。如果某一個節點出現故障，可讓與它相對應的節點頂替它，直到它被修復為止。
非共享結構
從硬體上說，每個節點的能力（或資源）基本上相同，但內部系統配置是用各種形式鎖定的，除非另有要求。按照群集語言可把此結構
叫做非共享結構。在此結構里，某些資源在未被傳送給其它節點或者該節點未出故障之前歸一個節點所有。在採用非共享結構的計算機與模式里運用群集法通常會把硬碟等設備分配給一個節點，並阻止其他人使用它，除非將其開放或該節點發生故障。
群集結構的其它實施方面增加了系統的複雜程度。除了非共享結構外（只提供最簡單的性能和可得性），還有磁碟共享結構。磁碟共享可提高存儲接入不同主機系統的能力。
從硬體的角度看，系統的磁碟陣列控制器可以很容易地管理這個共享結構。比較難辦的是在最低級別（文件或記錄層）上協調更新數據。
協調工作必須成為群集軟體的一部分。可以設想一下，如果兩個用戶同時接入同一記錄層會發生什麼情況。假定每個用戶都修改了文件。用戶1先把數據寫入伺服器，他發現用戶2做了完全不同的修改並且把修改後的文件用同一文件名存入相同的磁碟，或許存在另一個伺服器上，這樣就有可能把第一個用戶修改的文件衝掉。沒有一個控制方案，就會亂成一團。
儘管每個文件或記錄層都有簡單的口令或鎖定保護，但要確保用文件的正確版本存成另一個文件名或是「正式」版，則要求具有更高層的數據控制與管理能力。磁碟快速緩存問題又是另一種情形，我們等一會兒再說。
另一個防止錯誤數據覆蓋正確數據的方法是在修改未最後定之前限制接入某一特定文件。在計算機數據域中，用一個稱為信息傳送的程序通知管理員（通常是應用後台軟體的一部分）文件存取被鎖定，直到修改程序結束為止。
原子操作
原子操作的三個步驟是：讀數據、修改數據、然後重新寫入新數據。在原子操作過程中，在未執行完操作之前不會受到任何干擾。還必須有其他保護措施，以防隱藏的備份文件在以後某個無法預測的時間改寫其它的文件。
當數據分布在不止一個存儲磁碟上時，或者當公共存儲陣列中的數據被不同用戶在不同時間存取時，如何防止數據不一致是群集軟體需要解決的又一個問題。無論是通過硅緩存器還是通過遠程接入的臨時磁碟緩存器（甚至分區）進行高速緩存都會遇到定時和同步的問題。我們把這個問題叫做緩存相關性，它是因磁碟驅動器定時問題引起的。
磁碟驅動器並不一定能馬上寫入數據，磁頭也許定位在錯誤的磁軌上，導輪也許偏離相位190度，等結束運轉後才能開始磁頭的寫入操作，或許還因為溫度問題造成暫時性延緩，直到一切都符合條件為止。
這通常被稱為等待時間，磁碟驅動器的機械部分要求在驅動器等待寫入時暫存一下數據。最常見的方法是在驅動器上安一個硅緩存器，這個過程被叫做寫回高速緩存。在把主機儲存器中的數據轉存到磁碟驅動器的過程中，設一個寫回緩存器標識，對數據源表示寫入程序成功了。實際上，得過一會兒才能開始真正的電磁機械式的數據儲存過程。
假如系統上的另一個節點也從這個驅動器讀數據，（這是經過許可的操作，因為數據發生器已接到通知，新數據已發送到了這個位置），那麼緩存器已在指定位置存儲了正確新數據的指示信號就不見了。我們用失效數據一詞來表示未更新數據進入新數據區的狀態。
無效數據
RAID控制器在各自磁碟陣列的寫回緩存器里為與這個特殊的陣列有關的磁碟管理失效數據。假如在軟體里設一些適當的開關來檢測和阻止它發生，那麼數據相關性就只是一個小問題了。
當系統是由多層陣列構成的時候，控制失效數據問題的任務就交給高級別軟體去完成，把信號傳送給各自的陣列，就不會發生孤立或失效數據問題了。
在這個簡化的單一視頻伺服器模型里，媒體是通過單編碼器輸入的，並存在一個單實體陣列上。由一個更高級別（通常是第三方API，應用程序介面）登記和管理活動圖像數據。通常將其作為任選的「媒體管理」或「資產管理器」包出售。通過這個軟體，控制活動圖像和數據的過程成為一個閉路過程，因為輸入與輸出指令必須通過這個管理軟體包。該軟體在自己的資料庫里始終跟蹤著數據的有效性。
如果有好幾個伺服器，每個伺服器有自己的任務，情況就變得比較複雜了。這時可以讓幾個信號源的輸入進入不同的編碼器，並存在一個較大的磁碟陣列里。這些陣列通常與光纖通道仲裁環相連，由於它的連接方式決定，它可迫使部分重寫動作由伺服器推遲到存儲器，直到有了充足的帶寬來把該數據從這個存儲器存入另一個存儲器。
在類似的應用中，媒體管理軟體就更完善，更必不可少了。有時候製造商會提供一個完全獨立的CPU和資源管理軟體包（作為選件）。這個軟體包就像看門狗那樣管理伺服器之間的數據共享操作。除了這些基本概念外，還有大量的定時和數據驗證問題，這些問題會經常在伺服器結構的軟體與子系統中碰到。
群集的過程和功能正在擴展到設備內和設備間應用中。群集器理念最終將允許整個廣播集團通過光纖或通過廣域網共享資源。雖然可以讓設施連成網共享媒介，可是在這些設施相互離得很遠的情況下實現節點資源共享的設想似乎還很遙遠。
集群java版本和誰要匹配
集群java版本和誰要匹配：
搭建實驗環境
需求：Tomcat實現群集功能，以Nginx做代理，同時用zabbix監控Tomcat服務。可以開啟多台虛擬機，每台都安裝Tomcat服務，用另一種方法，一台伺服器安裝多個Tomcat服務，以埠號區分，實現群集搭建。
java支持class集群模式嗎
支持。
Java具有多線程功能，可以實現class集群模式。
分散式是指將不同的業務分布在不同的地方， 而集群指的是將幾台伺服器集中在一起，實現同一業務，分散式中的每一個節點，都可以做集群， 而集群並不一定就是分散式，分散式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/306106.html
微信掃一掃 
支付寶掃一掃 