java集群,java集群下文件存儲

本文目錄一覽：

• 1、java如何操作librados獲取集群的osd狀態及mon狀態？
• 2、java支持class集群模式嗎
• 3、JAVA服務集群與非集群的區別？
• 4、java 集群

java如何操作librados獲取集群的osd狀態及mon狀態？

一個Ceph客戶端，通過librados直接與OSD交互，來存儲和取出數據。為了與OSD交互，客戶端應用必須直接調用librados，連接一個Ceph Monitor。一旦連接好以後，librados會從Monitor處取回一個Cluster map。當客戶端的應用想讀或者取數據的時候，它會創建一個I/O上下文並且與一個pool綁定。通過這個I/O上下文，客戶端將Object的名字提供給librados，然後librados會根據Object的名字和Cluster map計算出相應的PG和OSD的位置。然後客戶端就可以讀或者寫數據。客戶端的應用無需知道這個集群的拓撲結構。

1. 給rados_create()使用的User ID和給rados_create2()使用的user name，其中後者更受推薦

2. Cephx authentication key

3. Monitor的ID和IP地址

4. 日誌級別

5. 調試級別

所以，從你的app使用集群的步驟如下：1. 創建一個cluster handle，它將被用來連接集群；2. 使用這個handle來連接集群。為了連接集群，這個app必須提供一個monitor地址，一個用戶名，還有一個authentication key。

java支持class集群模式嗎

支持。

Java具有多線程功能，可以實現class集群模式。

分佈式是指將不同的業務分佈在不同的地方， 而集群指的是將幾台服務器集中在一起，實現同一業務，分佈式中的每一個節點，都可以做集群， 而集群並不一定就是分佈式，分佈式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。

JAVA服務集群與非集群的區別？

集群肯定比非集群的處理能力強，但是你們集群不快可能是處理的瓶頸不在WEB到服務端的請求上，有可能是WEB端需要集群而不是服務端，更有可能是數據庫出現處理瓶頸而不是服務端。

要根據日誌分析和監控判斷好到底慢在哪裡。

一天才30000筆業務，對服務端程序來說簡直不值一提的

java 集群

群集方法介乎兩種計算機系統結構之間。當把多台計算機配置或互連在一起時，可採取鬆散耦合或緊密耦合結構。網絡就是一個鬆散耦合的系統，我們也稱其為異類系統結構。網絡把由各種CPU、應用軟件、NIC（網絡接口控制器）、甚至是操作系統組成的多台計算機連接在一起。計算機之間的地理距離可以近在咫尺，也可以遠在天邊。可以用實時和/或異步方式耦合網絡。

互聯網就是一個典型的極為鬆散與異類配置的例子。互聯網本身不能「實時」控制與它連接的任何主機。在鬆散耦合網絡中，單機崩潰一般不會影響網絡的其它部分。

相反，緊密耦合系統則高度依賴於構成系統的所有部件。當系統由相同部件組成，採用並行操作方式並共享所有子系統（存儲器）時，我們稱其為同類系統結構。緊密耦合系統最常見的例子是SMP（對稱多處理）。在SMP狀態下，根據工作量的多少把任務分給幾台處理器，這樣可均勻地分配工作量，以便提高數據吞吐量。

我們舉了兩個典型的鬆散和緊密耦合系統的例子，群集就介於鬆散和緊密耦合系統之間。根據系統的配置，在某些方面（比如操作系統），群集控制的系統也許更偏向緊密耦合的系統，或者偏向鬆散耦合的系統（比如獨立計算能力，通過公共存儲器連接）。

通常群集器放在同一設備區或同一辦公樓里。從理論上說，群集控制方法可應用於閉路廣域網環境中（現正在美國東北部地區進行試驗）。可是在考慮到視頻服務器應用時，一般來說只能把設備放在主要設施運行所在地。

公共數據共享

群集允許共享幾個節點的數據。在此應用中，這些節點包括客戶工作站、中央或多服務器。我們知道可以通過許多路徑（比如星形結構）連接節點，客戶可通過不同連接的節點路徑存取數據。當節點就是服務器時便可共享公共存儲器，某個服務器節點故障不會導致整個群集器系統癱瘓。

在12月專欄里，我們把群集描述成一個提供高可得性的系統。對廣播或有線電視操作來說，視頻服務器必須要提供連續的或高可得性的數據。考慮到這一點，我們認為視頻服務器體系結構採用群集是大有潛力的。

待命或無源服務器結構就是一種群集形式。在這種結構下，一個或多個服務器（或節點）平時保持在待命狀態，隨時可以啟動。利用後台控制系統管理待命服務器內容數據。在未發生故障之前一般不啟用無源服務器。

無源服務器未必就是主服務器的完全鏡像，它也可以有一些有限的數據源，包括存儲器，要經常清除這些數據，然後重新裝入最新的節目或廣告。通過這一循環過程把適量的數據（或視頻媒介）保持在待命狀態，在需要時隨時可以上線使用。

服務器在待命狀態時通常由少量的部件組成，比如編解碼器，在出現故障或另一個服務器需要它支持的時候，該服務器可立即被集成到系統中應用。此時，服務器進入負載均衡狀態。

數據共享

數據共享是群集器需要提供的最基本功能之一。我們還是以視頻服務器的應用為例，多個編輯站在這裡獨立地工作，不過利用一組公共服務器來管理數據和應用層的處理。

在這個例子中，多個新聞編輯站（或客戶工作站）可以選擇用哪個編輯服務器（包括編輯用的軟件和硬件）來進行編輯。這些服務器控制對公共媒體數據庫的存取，編輯站只是這些服務器的簡單控制器GUI（圖形用戶界面）。編輯服務器進一步控制接入另一個更大的數據存儲庫（通常是新聞檔案）。

這個概念可通過群集軟件實現。在獨立的編輯站通過群集器存取數據的過程中，編輯與數據存取或存儲處理自動進行，不會影響其它的客戶編輯站或預放站。通過提供連續的數據可得性，每個服務器可以是有源的，也可以是無源的，視工作負荷而定。假如有一個服務器發生了故障，該結構也可提供冗餘或保護方式。

共享一個操作系統和平台是群集的又一個共同特點。讓硬件與軟件平台同屬一類，也就是說，基本上是相同的，就可採用公用互連方案與公共文件格式結構。在SMP這樣的系統中，所有部件都依賴於公用硬件而像單獨部件一樣運行。正如我們已提到的，群集可以讓一部分系統保持同類結構，但脫離所有系統都有的依賴性，其它性能就會下降。

其它優點

我們現在還是回到基於群集服務器的編輯環境中來，我們又發現了其它一些優點。服務器硬件具有的冗餘性可對數據起保護作用。在新聞編輯環境中，當即將播放時，一個或更多的服務器便可將客戶工作站的功能變成播出功能，直接把新聞播出去。這樣還能讓所有客戶和服務器接入別的服務器的數據，包括在最後一分鐘直接存取中央存儲庫的數據。

通過使用多個服務器（每個服務器收集、編輯、存檔和重放的資源是一個類型的），系統便可對硬件進行備份。在某個服務器出現故障時，可把資源轉給或分給其它用戶，系統的其餘部分仍繼續工作。

除了上述的數據共享外，其它群集器結構也是可行的。在有些情況下，某些資源可被一個特定的節點「擁有」，在未接到指令前不會放棄。可將該系統的結構配置成一個節點有多個輸入編碼器，但只有一個輸出解碼器。另一個節點可能沒有輸入，但有好幾個輸出供放像和預看用。如果某一個節點出現故障，可讓與它相對應的節點頂替它，直到它被修復為止。

非共享結構

從硬件上說，每個節點的能力（或資源）基本上相同，但內部系統配置是用各種形式鎖定的，除非另有要求。按照群集語言可把此結構

叫做非共享結構。在此結構里，某些資源在未被傳送給其它節點或者該節點未出故障之前歸一個節點所有。在採用非共享結構的計算機與模式里運用群集法通常會把硬盤等設備分配給一個節點，並阻止其他人使用它，除非將其開放或該節點發生故障。

群集結構的其它實施方面增加了系統的複雜程度。除了非共享結構外（只提供最簡單的性能和可得性），還有磁盤共享結構。磁盤共享可提高存儲接入不同主機系統的能力。

從硬件的角度看，系統的磁盤陣列控制器可以很容易地管理這個共享結構。比較難辦的是在最低級別（文件或記錄層）上協調更新數據。

協調工作必須成為群集軟件的一部分。可以設想一下，如果兩個用戶同時接入同一記錄層會發生什麼情況。假定每個用戶都修改了文件。用戶1先把數據寫入服務器，他發現用戶2做了完全不同的修改並且把修改後的文件用同一文件名存入相同的磁盤，或許存在另一個服務器上，這樣就有可能把第一個用戶修改的文件衝掉。沒有一個控制方案，就會亂成一團。

儘管每個文件或記錄層都有簡單的口令或鎖定保護，但要確保用文件的正確版本存成另一個文件名或是「正式」版，則要求具有更高層的數據控制與管理能力。磁盤快速緩存問題又是另一種情形，我們等一會兒再說。

另一個防止錯誤數據覆蓋正確數據的方法是在修改未最後定之前限制接入某一特定文件。在計算機數據域中，用一個稱為信息傳送的程序通知管理員（通常是應用後台軟件的一部分）文件存取被鎖定，直到修改程序結束為止。

原子操作

原子操作的三個步驟是：讀數據、修改數據、然後重新寫入新數據。在原子操作過程中，在未執行完操作之前不會受到任何干擾。還必須有其他保護措施，以防隱藏的備份文件在以後某個無法預測的時間改寫其它的文件。

當數據分佈在不止一個存儲磁盤上時，或者當公共存儲陣列中的數據被不同用戶在不同時間存取時，如何防止數據不一致是群集軟件需要解決的又一個問題。無論是通過硅緩存器還是通過遠程接入的臨時磁盤緩存器（甚至分區）進行高速緩存都會遇到定時和同步的問題。我們把這個問題叫做緩存相關性，它是因磁盤驅動器定時問題引起的。

磁盤驅動器並不一定能馬上寫入數據，磁頭也許定位在錯誤的磁道上，導輪也許偏離相位190度，等結束運轉後才能開始磁頭的寫入操作，或許還因為溫度問題造成暫時性延緩，直到一切都符合條件為止。

這通常被稱為等待時間，磁盤驅動器的機械部分要求在驅動器等待寫入時暫存一下數據。最常見的方法是在驅動器上安一個硅緩存器，這個過程被叫做寫回高速緩存。在把主機儲存器中的數據轉存到磁盤驅動器的過程中，設一個寫回緩存器標識，對數據源表示寫入程序成功了。實際上，得過一會兒才能開始真正的電磁機械式的數據儲存過程。

假如系統上的另一個節點也從這個驅動器讀數據，（這是經過許可的操作，因為數據發生器已接到通知，新數據已發送到了這個位置），那麼緩存器已在指定位置存儲了正確新數據的指示信號就不見了。我們用失效數據一詞來表示未更新數據進入新數據區的狀態。

無效數據

RAID控制器在各自磁盤陣列的寫回緩存器里為與這個特殊的陣列有關的磁盤管理失效數據。假如在軟件里設一些適當的開關來檢測和阻止它發生，那麼數據相關性就只是一個小問題了。

當系統是由多層陣列構成的時候，控制失效數據問題的任務就交給高級別軟件去完成，把信號傳送給各自的陣列，就不會發生孤立或失效數據問題了。

在這個簡化的單一視頻服務器模型里，媒體是通過單編碼器輸入的，並存在一個單實體陣列上。由一個更高級別（通常是第三方API，應用程序接口）登記和管理活動圖像數據。通常將其作為任選的「媒體管理」或「資產管理器」包出售。通過這個軟件，控制活動圖像和數據的過程成為一個閉路過程，因為輸入與輸出指令必須通過這個管理軟件包。該軟件在自己的數據庫里始終跟蹤着數據的有效性。

如果有好幾個服務器，每個服務器有自己的任務，情況就變得比較複雜了。這時可以讓幾個信號源的輸入進入不同的編碼器，並存在一個較大的磁盤陣列里。這些陣列通常與光纖通道仲裁環相連，由於它的連接方式決定，它可迫使部分重寫動作由服務器推遲到存儲器，直到有了充足的帶寬來把該數據從這個存儲器存入另一個存儲器。

在類似的應用中，媒體管理軟件就更完善，更必不可少了。有時候製造商會提供一個完全獨立的CPU和資源管理軟件包（作為選件）。這個軟件包就像看門狗那樣管理服務器之間的數據共享操作。除了這些基本概念外，還有大量的定時和數據驗證問題，這些問題會經常在服務器結構的軟件與子系統中碰到。

群集的過程和功能正在擴展到設備內和設備間應用中。群集器理念最終將允許整個廣播集團通過光纖或通過廣域網共享資源。雖然可以讓設施連成網共享媒介，可是在這些設施相互離得很遠的情況下實現節點資源共享的設想似乎還很遙遠。