大數據分布式的簡介及理論是怎樣的

這篇文章將為大家詳細講解有關大數據分布式的簡介及理論是怎樣的，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

一：分布式簡介

1.1：分布式系統概念

分布式系統：就是將一個業務拆分為多個業務，分布在不同的服務器節點，共同構建的系統叫做分布式系統。

分布式與集群的區別：分布式是多個人在一起做不同的事情；集群是多個人在一起做同樣的事情。

分布式系統的特點：

• 分布性

• 對等性

• 并發性

• 缺乏全局時鐘

1.2：分布式系統的演變

1：單體應用架構->2：應用服務器與數據庫服務器分離->3：應用服務器集群->4：應用服務器負載均衡->5：數據庫讀寫分離->6：添加搜索引擎緩解數據庫壓力->7：添加緩存機制緩解數據庫壓力->8：數據庫水平拆分、垂直拆分->9：應用拆分->10：服務化

分布式架構演進圖示

1.3：分布式系統面臨的問題

1.3.1 通信異常

由于網絡本身的不可靠性，因此每次網絡通信都會伴隨網絡不可用的風險，都會導致分布式系統無法順利進行一次網絡通信。

1.3.2 網絡分區

網絡之間出現了網絡不連通，但各個子網絡的內部網絡是正常的，從而導致整個系統的網絡環境被切分成了若干個孤立的區域，分布式系統就會出現局部小集群。

1.3.3 節點故障

節點故障是分布式系統下另一個比較常見的問題，指的是組成分布式系統的服務器節點出現的宕機或"僵死"現象。

1.3.4 三態（成功、失敗、超時）

絕大部分情況下，網絡通信能夠接收到成功或失敗的響應，但當網絡出現異常的情況下，就會出現超時現象，通常有以下兩種情況：

• 請求并沒有被成功的發送到接收方，而是在發送過程就發生了丟失現象

• 請求成功的被接收方接收后，并進行了處理，但在響應反饋給發送方過程中，發生了消息丟失現象

二：分布式理論

2.1：一致性

分布式一致性：指的是數據在多份副本中存儲時，各個副本中的數據是一致的。
副本一致性：分布式系統當中，數據往往會有多個副本，各個副本要保證數據的一致性就帶來了同步的問題。

因此，如何既保證數據的一致性，同時又不影響系統運行的性能，是每一個分布式系統都需要重點考慮和權衡的。于是，一致性級別由此誕生：

2.1.1 強一致性

用戶更改了什么數據，讀出來就是什么數據，對系統性能影響大。其實現方式常為加鎖的方式，比如節點一的數據被更改，給其它節點上的該數據加鎖，直到改變的數據同步成功再釋放鎖。

2.1.2 弱一致性

系統在寫入成功后，不承諾立即可以讀到寫入的值，也不承諾多久之后數據能夠達到一致，但會盡可能地保證到某個時間級別（比如秒級別）后，數據能夠達到最終一致性即可。

最終一致性：不考慮所有的中間狀態的影響，只保證當沒有新的更新之后，經過一段時間之后，最終系統內所有副本的數據是正確的。
例子：比如銀行轉賬，A扣了錢后，經過很長時間，B收到錢。只要最終的狀態是正確的就行，其它方面可以降低要求。

最終一致性根據更新數據后各進程訪問到數據的時間和方式的不同包含下面的幾種方式：

1) 讀寫一致性

讀寫一致性：用戶讀取自己寫入結果的一致性，保證用戶永遠能夠第一時間看到自己更新的內容。
例子：比如我們發一條朋友圈，朋友圈的內容是不是第一時間被朋友看見不重要，但是一定要顯示在自己的列表上.
解決方案：

1. 一些特定的內容我們每次都去主庫讀取。（主庫壓力大）

2. 設置一個更新時間窗口，在剛剛更新的一段時間內，我們默認都從主庫讀取，過了這個窗口之后，再挑選最近有過更新的從庫進行讀取

3. 直接記錄用戶更新的時間戳，在請求的時候把這個時間戳帶上，凡是最后更新時間小于這個時間戳的從庫都不予以響應。

2) 單調讀一致性

單調讀一致性：本次讀到的數據不能比上次讀到的舊。由于主從節點更新數據的時間不一致，導致用戶在不停地刷新的時候，有時候能刷出來（請求到已經同步了的節點），再次刷新之后會發現數據不見了（又請求到了還未同步的節點），再刷新又可能再刷出來，就好像遇見靈異事件一樣。

解決方案：就是根據用戶ID計算一個hash值，再通過hash值映射到機器。同一個用戶不管怎么刷新，都只會被映射到同一臺機器上。

3) 因果一致性

指的是：如果節點 A 在更新完某個數據后通知了節點 B，那么節點 B 之后對該數據的訪問和修改都是基于 A 更新后 的值。同時，和節點 A 無因果關系的節點 C 的數據訪問則沒有這樣的限制。

2.2：CAP理論

CAP 理論含義是，一個分布式系統不可能同時滿足一致性（C:Consistency)，可用性（A: Availability）和分區容錯 性（P：Partition tolerance）這三個基本需求，最多只能同時滿足其中的2個。

• C 一致性：分布式系統中所有的節點（或副本）數據一致（這里的一致性指的是強一致性）

目標：若數據寫入主數據庫成功, 則從數據庫查詢數據也成功，若數據寫入主數據庫失敗,則向從數據庫查詢也失敗
實現：主數據庫寫入數據后對從數據庫加鎖，直到從數據庫同步成功再釋放鎖
分布式一致性的特點：

1. 寫操作會有一定的延遲，因為存在數據同步的過程

2. 同步過程中會對資源暫時鎖定

3. 若數據同步失敗，請求這個數據會返回失敗信息，而不是舊數據

• A 可用性：Reads and writes always succeed. 系統一直可用

目標：立即響應數據庫查詢請求（不考慮同步），不能出現響應超時或錯誤。
實現：寫入數據到主數據庫后，不考慮從數據庫的數據是否已經同步了，在讀取從數據庫數據時直接返回數據即可，即使數據是舊數據也行。

• P 分區容錯性：在系統節點或網絡分區故障時，仍然能夠提供滿足一致性和可用性的服務

目標：主數據庫同步數據到從數據庫即使失敗，也不能影響寫操作；其中一個節點掛掉不會影響另一個節點提供服務。

Partition tolerance（分區容錯性）的實現：

1. 使用異步的方式將主數據庫的數據同步到從數據庫

2. 添加數據庫節點，當中間的一個從節點掛掉時，由另一個從節點提供服務

2.2.1 CAP只能滿足其中二種

1. 舍棄A，瞞足CP（一致性和容錯性）
   一個系統保證了一致性和分區容錯性，舍棄可用性。也就是說在極端情況下，允許出現系統無法訪問的情況出現，這個 時候往往會犧牲用戶體驗，讓用戶保持等待，一直到系統數據一致了之后，再恢復服務。

2. 舍棄C，滿足AP（可用性及容錯性）
   大部分的分布式系統的設計，保證高可用和分區容錯，但是會犧牲一致性。

3. 舍棄P，滿足CA（一致性及可用性）
   如果要舍棄P，那么就是要舍棄分布式系統，CAP也就無從談起了，回到了傳統的單機服務了。

2.3：BASE理論

BASE理論：全稱：Basically Available(基本可用)，Soft state（軟狀態）,和 Eventually consistent（最終一致性）三個 短語的縮寫；是對CAP理論的一個協調，對CAP理論中一致性及可用性權衡的結果，讓CAP三種條件都達到不錯的效果，而不用必須三選二。

BASE理論的意義在于：我們不必在A或C中做出選擇，可以實現部分的A和C，是對 CAP 中 AP 的一個擴展。

BASE理論的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，采用適當的方式來使系統達到最終一致性

• Basically Available(基本可用)
  當分布式系統在出現不可預知故障的時候，允許損失部分可用性——但不等價于系統完全不可用。
  例如：出現故障時，使用搜索功能響應時間可以適當增加一二秒；雙十一時，為了保護系統穩定性，會引導部分用戶到一個降級頁面。

• Soft state（軟狀態）
  軟狀態：允許系統中的數據存在中間狀態，并認為該狀態不影響系統的整體可用性，即允許系統在多個不同節點的數據副本之間進行數據同步的過程中存在延遲。
  例如：外賣配送狀態，對用戶來說有配送中狀態。

• Eventually consistent（最終一致性）
  最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步后，最終能夠達到一個一致的狀態。而不需要實時保證系統數據的強一致性。 例如：轉賬不會立即到賬，會經過一段時間后數據同步成功，但最終一定會成功。

關于大數據分布式的簡介及理論是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。