java分布式,JAVA分布式存儲

本文目錄一覽：

• 1、北大青鳥java培訓：IT編程開發分布式系統都存在哪些不足之處？
• 2、java分布式架構有哪些技術
• 3、java的分布式開發怎麼實現後台模塊之間的數據交互
• 4、java支持分布式和什麼？
• 5、java的某些項目為什麼要採用分布式開發？什麼是分布式開發？

北大青鳥java培訓：IT編程開發分布式系統都存在哪些不足之處？

分布式編程開發系統相信大家應該不陌生了吧。

而關於分布式的缺陷或者說問題大家是否有去研究呢?今天我們就一起來了解一下，關於分布式系統中存在的幾個問題吧。

網絡並不是可靠的你應該明白，分布式系統中不同節點間的通信是基於網絡的。

網絡使得它們連接起來共同協作。

然而，光纜被挖斷的事件相信你也看到過不是一兩次了。

除此之外，網卡異常、交換機故障、遭受惡意攻擊等導致的網絡擁塞、網絡中斷、報文丟失的種種跡象皆意味着網絡隨時可能無法正常運作，是不可靠的。

此時，需要在你的系統設計中，儘可能地考慮到：當前節點所依賴的其他節點由於各種原因無法與之正常通信時，該如何保證其依然能夠提供部分或者完整的服務。

這個概念在軟件域被定義為“魯棒性”。

不同節點之間的通信是存在延遲的網絡連接的是處於不同物理位置上的節點，學過物理和數學你的應該明白，兩點之間是存在“距離”的，而我們的分布式系統需要在這個距離之上進行數據的傳遞，本質上就是物質的傳遞。

同時應該你也知道，物質的運動速度不會超過光速。

所以，不同節點之間的通信是需要經過一段時間的，也就意味着會存在延遲。

具體的延遲是由所用的傳輸介質、節點當前的負載大小所決定的。

帶寬是有上限的這個點，我相信你是知道的，因為當你通過QQ、釘釘之類的工具傳輸或者下載一個大文件時候，就發現它是存在上限的，這個上限是根據你的網絡帶寬大小決定的。

但是，為什麼你還是有可能會掉入這個陷阱里呢?電腦培訓發現這往往由於你對所傳輸的數據的大小和頻率沒有充分的認識，導致了你覺得達到上限是一個很久遠的事情，不用考慮它。

分布式並不直接意味着是“敏捷”了可能你曾經有過這樣的想法，當在規模較大的集中式系統中工作的時候，每次和許多人在一個代碼庫里提交代碼，老是遇到衝突、排隊等待上游模塊先開發等等。

這時你會想，如果改造成分布式系統，這些問題都沒了，工作效率高多了。

java分布式架構有哪些技術

既然是分布式系統，系統間通信的技術就不可避免的要掌握。

首先，我們必須掌握一些基本知識，例如網絡通信協議（例如TCP / UDP等），網絡IO（Blocking-IO，NonBlocking-IO，Asyn-IO），網卡（多隊列等）。   了解有關連接重用，序列化/反序列化，RPC，負載平衡等的信息。

在學習了這些基本知識之後，您基本上可以在分布式系統中編寫一個簡單的通信模塊，但這實際上還遠遠不夠。 現在，您已經進入了分布式字段，您已經對規模有很多要求。 這意味着需要一種通信程序，該程序可以支持大量連接，高並發性和低資源消耗。

大量的連接通常會有兩種方式：

大量client連一個server

當前在NonBlocking-IO非常成熟的情況下，支持大量客戶端的服務器並不難編寫，但是在大規模且通常是長連接的情況下，有一點需要特別注意 ，即服務器掛起時不可能所有客戶端都在某個時間點啟動重新連接。 那基本上是一場災難。 我見過一些沒有經驗的類似案例。 客戶端規模擴大後，服務器基本上會在重新啟動後立即刷新。 大量傳入連接中斷（當然，服務器的積壓隊列首先應設置為稍大一些）。 可以使用的通常方法是在客戶端重新連接之前睡眠一段隨機的時間。 另外，重連間隔採用避讓算法。

一個client連大量的server

有些場景也會出現需要連大量server的現象，在這種情況下，同樣要注意的也是不要並發同時去建所有的連接，而是在能力範圍內分批去建。

除了建連接外，另外還要注意的地方是並發發送請求也同樣，一定要做好限流，否則很容易會因為一些點慢導致內存爆掉。

這些問題在技術風險上得考慮進去，並在設計和代碼實現上體現，否則一旦隨着規模上去了，問題一時半會還真不太好解。

高並發這個點需要掌握CAS、常見的lock-free算法、讀寫鎖、線程相關知識（例如線程交互、線程池）等，通信層面的高並發在NonBlocking-IO的情況下，最重要的是要注意在整體設計和代碼實現上盡量減少對io線程池的時間佔用。

低資源消耗這點的話NonBlocking-IO本身基本已經做到。

伸縮性

分布式系統基本上意味着規模不小。 對於此類系統，在設計時必須考慮可伸縮性。 在體系結構圖上繪製的任何點，如果請求量或數據量繼續增加，該怎麼辦？ 通過添加機器來解決。 當然，此過程不需要考慮無限的情況。 如果您有經驗的建築師，從相對較小的規模到非常大型的範圍，那麼優勢顯然並不小，而且它們也將越來越稀缺。  。

橫向可擴展性（Scale Out）是指通過增加服務器數量來提高群集的整體性能。 垂直可伸縮性（Scale Up）是指提高每台服務器的性能以提高集群的整體性能。 縱向可擴展性的上限非常明顯，而分布式系統則強調水平可伸縮性。

分布式系統應用服務最好做成無狀態的

應用服務的狀態是指運行時程序因為處理服務請求而存在內存的數據。分布式應用服務最好是設計成無狀態。因為如果應用程序是有狀態的，那麼一旦服務器宕機就會使得應用服務程序受影響而掛掉，那存在內存的數據也就丟失了，這顯然不是高可靠的服務。把應用服務設計成無狀態的，讓程序把需要保存的數據都保存在專門的存儲上(eg. 數據庫)，這樣應用服務程序可以任意重啟而不丟失數據，方便分布式系統在服務器宕機後恢復應用服務。

伸縮性的問題圍繞着以下兩種場景在解決：

無狀態場景

對於無狀態場景，要實現隨量增長而加機器支撐會比較簡單，這種情況下只用解決節點發現的問題，通常只要基於負載均衡就可以搞定，硬件或軟件方式都有；

無狀態場景通常會把很多狀態放在db，當量到一定階段後會需要引入服務化，去緩解對db連接數太多的情況。

有狀態場景

所謂狀態其實就是數據，通常採用Sharding來實現伸縮性，Sharding有多種的實現方式，常見的有這麼一些：

2.1 規則Sharding

基於一定規則把狀態數據進行Sharding，例如分庫分表很多時候採用的就是這樣的，這種方式支持了伸縮性，但通常也帶來了很複雜的管理、狀態數據搬遷，甚至業務功能很難實現的問題，例如全局join，跨表事務等。

2.2 一致性Hash

一致性Hash方案會使得加機器代價更低一些，另外就是壓力可以更為均衡，例如分布式cache經常採用，和規則Sharding帶來的問題基本一樣。

2.3 Auto Sharding

Auto Sharding的好處是基本上不用管數據搬遷，而且隨着量上漲加機器就OK，但通常Auto Sharding的情況下對如何使用會有比較高的要求，而這個通常也就會造成一些限制，這種方案例如HBase。

2.4 Copy

Copy這種常見於讀遠多於寫的情況，實現起來又會有最終一致的方案和全局一致的方案，最終一致的多數可通過消息機制等，全局一致的例如zookeeper/etcd之類的，既要全局一致又要做到很高的寫支撐能力就很難實現了。

即使發展到今天，Sharding方式下的伸縮性問題仍然是很大的挑戰，非常不好做。

上面所寫的基本都還只是解決的方向，到細節點基本就很容易判斷是一個解決過多大規模場景問題的架構師，:)

穩定性

作為分布式系統，必須要考慮清楚整個系統中任何一個點掛掉應該怎麼處理（到了一定機器規模，每天掛掉一些機器很正常），同樣主要還是分成了無狀態和有狀態：

無狀態場景

對於無狀態場景，通常好辦，只用節點發現的機制上具備心跳等檢測機制就OK，經驗上來說無非就是純粹靠4層的檢測對業務不太夠，通常得做成7層的，當然，做成7層的就得處理好規模大了後的問題。

有狀態場景

對於有狀態場景，就比較麻煩了，對數據一致性要求不高的還OK，主備類型的方案基本也可以用，當然，主備方案要做的很好也非常不容易，有各種各樣的方案，對於主備方案又覺得不太爽的情況下，例如HBase這樣的，就意味着掛掉一台，另外一台接管的話是需要一定時間的，這個對可用性還是有一定影響的；

全局一致類型的場景中，如果一台掛了，就通常意味着得有選舉機制來決定其他機器哪台成為主，常見的例如基於paxos的實現。

可維護性

維護性是很容易被遺漏的部分，但對分布式系統來說其實是很重要的部分，例如整個系統環境應該怎麼搭建，部署，配套的維護工具、監控點、報警點、問題定位、問題處理策略等等。

java的分布式開發怎麼實現後台模塊之間的數據交互

1、使用表單發送同步請求，實現數據交互。參數inputStr，參數intputlnt。

2、jave分布式開發採用服務端後台進行實現接收模塊之間的數據交互，點擊服務器端來交換，點擊確認即可。

java支持分布式和什麼？

Java設計成支持在網絡上應用，它是分布式語言。Java既支持各種層次的網絡連接，又以Socket類支持可靠的流（stream）網絡連接，所以用戶可以產生分布式的客戶機和服務器

java的某些項目為什麼要採用分布式開發？什麼是分布式開發？

java的某些項目為什麼要採用分布式開發，分布式開發

在數據庫應用程序的開發過程中，網絡已走到社會的各個角落。從金融行業的銀行聯網、交通行業的售票系統、公安系統的全國戶籍管理等等，這些企業或行業單位之間地理分布性或業務分布性，使得一個企業或行業擁有多個網絡服務器，如何在這種分布式的網絡環境下實現高效的數據庫應用程序的開發是一個重要的問題。

分布式應用開發簡單的說，是指將用戶界面、控制台服務、數據庫管理三個層次部署在不同的位置上。其中用戶界面是客戶端實現的功能，控制台服務是一個專門的服務器，數據管理是在一個專門的數據庫服務器上實現的。

提示：這裡的Web服務器，都是指軟件（如IIS等Web服務器軟件），它和Web服務器應用以及其它程序等，共同存在於服務器計算機上。

控制台CGI應用：是一個獨立的控制台EXE。它在一個標準輸入設備上接收客戶端的請求信息，在標準輸出設備上將結果返回給服務器。

分布式數據庫系統已經成為信息處理學科的重要領域，正在迅速發展之中，原因是什麼？

1、它可以解決組織機構分散而數據需要相互聯繫的問題。比如銀行系統，總行與各分行處於不同的城市或城市中的各個地區，在業務上它們需要處理各自的數據，也需要彼此之間的交換和處理，這就需要分布式的系統。

2、如果一個組織機構需要增加新的相對自主的組織單位來擴充機構，則分布式數據庫系統可以在對當前機構影響最小的情況下進行擴充。

3、均衡負載的需要。數據的分解採用使局部應用達到最大，這使得各處理機之間的相互干擾降到最低。負載在各處理機之間分擔，可以避免臨界瓶頸。

4、當現有機構中已存在幾個數據庫系統，而且實現全局應用的必要性增加時，就可以由這些數據庫自下而上構成分布式數據庫系統。

5、相等規模的分布式數據庫系統在出現故障的幾率上不會比集中式數據庫系統低，但由於其故障的影響僅限於局部數據應用，因此就整個系統來講它的可靠性是比較高的。