㈠ 分布式技術介紹
2.一致性模型
弱一致性
最終一致性（一段時間達到一致性）
強一致
1、2 非同步冗餘；3是同步冗餘
數據分區： uid % 16
數據鏡像：讓多有的伺服器都有相同的數據，提供相當的服務（冗餘存儲，一般3份為好）
4.兩種方案的事務問題
A向B匯錢，兩個用戶不在一個伺服器上
鏡像：在不同的伺服器上對同一數據的寫操作如何保證一致性。
5. 解決一致性事務問題的技術
1. Master -Slave
讀寫請求由Master負責
寫請求寫到Master後，由Master同步到Slave上
由Master push or Slave pull
通常是由Slave 周期性來pull，所以是最終一致性
問題： 若在 pull 周期內（不是期間？），master掛掉，那麼會導致這個時間片內的數據丟失
若不想讓數據丟掉，Slave 只能成為 ReadOnly方式等Master恢復
若容忍數據丟失，可以讓 Slave代替Master工作
如何保證強一致性？
Master 寫操作，寫完成功後，再寫 Slave，兩者成功後返回成功。若 Slave失敗，兩種方法
標記 Slave 不可用報錯，並繼續服務（等恢復後，再同步Master的數據，多個Slave少了一個而已）
回滾自己並返回失敗
2. Master-Master
數據同步一般是通過 Master 間的非同步完成，所以是最終一致
好處： 一台Master掛掉，另外一台照樣可以提供讀寫服務。當數據沒有被賦值到別的Master上時，數據會丟失。
對同一數據的處理問題：Dynamo的Vector Clock的設計（記錄數據的版本號和修改者），當數據發生沖突時，要開發者自己來處理
3.兩階段提交 Two Phase Commit _ 2PC
第一階段：針對准備工作
協調者問所有節點是否可以執行提交
參與者開始事務，執行准備工作：鎖定資源（獲取鎖操作）
參與者響應協調者，如果事務的准備工作成功，則回應"可以提交"，否則，拒絕提交
第二階段：
若都響應可以提交，則協調者項多有參與者發送正式提交的命令（更新值），參與者完成正式提交，釋放資源，回應完成。協調者收到所有節點的完成響應後結束這個全局事務.。若參與者回應拒絕提交，則協調者向所有的參與者發送回滾操作，並釋放資源，當收到全部節點的回滾回應後，取消全局事務
存在的問題：若一個沒提交，就會進行回滾
第一階段：若消息的傳遞未接收到，則需要協調者作超時處理，要麼當做失敗，要麼重載
第二階段：若參與者的回應超時，要麼重試，要麼把那個參與者即為問題節點，提出整個集群
在第二階段中，參與者未收到協調者的指示（也許協調者掛掉），則所有參與者會進入「不知所措」 的狀態（但是已經鎖定了資源），所以引入了三段提交
4. 三段提交：把二段提交的第一階段 break 成了兩段
詢問
鎖定資源（獲取鎖）
提交
核心理念：在詢問的時候並不鎖定資源，除非所有人都同意了，才開始鎖定
好處：當發生了失敗或超時時，三段提交可以繼續把狀態變為Commit 狀態，而二段提交則不知所措？
5. Raxos 演算法（少數服從多數）
解決的問題：在一個可能發生異常的分布式系統中如何就某個值達成一致，讓整個集群的節點對某個值的變更達成一致
任何一個節點都可以提出要修改 某個 數據的提案,是否通過這個提案取決於這個集群中是否有超過半數的節點同意（所以節點數總是單數）—— 版本標記。雖然一致性，但是只能對一個操作進行操作啊？？
當一個Server接收到比當前版本號小的提案時，則拒絕。當收到比當前大的版本號的提案時，則鎖定資源，進行修改，返回OK. 也就是說收到超過一半的最大版本的提案才算成功。
核心思想 ：
在搶占式訪問權的基礎上引入多個acceptor，也就是說當一個版本號更大的提案可以剝奪版本號已經獲取的鎖。
後者認同前者的原則：
在肯定舊epoch 無法生成確定性取值時，新的 epoch 會提交自己的valu
一旦 舊epoch形成確定性取值，新的 epoch肯定可以獲取到此取值，並且會認同此取值，不會被破壞。
步驟
P1 請求Acceptor的 #1,Acceptor 這時並沒有其他線程獲取到鎖，所以把鎖交給 P1，並返回這時 #1 的值為null
然後 P1 向 第一個 Acceptor 提交 #1 的值，Acceptor 接受並返回 OK
這個時候，P2向Acceptor請求#1上的鎖，因為版本號更大，所以直接搶佔了 P1 的鎖。這時 Acceptor 返回了 OK並且返回了 #1 的值
這時 P1 P向 後面兩個 Acceptor 提交 #1 的值，但是由於中間的那個Acceptor 版本號已經更改為 2 了，所以拒絕P1。第三個 Acceptor 接受了，並且返回了 OK
由於後者認同前者的原則，這時 P1 已經形成確定性取值了 V1 了，這時新的 P2 會認同此取值，而不是提交自己的取值。所以，P2會選擇最新的那個取值 也就是V1 進行提交。這時Acceptor 返回 OK
6.ZAB 協議 ( Zookeeper Atomic Broadcast) 原子廣播協議：保證了發給各副本的消息順序相同
定義 ：原子廣播協議 ZAB 是一致性協議，Zookeeper 把其作為數據一致性的演算法。ZAB 是在 Paxos 演算法基礎上進行擴展而來的。Zookeeper 使用單一主進程 Leader用於處理客戶端所有事務請求，採用 ZAB 協議將伺服器狀態以事務形式廣播到所有 Follower 上，由於事務間可能存在著依賴關系，ZAB協議保證 Leader 廣播的變更序列被順序的處理，一個狀態被處理那麼它所依賴的狀態也已經提前被處理
核心思想： 保證任意時刻只有一個節點是Leader，所有更新事務由Leader發起去更新所有副本 Follower，更新時用的是 兩段提交協議，只要多數節點 prepare 成功，就通知他們commit。各個follower 要按當初 leader 讓他們 prepare 的順序來 apply 事務
協議狀態
Looking:系統剛啟動時 或者 Leader 崩潰後正處於選舉狀態
Following：Follower 節點所處的狀態，Follower與 Leader處於數據同步狀態
Leading：Leader 所處狀態，當前集群中有一個 Leader 為主進程
ZooKeeper啟動時所有節點初始狀態為Looking，這時集群會嘗試選舉出一個Leader節點，選舉出的Leader節點切換為Leading狀態；當節點發現集群中已經選舉出Leader則該節點會切換到Following狀態，然後和Leader節點保持同步；當Follower節點與Leader失去聯系時Follower節點則會切換到Looking狀態，開始新一輪選舉；在ZooKeeper的整個生命周期中每個節點都會在Looking、Following、Leading狀態間不斷轉換。
選舉出Leader節點後 ZAB 進入原子廣播階段，這時Leader為和自己同步每個節點 Follower 創建一個操作序列，一個時期一個 Follower 只能和一個Leader保持同步
階段
Election： 在 Looking狀態中選舉出 Leader節點，Leader的LastZXID總是最新的（只有lastZXID的節點才有資格成為Leade,這種情況下選舉出來的Leader總有最新的事務日誌）。在選舉的過程中會對每個Follower節點的ZXID進行對比只有highestZXID的Follower才可能當選Leader
每個Follower都向其他節點發送選自身為Leader的Vote投票請求，等待回復；
Follower接受到的Vote如果比自身的大（ZXID更新）時則投票，並更新自身的Vote，否則拒絕投票；
每個Follower中維護著一個投票記錄表，當某個節點收到過半的投票時，結束投票並把該Follower選為Leader，投票結束；
Discovery:Follower 節點向准 Leader推送 FollwerInfo,該信息包含了上一周期的epoch，接受准 Leader 的 NEWLEADER 指令
Sync：將 Follower 與 Leader的數據進行同步，由Leader發起同步指令，最終保持數據的一致性
Broadcast：Leader廣播 Proposal 與 Commit，Follower 接受 Proposal 與 commit。因為一個時刻只有一個Leader節點，若是更新請求，只能由Leader節點執行（若連到的是 Follower 節點，則需轉發到Leader節點執行；讀請求可以從Follower 上讀取，若是要最新的數據，則還是需要在 Leader上讀取）
消息廣播使用了TCP協議進行通訊所有保證了接受和發送事務的順序性。廣播消息時Leader節點為每個事務Proposal分配一個全局遞增的ZXID（事務ID），每個事務Proposal都按照ZXID順序來處理（Paxos 保證不了）
Leader節點為每一個Follower節點分配一個隊列按事務ZXID順序放入到隊列中，且根據隊列的規則FIFO來進行事務的發送。
Recovery ：根據Leader的事務日誌對Follower 節點數據進行同步更新
同步策略：
SNAP ：如果Follower數據太老，Leader將發送快照SNAP指令給Follower同步數據；
DIFF ：Leader發送從Follolwer.lastZXID到Leader.lastZXID議案的DIFF指令給Follower同步數據；
TRUNC ：當Follower.lastZXID比Leader.lastZXID大時，Leader發送從Leader.lastZXID到Follower.lastZXID的TRUNC指令讓Follower丟棄該段數據；（當老Leader在Commit前掛掉，但是已提交到本地）
Follower將所有事務都同步完成後Leader會把該節點添加到可用Follower列表中；
Follower接收Leader的NEWLEADER指令，如果該指令中epoch比當前Follower的epoch小那麼Follower轉到Election階段
7. Raft 演算法
Raft 演算法也是一種少數服從多數的演算法，在任何時候一個伺服器可以扮演以下角色之一：
Leader：負責 Client 交互 和 log 復制，同一時刻系統中最多存在一個
Follower：被動響應請求 RPC，從不主動發起請求 RPC
Candidate : 由Follower 向Leader轉換的中間狀態
在選舉Leader的過程中，是有時間限制的，raft 將時間分為一個個 Term，可以認為是「邏輯時間」：
每個 Term中至多存在1個 Leader
某些 Term由於不止一個得到的票數一樣，就會選舉失敗，不存在Leader。則會出現 Split Vote ，再由候選者發出邀票
每個 Server 本地維護 currentTerm
選舉過程：
自增 CurrentTerm，由Follower 轉換為 Candidate，設置 votedFor 為自身，並行發起 RequestVote RPC,不斷重試，直至滿足下列條件之一為止：
獲得超過半數的Server的投票，轉換為 Leader，廣播 HeatBeat
接收到 合法 Leader 的 AppendEnties RPC，轉換為Follower
選舉超時，沒有 Server選舉成功，自增 currentTerm ,重新選舉
當Candidate 在等待投票結果的過程中，可能會接收到來自其他Leader的 AppendEntries RPC ,如果該 Leader 的 Term 不小於本地的 Current Term，則認可該Leader身份的合法性，主動降級為Follower，反之，則維持 candida 身份繼續等待投票結果
Candidate 既沒有選舉成功，也沒有收到其他 Leader 的 RPC (多個節點同時發起選舉，最終每個 Candidate都將超時)，為了減少沖突，採取隨機退讓策略，每個 Candidate 重啟選舉定時器
日誌更新問題：
如果在日誌復制過程中，發生了網路分區或者網路通信故障，使得Leader不能訪問大多數Follwers了，那麼Leader只能正常更新它能訪問的那些Follower伺服器，而大多數的伺服器Follower因為沒有了Leader，他們重新選舉一個候選者作為Leader，然後這個Leader作為代表於外界打交道，如果外界要求其添加新的日誌，這個新的Leader就按上述步驟通知大多數Followers，如果這時網路故障修復了，那麼原先的Leader就變成Follower，在失聯階段這個老Leader的任何更新都不能算commit，都回滾，接受新的Leader的新的更新。
流程：
Client 發送command 命令給 Leader
Leader追加日誌項，等待 commit 更新本地狀態機，最終響應 Client
若 Client超時，則不斷重試，直到收到響應為止（重發 command，可能被執行多次，在被執行但是由於網路通信問題未收到響應）
解決辦法：Client 賦予每個 Command唯一標識，Leader在接收 command 之前首先檢查本地log
9. paxos 演算法與 raft 演算法的差異
raft強調是唯一leader的協議，此leader至高無上
raft：新選舉出來的leader擁有全部提交的日誌，而 paxos 需要額外的流程從其他節點獲取已經被提交的日誌，它允許日誌有空洞
相同點：得到大多數的贊成，這個 entries 就會定下來，最終所有節點都會贊成
NWR模型
N： N個備份
W：要寫入至少 w 份才認為成功
R : 至少讀取 R 個備份
W+ R > N ——> R > N - W(未更新成功的) ，代表每次讀取，都至少讀取到一個最新的版本（更新成功的），從而不會讀到一份舊數據
問題：並非強一致性，會出現一些節點上的數據並不是最新版本，但卻進行了最新的操作
版本沖突問題：矢量鍾 Vector Clock ： 誰更新的我，我的版本號是什麼（對於同一個操作者的同一操作，版本號遞增）
㈡ 什麼是分布式計算機網路
在這種網路中，不存在一個處理和控制中心，網路中任一結點都至少和另外兩個結點相連接，信息從一個結點到達另一結點時，可能有多條路徑。同時，網路中各個結點均以平等地位相互協調工作和交換信息，並可共同完成一個大型任務。分組交換網、網狀形網屬於分布式網路。這種網具有信息處理的分布性、可靠性、可擴充性及靈活性等一系列優點。因此，它是網路發展的方向。 分布式系統的平台已經成為一個鏈接某個組織的各個工作組、部門、分支機構和各個分部的企業網路。數據不是在一台伺服器上，而是在許多台伺服器上；這些伺服器可能位於多個不同的地理區域，並用WAN鏈路相連接。 圖D-26說明了從昂貴的集中式系統向可大批量安裝的低成本的分布式系統發展的趨勢。在20世紀80年代末、90年代初，分布式系統由數量龐大的桌面計算機組成，而如今，網際網路和Web技術已經大大擴展了分布式系統的概念。根據3Com論文的說法，Web是一個「大規模分布的系統集合」，它由數不勝數的節點組成，這些節點范圍從伺服器到攜帶型計算機和無線PDA，更不用說那些無需人工干預基本上就能夠彼此對話的嵌入式系統了。 TCP/IP提供了一個網路無關的傳輸層。 Web客戶機和伺服器消除了對平台和操作系統的依賴性。 組件軟體(Java、ActiveX)消除了與購買和安裝軟體相關的爭論。 XML使數據獨立於軟體。 用Web技術構建的網路(如內聯網和網際網路)是真正的高級分布式計算網路。Web技術為分布式計算添加了一個新的維度。Web伺服器為具有Web瀏覽器的任何一台客戶機提供了通用的訪問方法。計算平台和操作系統的類型變得無關緊要，而無限制的通信和信息交換卻占據了主導地位。 最近的分布式計算項目已經被用於使用世界各地成千上萬位志願者的計算機的閑置計算能力，通過網際網路，您可以分析來自外太空的電訊號，尋找隱蔽的黑洞，並探索可能存在的外星智慧生命；您可以尋找超過1000萬位數字的梅森質數；您也可以尋找並發現對抗艾滋病病毒的更為有效的葯物。這些項目都很龐大，需要驚人的計算量，僅僅由單個的電腦或是個人在一個能讓人接受的時間內計算完成是決不可能的。 分布式環境具有一些很有趣的特徵。它利用了客戶機/伺服器計算技術和多層體系結構。它可將處理工作分布在多個不很昂貴的系統上，從而減輕了伺服器處理許多任務的工作量。數據可以通過有線或無線網路從許多不同的站點上進行訪問。可以將數據復制到其他系統以提供容錯功能，並使其更接近於用戶。對數據進行分布可以使數據免遭本地災害的破壞。 分布式環境需要下列組件： 支持多供應商產品和通信協議的網路平台。TCP/IP成為實際使用的標准協議。 用於在客戶機和伺服器之間交換信息的應用程序介面，如RPC(遠程過程調用)、消息傳遞系統或Web協議。 用來跟蹤資源和信息及其所處位置的目錄命名服務。 可支持分區和復制以便對數據進行分布並確保數據的可用性、可靠性和保護的文件系統和資料庫。 用於使信息更接近於用戶並使通過遠距離鏈路傳輸信息所需時間最小化的高速緩存方案。 安全功能(如身份驗證和授權)以及不同位置的系統之間的信任關系。 如前所述，Web是最基本的分布式計算機系統。您可以訪問全世界的Web伺服器，這些伺服器提供了近乎無限的豐富內容。您可以利用目錄服務來查找站點。搜索引擎對整個Web上的信息進行分類，並使您可以對其進行查詢。高速緩存技術和「內容分布」正在使信息與用戶的距離越來越近。 大規模分布系統 3Com有一篇論文，名為「Massively Distributed Systems」，是由Dan Nessett撰寫的。該論文談到了從高成本的集中式系統向低成本分布式的高單元容量的產品發展的趨勢，向大規模分布的系統發展的趨勢，這些大規模分布系統無處不在並且其運行常常超出人們的正常的知識范圍。對於那些想了解分布式計算發展趨勢的人們，建議最好閱讀一下這篇論文。 Nessett探討了兩種分布式處理方法。一種方法是將數據移到邊緣處理器，正如Web和基於Web的文件系統那樣。另一種方法是先有處理過程再接收數據，正如活動聯網和Java應用小程序那樣(如對象在分布式系統中移動，同時攜帶代碼和數據)。如果對象主要包含數據，則它會更接近於再進行處理。如果對象主要包含代碼，則它更接近於先有處理過程再接收數據。然而，另一種方法是利用瘦客戶機，這種方法是用戶在與伺服器連接的圖形終端進行工作，這些伺服器執行所有處理工作並存儲用戶的數據。 萬維網是由歐洲粒子物理實驗室(CERN)研製的基於Internet的信息服務系統。WWW以超文本技術為基礎，用面向文件的閱覽方式替代通常的菜單的列表方式，提供具有一定格式的文本、圖形、聲音、動畫等。它是一個充滿著對象的大規模分布的系統，其中各個Web站點所包含的文檔都同時包含有對象和對其他對象的索引。 Nessett談到了要使大規模分布的對象呈現給缺乏技術的用戶為何需要新的介面。一個例子是在用戶可瀏覽的虛擬空間中表示這些對象，就好像在三維世界中漫遊一樣。 分布式和並行處理 分布式計算技術的一個方面是能夠在多台計算機上並行運行若干個程序。以分布式計算技術為基礎，基於構件的系統體系結構將逐漸取代模塊化的系統體系結構。現在主要有兩種分布式計算技術的標准，一個是以OMG組織為核心的CORBA標准，另一個是以微軟為代表的基於DCOM的ActiveX標准。近年來，OMG組織在CORBA 標準的制定和推廣方面付出了巨大的努力，同時許多CORBA標準的產品也在逐漸成熟和發展；同時由於微軟在操作系統方面的絕對統治地位，ActiveX標准在Windows系列平台上顯得更加實用，相應的工具也更加成熟。 分布式並行處理技術是最適合於在通過LAN或網際網路連接的計算機之間發生的多道處理技術；而專用並行處理則是最適合於在本地通過高速介面掛接的系統上發生的多道處理技術。 多個計算機系統間的分布式並行處理需要有一個權威性的調度程序，用來決定何時何地運行程序的一些部分。任務分布可以實時進行，也可以按比較緩和的任務安排來進行。例如，分布式處理已經在破譯加密消息上得以使用。Distributed.net項目就是僱用數千名用戶和他們的計算機來破譯密碼的。用戶收到一個小程序，該程序可與Distributed.net的主系統進行通信，該系統向用戶分布要解決的部分問題。當用戶的計算機空閑時該程序即會運行。然後在完成後將其結果返回給主計算機。最後，主計算機對所有計算機提交的全部結果進行編譯。Distributed.net宣稱，它的用戶網擁有「世界上最快的計算機」。 HTC(高吞吐量計算)環境是由許多工作站組成的大集合環境，通常稱之為「網格環境」。Globus項目就是一個HTC項目，它可以幫助科研人員利用工作站和超級計算機池中的空閑周期。
㈢ 網路經常掉線怎麼解決
1、根據您提供的信息，如果您是指寬頻頻繁掉線，影響您上網，建議可通過以下方式進行排障：
【1】如果有使用路由器則先斷開路由器單機撥號測試；
【2】如果有modem設備，則需要留意該設備是否過熱，可以關閉幾分鍾後再重啟試試；
【3】如果單獨運行程序時掉線（比如果玩游戲時掉線），建議重啟電腦嘗試或者重新安裝該程序；
【4】如果是整個網路掉線，請檢查接入線與網線是否松動或接觸不良，重新拔插線路嘗試；
【5】檢查過濾電腦病毒引起的斷線，全盤掃描；
【6】如果所運行程序有伺服器選擇，請選擇中國聯通。
2、如果經以上方式排障後，還是無法解決問題，建議您可聯系歸屬地聯通人工客服報障，我司將盡快為您核查處理。
同時您也可關注「中國聯通」微信公眾號，點擊「客戶服務＞寬頻報障＞常見故障指引「，查看對應故障的處理方式。
如仍無法解決，可通過以下方式自助報障：
【方式一】關注「中國聯通」微信公眾號，點擊「客戶服務＞寬頻報障＞在線報障」；
【方式二】登錄中國聯通手機營業廳APP，點擊「服務＞寬頻＞寬頻辦理服務＞寬頻報障」。
㈣ 分布式編程系統有哪些不足
對於學習編程語言來說，分布式編程開發系統是很多人比較熟悉的。但是分布式系統存在的缺陷和問題很多人都不了解，學習編程語言需要對分布式編程系統非常熟悉，分布式系統存在哪些不足呢？下面電腦培訓為大傢具體介紹分布式編程系統的不足之處。
一、網路不可靠
很多人都知道，分布式系統中的不同節點之間的通信是基於網路的。網路能夠很好的使他們結合在一起，但是如果光纜出現問題，也是非常頻繁的。此外，由網卡異常、交換機故障、惡意攻擊等引起的網路擁塞、網路中斷和數據包丟失所造成的網路擁塞、網路中斷和消息丟失，所以IT培訓發現網路在任何時候都可能無法正常運行，並且是非常不可靠的。
二、不同節點之前的通訊延遲
網路將不同物理位置的節點連接起來。在學習物理和數學之後，你就會了解很多這方面的知識。在兩個點之間，我們的分布式系統必須傳輸關於這個距離的數據，這基本上就是物質的傳輸。同時，北大青鳥昆明計算機學院認為你也要知道，重要性不會比光移動得更快。
三、寬頻的上限問題
關於寬頻問題相信很多人都非常熟悉，在使用聊天軟體的過程中，下載和傳輸文件會存在上限問題，這個上限是由網路寬頻決定的。但是很多人還是會進入這個陷阱中，因為很多人對傳輸數據的大小和頻率認識不充分，北大青鳥發現這就導致出現上限的問題，這是一個非常久遠的事情。
對於這些問題最重要的是對理論的認識，學習編程需要有充分的認識，並且認識到使用的環境，這樣對解決分布式編程系統問題有很大的幫助。
㈤ Java分布式系統處理分布式事務有哪些經典解決方
當我們在生產線上用一台伺服器來提供數據服務的時候，我會遇到如下的兩個問題：
1）一台伺服器的性能不足以提供足夠的能力服務於所有的網路請求。
2）我們總是害怕我們的這台伺服器停機，造成服務不可用或是數據丟失。
於是我們不得不對我們的伺服器進行擴展，加入更多的機器來分擔性能上的問題，以及來解決單點故障問題。 通常，我們會通過兩種手段來擴展我們的數據服務：
1）數據分區：就是把數據分塊放在不同的伺服器上（如：uid % 16，一致性哈希等）。
2）數據鏡像：讓所有的伺服器都有相同的數據，提供相當的服務。
對於第一種情況，我們無法解決數據丟失的問題，單台伺服器出問題時，會有部分數據丟失。所以，數據服務的高可用性只能通過第二種方法來完成——數據的冗餘存儲（一般工業界認為比較安全的備份數應該是3份，如：Hadoop和Dynamo）。 但是，加入更多的機器，會讓我們的數據服務變得很復雜，尤其是跨伺服器的事務處理，也就是跨伺服器的數據一致性。這個是一個很難的問題。 讓我們用最經典的Use Case：「A帳號向B帳號匯錢」來說明一下，熟悉RDBMS事務的都知道從帳號A到帳號B需要6個操作：
從A帳號中把余額讀出來。
對A帳號做減法操作。
把結果寫回A帳號中。
從B帳號中把余額讀出來。
對B帳號做加法操作。
把結果寫回B帳號中。
為了數據的一致性，這6件事，要麼都成功做完，要麼都不成功，而且這個操作的過程中，對A、B帳號的其它訪問必需鎖死，所謂鎖死就是要排除其它的讀寫操作，不然會有臟數據的問題，這就是事務。那麼，我們在加入了更多的機器後，這個事情會變得復雜起來：
1）在數據分區的方案中：如果A帳號和B帳號的數據不在同一台伺服器上怎麼辦？我們需要一個跨機器的事務處理。也就是說，如果A的扣錢成功了，但B的加錢不成功，我們還要把A的操作給回滾回去。這在跨機器的情況下，就變得比較復雜了。
2）在數據鏡像的方案中：A帳號和B帳號間的匯款是可以在一台機器上完成的，但是別忘了我們有多台機器存在A帳號和B帳號的副本。如果對A帳號的匯錢有兩個並發操作（要匯給B和C），這兩個操作發生在不同的兩台伺服器上怎麼辦？也就是說，在數據鏡像中，在不同的伺服器上對同一個數據的寫操作怎麼保證其一致性，保證數據不沖突？
同時，我們還要考慮性能的因素，如果不考慮性能的話，事務得到保證並不困難，系統慢一點就行了。除了考慮性能外，我們還要考慮可用性，也就是說，一台機器沒了，數據不丟失，服務可由別的機器繼續提供。 於是，我們需要重點考慮下面的這么幾個情況：
1）容災：數據不丟、節點的Failover
2）數據的一致性：事務處理
3）性能：吞吐量 、 響應時間
前面說過，要解決數據不丟，只能通過數據冗餘的方法，就算是數據分區，每個區也需要進行數據冗餘處理。這就是數據副本：當出現某個節點的數據丟失時可以從副本讀到，數據副本是分布式系統解決數據丟失異常的唯一手段。所以，在這篇文章中，簡單起見，我們只討論在數據冗餘情況下考慮數據的一致性和性能的問題。簡單說來：
1）要想讓數據有高可用性，就得寫多份數據。
2）寫多份的問題會導致數據一致性的問題。
3）數據一致性的問題又會引發性能問題
這就是軟體開發，按下了葫蘆起了瓢。
一致性模型
說起數據一致性來說，簡單說有三種類型（當然，如果細分的話，還有很多一致性模型，如：順序一致性，FIFO一致性，會話一致性，單讀一致性，單寫一致性，但為了本文的簡單易讀，我只說下面三種）：
1）Weak 弱一致性：當你寫入一個新值後，讀操作在數據副本上可能讀出來，也可能讀不出來。比如：某些cache系統，網路游戲其它玩家的數據和你沒什麼關系，VOIP這樣的系統，或是網路搜索引擎（呵呵）。
2）Eventually 最終一致性：當你寫入一個新值後，有可能讀不出來，但在某個時間窗口之後保證最終能讀出來。比如：DNS，電子郵件、Amazon S3，Google搜索引擎這樣的系統。
3）Strong 強一致性：新的數據一旦寫入，在任意副本任意時刻都能讀到新值。比如：文件系統，RDBMS，Azure Table都是強一致性的。
從這三種一致型的模型上來說，我們可以看到，Weak和Eventually一般來說是非同步冗餘的，而Strong一般來說是同步冗餘的，非同步的通常意味著更好的性能，但也意味著更復雜的狀態控制。同步意味著簡單，但也意味著性能下降。 好，讓我們由淺入深，一步一步地來看有哪些技術：
Master-Slave
首先是Master-Slave結構，對於這種加構，Slave一般是Master的備份。在這樣的系統中，一般是如下設計的：
1）讀寫請求都由Master負責。
2）寫請求寫到Master上後，由Master同步到Slave上。
從Master同步到Slave上，你可以使用非同步，也可以使用同步，可以使用Master來push，也可以使用Slave來pull。 通常來說是Slave來周期性的pull，所以，是最終一致性。這個設計的問題是，如果Master在pull周期內垮掉了，那麼會導致這個時間片內的數據丟失。如果你不想讓數據丟掉，Slave只能成為Read-Only的方式等Master恢復。
當然，如果你可以容忍數據丟掉的話，你可以馬上讓Slave代替Master工作（對於只負責計算的節點來說，沒有數據一致性和數據丟失的問題，Master-Slave的方式就可以解決單點問題了） 當然，Master Slave也可以是強一致性的， 比如：當我們寫Master的時候，Master負責先寫自己，等成功後，再寫Slave，兩者都成功後返回成功，整個過程是同步的，如果寫Slave失敗了，那麼兩種方法，一種是標記Slave不可用報錯並繼續服務（等Slave恢復後同步Master的數據，可以有多個Slave，這樣少一個，還有備份，就像前面說的寫三份那樣），另一種是回滾自己並返回寫失敗。（註：一般不先寫Slave，因為如果寫Master自己失敗後，還要回滾Slave，此時如果回滾Slave失敗，就得手工訂正數據了）你可以看到，如果Master-Slave需要做成強一致性有多復雜。
Master-Master
Master-Master，又叫Multi-master，是指一個系統存在兩個或多個Master，每個Master都提供read-write服務。這個模型是Master-Slave的加強版，數據間同步一般是通過Master間的非同步完成，所以是最終一致性。 Master-Master的好處是，一台Master掛了，別的Master可以正常做讀寫服務，他和Master-Slave一樣，當數據沒有被復制到別的Master上時，數據會丟失。很多資料庫都支持Master-Master的Replication的機制。
另外，如果多個Master對同一個數據進行修改的時候，這個模型的惡夢就出現了——對數據間的沖突合並，這並不是一件容易的事情。看看Dynamo的Vector Clock的設計（記錄數據的版本號和修改者）就知道這個事並不那麼簡單，而且Dynamo對數據沖突這個事是交給用戶自己搞的。就像我們的SVN源碼沖突一樣，對於同一行代碼的沖突，只能交給開發者自己來處理。（在本文後後面會討論一下Dynamo的Vector Clock）
Two/Three Phase Commit
這個協議的縮寫又叫2PC，中文叫兩階段提交。在分布式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當一個事務跨越多個節點時，為了保持事務的ACID特性，需要引入一個作為協調者的組件來統一掌控所有節點(稱作參與者)的操作結果並最終指示這些節點是否要把操作結果進行真正的提交(比如將更新後的數據寫入磁碟等等)。
㈥ IT編程開發分布式系統都存在哪些不足之處
分布式編程開發系統相信大家應該不陌生了吧。而關於分布式的缺陷或者說問題大家是否有去研究呢?今天我們就一起來了解一下，關於分布式系統中存在的幾個問題吧。
網路並不是可靠的
你應該明白，分布式系統中不同節點間的通信是基於網路的。網路使得它們連接起來共同協作。
然而，光纜被挖斷的事件相信你也看到過不是一兩次了。除此之外，網卡異常、交換機故障、遭受惡意攻擊等導致的網路擁塞、網路中斷、報文丟失的種種跡象皆意味著網路隨時可能無法正常運作，是不可靠的。
此時，需要在你的系統設計中，盡可能地考慮到：當前節點所依賴的其他節點由於各種原因無法與之正常通信時，該如何保證其依然能夠提供部分或者完整的服務。這個概念在軟體域被定義為「魯棒性」。
不同節點之間的通信是存在延遲的
網路連接的是處於不同物理位置上的節點，學過物理和數學你的應該明白，兩點之間是存在「距離」的，而我們的分布式系統需要在這個距離之上進行數據的傳遞，本質上就是物質的傳遞。同時應該你也知道，物質的運動速度不會超過光速。所以，不同節點之間的通信是需要經過一段時間的，也就意味著會存在延遲。具體的延遲是由所用的傳輸介質、節點當前的負載大小所決定的。
帶寬是有上限的
這個點，我相信你是知道的，因為當你通過QQ、釘釘之類的工具傳輸或者下載一個大文件時候，就發現它是存在上限的，這個上限是根據你的網路帶寬大小決定的。但是，為什麼你還是有可能會掉入這個陷阱里呢?電腦培訓http://www.kmbdqn.cn/發現這往往由於你對所傳輸的數據的大小和頻率沒有充分的認識，導致了你覺得達到上限是一個很久遠的事情，不用考慮它。
分布式並不直接意味著是「敏捷」了
可能你曾經有過這樣的想法，當在規模較大的集中式系統中工作的時候，每次和許多人在一個代碼庫里提交代碼，老是遇到沖突、排隊等待上游模塊先開發等等。這時你會想，如果改造成分布式系統，這些問題都沒了，工作效率高多了。
㈦ 誰能告訴我分布式系統的具體應用環境，還有其優缺點
一種計算機硬體的配置方式和相應的功能配置方式。它是一種多處理器的計算機系統，各處理器通過互連網路構成統一的系統。系統採用分布式計算結構，即把原來系統內中央處理器處理的任務分散給相應的處理器，實現不同功能的各個處理器相互協調，共享系統的外設與軟體。這樣就加快了系統的處理速度，簡化了主機的邏輯結構優點：容易訪問文件 分布式文件系統使用戶可以更容易地訪問文件。即使文件可能在物理上分布於多個伺服器上，用戶也只需轉到網路上的一個位置即可訪問文件。而且，當您更改目標的物理位置時，不會影響用戶訪問文件夾。因為文件的位置看起來相同，所以用戶仍然以與以前相同的方式訪問文件夾。用戶不再需要多個驅動器映射即可訪問他們的文件。 最後，計劃的文件伺服器維護、軟體升級和其他任務（一般需要伺服器離線）可以在不中斷用戶訪問的情況下完成。這對 Web 伺服器特別有用。通過選擇網站的根目錄作為 DFS 根目錄，您可以在分布式文件系統中移動資源，而不會斷開任何 HTML 鏈接。可用性 域 DFS 以兩種方法確保用戶可以保持對文件的訪問：首先，Windows Server 2003 操作系統自動將 DFS 映射發布到 Active Directory。這可確保 DFS 名稱空間對於域中所有伺服器上的用戶是可見的。第二，作為管理員，您可以復制 DFS 根目錄和目標。復制指您可在域中的多個伺服器上復制 DFS 根目錄和目標。這樣，即使在保存這些文件的某個物理伺服器不可用的情況下，用戶仍然可以訪問他們的文件。伺服器負載平衡 DFS 根目錄可以支持物理上分布在網路中的多個目標。如果您知道您的某個文件將被用戶頻繁訪問，這一點將很有用。與所有用戶都在單個伺服器上以物理方式訪問此文件從而增加伺服器負載的情況不同，DFS 可確保用戶對該文件的訪問分布於多個伺服器。然而，在用戶看來，該文件是駐留在網路的同一位置。 文件和文件夾安全 因為共享的資源 DFS 管理使用標准 NTFS 和文件共享許可權，所以您可使用以前的安全組和用戶帳戶以確保只有授權的用戶才能訪問敏感數據。缺點： 系統開銷大。系統開銷主要包括硬體開銷、通信開銷、數據冗餘的潛在開銷，以及為保證資料庫全局並行性、並行操作的可串列性、安全性和完整性等的開銷。 數據安全性和保密性較難處理。每個場地的數據安全不能保證全局的數據是安全的，安全性問題是分布式系統的固有問題。分布式系統是通過網路實現分布控制的，而通信網路本身在保證數據安全方面存在弱點，數據很容易被竊取。
㈧ 如果區域網遇上網路中斷的時候,你是怎麼處理的
ls說的很正確，不過本著「自己動手豐衣足食」的優良傳統，我們應該具備基本的網路故障排除解決能力。
區域網經常出現的問題有：
1.若是自動獲取IP，則DHCP服務down掉將導致中斷；
2.IP沖突；
3.若是固定IP，則可能是掩碼配置不正確，或是忘記配置默認網關；
4.ARP風暴，病毒等，這種情況可以逐台電腦排查「元兇」；
5.硬體方面的故障，比如交換機宕掉，網卡介面問題等，這種情況就得花錢解決了。