分佈式系統複習筆記2019年秋

Introduction

分佈式系統定義（集合、單一、一致）

獨立計算機的集合，對外呈現一個單一的、一致的系統。

分佈式系統的目標（MDOS）

• (Make resources available)讓資源可用
• (Distribution transparency)分佈式透明
• (Openness)開放
• (Scalability)可擴展性

爲什麼要分佈式(ESIRI)

Economics 經濟性	微處理器能提供比大型機更好的性價比
Speed 速度	分佈式系統能提供比大型機更強的計算能力
Inherent distribution 固有的分佈性	有一些應用包含物理上分佈的機器
Reliability 可靠性	當某臺機器崩潰時，整個系統仍能正常工作
Incremental growth 可擴展性	計算能力逐步增加

分佈式系統透明性和開放性的含義

• 透明性：在用戶面前呈現爲單個計算機系統，隱藏底層的細節
• 開放性：能夠和其它開放系統提供的服務進行通信互訪，獨立於底層異構的環境。

分佈式系統的類型（計算、信息、普適）

• 分佈式計算系統 ：網格計算、雲計算等
• 分佈式信息系統：分佈式數據庫等
• 分佈式普適系統：節點更小、可移動、嵌入式的分佈式系統

Distributed System Architecture

分佈式系統架構風格（層次、對象、時空解耦）

• 在邏輯上分爲不同組件，然後將它們分佈到不同的機器上
  • 層次風格用於c-s系統
  • 基於對象的風格用於分佈式對象系統
• 空間上解耦，時間上異步
  • 發佈/訂閱模式 （空間上解耦）
  • 分享數據空間 (時空上解耦)

分佈式系統組織形式（集中、分佈、混合）

• 集中控制式
• 去中心化
• 混合式

客戶-服務器模式和對等模式

Basic Client-Server 模型（單服務器/多客戶端）：

• • 特點：服務器提供服務；客戶端使用服務；客戶端和服務端可以在不同機器上；客戶端通過請求/回覆模式使用服務
  • 缺陷：服務器成爲瓶頸；服務器成爲單點故障；系統很難擴展
  • 多個服務器/多個客戶端，web proxy ，web applets, thin clients
  • 傳統三層結構：User-interface layer、Processing layer, Data layer

對等模式（結構、非結構、混合）

• • 結構化 p2p：將節點組織成結構化覆蓋網絡例如邏輯環和超立方等，並根據節點ID來指定任務
  • 非結構化p2p：節點之間隨機覆蓋，兩個節點有一定的概率建立鏈接。算法有Flooding，Random walk（隨機選個節點v，v要麼返回結果，要麼隨機選擇一個自己的鄰居）。
  • 混合p2p：CS與p2p的結合。邊緣服務器架構，例如CDN的架構

分佈式系統組織爲中間件

在大多數情況下，分佈式系統會根據特定的架構風格去部署，這樣的風格並不是在所有情況下都是最優的，因此需要動態適配中間件的行爲。

 

Processes

進程vs 線程

• 進程是具有獨立功能的程序關於某個數據集合的一次性活動，是資源分配和調度的基本單位。(ready ,running, blocked)
• 線程是進程的一個實體，是CPU調度的基本單位。
• 線程之間共享地址空間，進程間則獨立。一個進程可以有多個線程
• 優勢：代碼遷移最多包含代碼、數據、執行狀態的遷移，總傳輸量小於一個虛擬機，所以輕量，網絡負載小，無需引入其它中間語言
• 劣勢：在異構系統中目標計算可能不適合執行遷移的代碼，進程、線程、處理器上下文可能高度依賴本地硬件，OS和運行時系統。

代碼遷移

Code segment/ Data segment / Excution state

強遷移 vs. 弱遷移

• 只遷移代碼和數據段，相對簡單，需要將代碼傳送和代碼提取區分開
• 遷移整個組件，包含執行狀態

Manging local resources

本地資源在目標處可能不可用

資源類型：

• 固定：不能被遷移，例如硬件
• 牢固：遷移代價很大
• 獨立：很容易遷移

對象到資源的綁定：

• 通過標識符：目標需要一個具體的實例（例如數據庫）
• 通過值：目標需要資源的值（例如 緩存的集合）
• 類型：目標需要資源的類型

Migration in heterogeneous systems

主要問題

• 目標機器可能不適合執行遷移代碼
• 進程/線程/處理器上下文可能高度依賴本地硬件、os和運行時系統

利用在不同平臺上實現的抽象機器

• 解釋型語言，擁有自己的VM
• 虛擬機

Communication

通信的類型（持久/非持久、異步/同步）

非持久通信：無法在下一個服務器或接收者處傳遞消息時，服務器將丟棄該消息

持久通信：只要傳遞消息，消息就會存儲在通信服務器中

同步通信和異步通信

遠程過程調用RPC（Remote procedure call protocol）

RPC概念：當機器A上的一個進程調用機器B上的一個過程，則調用進程掛起，被調用進程在B上執行。信息可通過參數或者結果傳遞，過程對程序員不可見。

目標：讓遠程調用在程序員看起來是本地的普通調用。

RPC的工作過程

 

(1) 客戶端（client）以本地調用方式（即以接口的方式）調用服務；

(2) 客戶端存根（client stub）接收到調用後，負責將方法、參數等組裝成能夠進行網絡傳輸的消息體（將消息體對象序列化爲二進制）；

(3) 客戶端通過sockets將消息發送到服務端；

(4) 服務端存根( server stub）收到消息後進行解碼（將消息對象反序列化）；

(5) 服務端存根( server stub）根據解碼結果調用本地的服務；

(6) 本地服務執行並將結果返回給服務端存根( server stub）；

(7) 服務端存根( server stub）將返回結果打包成消息（將結果消息對象序列化）；

(8) 服務端（server）通過sockets將消息發送到客戶端；

(9) 客戶端存根（client stub）接收到結果消息，並進行解碼（將結果消息發序列化）；

(10) 客戶端（client）得到最終結果。

故障處理

• 客戶端不能找到服務器

e.g. 服務端掛掉/ 服務端更新而客戶端還用的老版本

解決方案：使用 返回值(-1)、exception、signal等代表異常

• 客戶端到服務端的請求信息丟失

客戶端設置一個timer，超時重發

• 服務端到客戶端的回覆信息丟失

客戶端設置一個timer，超時則重發；對於不冪等的請求，爲請求分配序號，服務器區別不同的請求

• 服務端在收到請求後崩潰

1. 等待服務器重啓然後重發，保證RPC至少被執行一次(至少執行一次語義)
2. 立刻放棄並彙報錯誤，保證RPC最多執行一次
3. 什麼也不做，語義由客戶端自己保證

• 客戶端在發送請求後掛掉

問題：計算在服務端進行卻沒有接收計算結果的一端（孤兒），浪費了計算資源，並且可能在計算時還會鎖定數據；還可能導致混淆，因爲客戶端重啓後重新調用RPC可能收到上一個RPC的結果。

解決方案：1）extermination:在客戶端存根發送RPC前，將操作記錄在安全存儲的 log entry上，重啓後，查看 log entry 然後將 孤兒終止（爲每個RPC寫 log entry 代價較高，如果網絡切分了也無法終止孤兒）2）reincarnation:給時間劃分不同的時期，當客戶端重啓時，開始一個新的時期，並將這個消息廣播出去，服務器收到這個消息時，就終止任務的計算。3）expiration: 給rpc執行一個標準的時間段，未完成任務需顯式申請附加配額。

 

動態綁定（優勢：靈活、多服務器、版本一致。劣勢：ex/import開銷、瓶頸）

客戶端如何定位服務器？一種解決方案是將服務器地址寫死在代碼裏面，這樣不靈活；更好的方式是動態綁定：當服務器開始執行時，發送一個消息給binder 告訴自己所能提供的接口，然後當客戶端第一次調用RPC時，詢問binder服務器的位置，然後再進行操作。

動態綁定過程

• 服務器向一個binder 註冊自己的信息表示自己的存在，這些信息包括它的名字、版本號、唯一標誌符，句柄。
• 當客戶端第一次調用一個rpc時，客戶端存根利用接口名、版本號向binder 詢問接口信息。如果有，binder返回句柄以及標識符。
• 客戶端存根將句柄當作地址，發送調用信息，包括標識符和參數

優勢：

• 靈活
• 可以支持多個服務器提供同一個接口，從而實現負載均衡、容錯、協助認證
• binder可以確保client 和server 使用同樣版本的接口

缺點：

• 導入導出接口的額外開銷
• binder在大型分佈式系統中可能成爲瓶頸

基於消息的通信

同步異步

同步：sender 被阻塞，直到消息存儲在receiver的本地緩存或receiver接受到消息爲止

異步：sender 發送信息後繼續工作，消息存儲在sender 端或着第一通信服務器的的本地緩存

持久性/非持久性

持久性：只要將消息傳遞到接收方，消息就存儲在通信系統中。

持久性消息也稱爲消息隊列系統，sender和receiver都有自己的隊列，當sender將消息放到receiver消息隊列中時，receiver可以不是活躍狀態，反之亦然。

非持久性：消息被sender放到網上，如果其無法傳遞給下一個通信主機則丟棄。

面向流的通信（buffer、packet不放連續幀、複用/解複用）

數據流是一種支持等時數據傳輸的面向連接的通信工具

特點：1）單向 2）通常只有單個來源多個接收者 3）接收者或者源是硬件包裝器 4）簡單的流：音頻或者視頻 5）複雜的流：音頻視頻組合

Qos：1）傳輸數據所需的比特率 2）建立會話之前的最大延遲 3）端到端的最大延遲（數據單元到達對方的最大時間）4）最大延遲的方差或者抖動 5）最大往返延遲

• 利用 buffer 降低抖動
• 一個packet內不放連續的幀來降低丟包的影響
• 多個子流複用爲單個流，並在接收器處解複用，同步在 複用/解複用時解決

 

同步與資源管理

同步問題

在單cpu系統中，可以使用信號量等方法解決互斥、同步問題，分佈式系統中由於沒有共享內存這些方法是不起作用的。在分佈式系統中，如果發生兩個事件，很難知道哪個先發生，因爲兩個時鐘的差異、計算機時鐘受時鐘漂移影響，所以需要時鐘同步來保證時鐘的相對一致

 

邏輯時鐘和物理時鐘

時鐘同步不是必須的，如果兩個進程沒有交互，他們的時鐘可以不同步，重要的不是所有流程都確切的約定在幾點，而是他們同意事件發生的順序。

邏輯時鐘：僅考慮節點間的交互在事件的發生順序上達成一致，而不考慮時鐘是否接近實際時間的算法

物理時鐘：內部時鐘不僅要一樣，而且也要接近實際時間

 

時鐘同步機制

Cristian’s Time Sync

服務器和客戶端之間通過二次報文交換，確定主從時間誤差，客戶端校準本地計算機時間，完成時間同步，有條件的話進一步校準本地時鐘頻率。

 

流程如下：

1. 客戶端發送附帶T1時間戳的查詢報文給服務器；
2. 服務器在該報文上添加到達時刻T2和響應報文發送時刻T3；
3. 客戶端記錄響應報到達時間T4

RTT（Round Trip Time）= (t4-t1)-(t3-t2). RTT表示從發送到接受數據包的時間。假設來回網絡鏈路是對稱的，即傳輸時延相等，那麼可以計算客戶端於服務器之間的時差D爲 (t2-t1)- RTT/2, 所以客戶端在自己當前時間上加上誤差D就可以校準時間。同時爲了提高準確率，可以發送多次請求，計算RTT的平均值。

邏輯時鐘

給每個事件e 一個時間戳C,滿足下面兩個屬性：1）如果事件 a 和事件b 在同一個進程裏（不同進程分佈在不同機器上），並且a 先於b，只需要C(a) < C(b) 。 2）如果a 發送一個消息m，而b接受消息m，則必須滿足C(a) < C(b)。

因爲沒有全局時鐘，可以爲每個進程維護一個邏輯時鐘。

lamport算法（3步）

每個事件對應一個Lamport時間戳，初始值爲0

1. 如果事件在節點內發生，本地進程中的時間戳+1
2. 如果事件屬於發送事件，本地進程中的時間戳+1，並在消息中帶上該時間戳
3. 如果時間屬於接受事件，本地進程中的時間戳 = Max （本地時間戳，消息中的事件戳）+ 1

這樣保證了事件的偏序關係，但仍然存在不同進程中的兩個事件同時發生，因此可以爲每個進程編號，在C(a) == C(b)的情況下，若a進程號小於b進程號，則認爲a先於b，從而保證全序性（這裏a，b的先後並不重要，只是這樣可以對全局事件進行排序）

total order multicasting （全序組播）（基於隊列，4步：順序接受；發送消息；接受消息，放入隊列，發送ACK；應用消息）

如何保證分佈式系統中各個子系統都按相同的順序執行一組操作？一個等價的問題就是如何在分佈式系統下實現全序組播。

使用進程Id 保證不同進程的邏輯時鐘不一致，C(a).i （i是進程號） 發生在C(b).j 之前可以表示爲: C(a) < C(b) 或 C(a) == C(b), i < j 。

 

實現細節：

 

1. 設一個發送者發送的所有消息都按照他發送的順序被接受，
2. 進程 Pi 發送一個帶有時間戳的消息MSGi 給其它所有進程。它自己也將這個消息放入本地的隊列Qi
3. 進程按照消息的時間戳順序把接收到的消息放入一個本地的隊列中，然後向其他所有進程多播一個ACK（確認消息收到）
4. 進程Pj 有在滿足下麪條件時，纔會執行消息：
   1. MSGi 在Qj 頭部
   2. MSGi在Qj中時間戳最小

實現原理：

1. 收到消息的時間戳低於ACK的時間戳，這是Lamport Clock的特性
2. 所有的進程在本地保存的隊列都是相同的，保證了實現順序的一致性

向量時戳（3步：vector含義；發送msg+vector；更新vector）

lamport lock 特點

• 如果 a 因果先於 b，則 C(a) < C(b)
• 如果 C(a) < C(b) ，a不一定 因果先於b，可能是併發關係

向量時戳就是解決這個問題的。

• 每個進程Pi有一個vector VC_i[n] , VC_i[j]表示Pi 知道的關於Pj上發生的事件數
• 當Pi發送一個消息m，VC_i[i] +=1，然後將消息m和自己的VC一起發送出去
• 當進程Pj收到消息m時，更新自己的VC_j[k]爲 Max（VC_j[k] ，VC_i[K]）,然後將相應的VC_j[j] + 1

 

分佈式系統的互斥訪問

Centralized Mutual Exclusion

集中式算法：仿照單機處理系統中的方法，選舉一個進程作爲協作者，由這個協作者調度對共享資源的訪問。

當一個進程要訪問共享資源，它要向協作者發送一個請求信息，說明它想要訪問哪個資源。如果當前沒有其他進程訪問資源，協作者就發送准許的應答消息。

 

特性:

• 安全的，每次只有一個進程訪問共享資源
• 基於隊列的公平性
• 沒有餓死問題
• 非常好實現(三種消息：一個請求，一個授權，一個釋放)

缺點：

• 協調者：單點故障，性能瓶頸
• 如果進程發送請求後阻塞，則不能區分協調者掛了還是被拒絕了。

A Distributed Algorithm （基於時間戳投票）

• 當一個進程想要訪問臨界資源時，構建訪問請求信息帶上自己的時間戳，然後發送給所有其它進程
• 當一個進程收到了其它進程的請求信息，1） 如果它沒有也不想訪問這個資源，回覆ok。 2)如果正在訪問這個資源，則將請求信息放到隊列裏 。3）如果想訪問但還沒訪問，就對比下自己發出的訪問請求信息中的時間戳，如果自己的更小，則將請求放入隊列；否則回覆ok

缺點：

• 如果任何進程崩潰，它將對後續操作無反應，會被認爲是拒絕，從而阻止其它進程訪問
• 需要可靠的多播，維護一系列信息
• 比集中算法更慢、更復雜、更不可靠

Token ring algorithm

將進程組織爲邏輯環，然後傳一個令牌，擁有令牌的可以訪問資源

 

分佈式系統的選舉機制

Bully Algorithm（3步：優先級組播；出局/接管；沒收到接管獲勝）

每個進程都有自己的優先級，問題是如何找到最高優先級的進程

1. 每個進程都能開始一輪選舉，將選舉消息附帶上自己的優先級發送給所有其它進程
2. 進程收到消息後，比對自己的優先級，自己低則出局，自己高則回覆接管消息
3. 如果一個沒有收到一個接管消息，則它就贏了，向所有其它進程發送勝利消息。

Election in a ring

任何進程都可以發送選舉消息，然後這個消息不斷往下傳，每傳到一個節點大家都將自己的優先級信息附加上去，最後回到選舉發起者那裏，然後找到優先級最高的那個作爲協調者，將消息傳播出去。

 

複製與一致性

複製的優勢與不足（可靠性/性能；複製透明度/一致性）

優勢 ：可靠性、性能

不足：複製透明度；一致性問題。

真正實現一致性，需要考慮數據更新時如何進行實際的分發，副本的位置、更新的方式，更新的速度

數據一致性模型

Data-centric consistency

數據的共享是通過分佈式共享存儲器、分佈式共享數據庫或者分佈式共享文件系統實現的。

Strict consistency

需要保證數據更新的同時，所有副本也同樣同時更新，但顯然是不可能實現的

Sequential consistency

允許任何讀寫操作的交叉執行，但是要保證所有進程能夠確認統一的執行順序，不會存在不同進程的執行順序得到不同的結果的現象。

存在嚴重的性能問題，對於任何順序一致性存儲，提高讀操作性能必降低寫操作性能

實現順序一致性：對於寫操作，使用全序多播；對於讀操作，立即返回本節點上對應變量的值。

Linearizability

線性一致性相對於順序一致性增加了時間戳順序的要求，更加嚴格

Causal Consistency

弱化的順序一致性，順序存儲的因果一致性定位爲：所有進程必須以相同的順序看到具有潛在因果關係的寫操作。不同機器上的進程可以以不同的順序被看到併發寫操作。

實現因果一致性要求跟蹤哪些進程看到了哪些寫操作。換句話說，因果一致性允許不同的機器以不同的順序看到併發的寫操作，但是所有機器必須以相同的順序看到因果相關的操作。

FIFO Consistency

所有進程以某個單一進程提出寫操作的順序看這些寫操作，但是不同進程可以以不同的順序看到不同進程提出的寫操作。也就是說，進程不必再開始進行下一個寫操作之前停止並且等待前一個寫操作的完成。不同進程產生的寫操作都是併發的。

它僅僅要求：對於同一個進程執行的讀寫序列，對於任何一個變量x的讀操作read(x)，讀到的值都是在此讀操作之前最後一次此進程發出的寫操作write(x)更新的值。而對於不同節點發出的寫序列，其他節點的讀操作可以按任意順序返回值。

Weak Consistency

引入同步變量s，當一個進程對變量設置值的時候，不保證其他進程什麼時候能夠看到值的變化，但是當執行了一次同步操作後，所有進程會看到最新的值。

Release Consistency

使用兩個同步變量ACQ和REL成對控制，釋放一致性規則如下

• 對共享數據執行讀寫操作之前，所有進程之前的獲取操作都已經完成
• 在釋放操作被允許之前，所有進程之前對數據的讀寫操作都必須已經完成
• 對同步變量的訪問是FIFO一致的

Entry Consistency

 

Client-centric consistency(最終一致性；只需保證更新消息被傳出去；訪問多個和一個副本難度不同)

本質上以客戶爲中心的一致性模型爲單一的客戶提供一致性保證，並不爲不同客戶的併發訪問提供一致性保證。

Eventual consistency

如果在一段相當長的時間內沒有更新操作，那麼所有的副本將逐漸成爲一致的。

單調讀：進程在t時刻看到x，保證後續操作不會看到x的更老版本。

單調寫：寫操作必須完全串行執行，不能交叉。

寫後讀(read-your-writes consistency)：一個寫操作總是在同一進程後續讀操作之前完成，不管這個後續讀在什麼位置。

讀後寫：對數據項x的任何後續寫操作，保證發生在於x讀取值相同或比之更新的值上。

三種數據拷貝的類型：永久複製（多個拷貝分佈在LAN的多個server上；）；server發起的複製；client發起的複製（主要是cache）

更新傳播的三種方式：僅傳播一個更新通知；傳播更新後數據；傳播更新操作種類；

數據一致性協議實例

基於法定數量的協議（兩個不等式）

要求客戶在讀寫一個複製的數據項之前請求半數以上的服務器並多的返回的版本號，以確定數據的最新版本。假設所有副本數量加起來等於V

每個操作需要獲得一個讀的法定數量Vr 和寫的法定數量Vw，必須遵循以下規則：

• Vr + Vw > V
• Vw > V/2

 

容錯

可信系統（Dependable System）特徵（ARSM）

• (Availability)可用性：在任何給定的時刻，系統都可以正確及時地工作，並執行用戶的請求。
• (Reliability)可靠性：系統可以無故障持續運行，但是隻能根據時間間隔來定義。高可靠性的系統可以在一個相對較長的時間內持續工作而不被中斷。
• (Safety)安全性：系統偶然出現故障時還能正確操作和運行。
• (Maintainability)可維護性：表示發生故障後系統能被恢復到可用性的難易程度。

提高系統可信性的途徑（信息|時間|物理冗餘；少量關鍵組件同時運行）

使用冗餘來掩蓋故障：對其它進程隱藏故障的發生。

• 信息冗餘：添加額外的位或碼檢測恢復數據傳輸錯誤
• 時間冗餘：重複執行異常終止的任務
• 物理冗餘：添加額外的硬件或軟件

一種不需要大量關鍵組件同時運行的設計。

K容錯系統

複製進程的管理（基於主進程|選舉|層級；複製寫|法定數量協議|平等）

基於主進程的複製：主進程負責協調所有更新；如果協調者掛了，備份接管（通常需要選舉）；進程之間是層級的組織方式。

複製寫：主動複製，基於法定數量協議；平等組織；沒有單點失敗

設計問題

• 系統能夠經受K個組件的故障並且還能滿足規範要求。當這些組件是失敗沉默的情況下，需要K+1個組件可以提供K容錯；如果發生拜占庭失敗，至少需要2k+1個進程才能獲得K容錯
• 組結構：平等/分層
• 需要管理組以及組關係；集中式：group server；分佈式：全序多播

 

拜占庭問題（ByZantine Problem）

通信是可靠的但是進程不可靠。（通信不可靠的兩軍問題無解，最多隻能降低不可靠性）。

問題定義

n 個不同地點的藍色將軍想要達成共識，但是其中的m個是叛徒。那麼忠誠的將軍們能否在同一個行動上達成共識？這個與K容錯是有區別的。K容錯是正確節點都會得到相同結果，而拜占庭將軍問題是正確節點也會存在有不同結果。

算法步驟

第一步：每個軍將告訴其他所有n-1個將軍自己的兵力（真假未知）。

第二步：每個將軍收集消息形成一個向量。

第三步：每個將軍將自己的向量發送給其它所有將軍。

第四步：每個將軍檢查新收到的向量的第i個元素。把多數值保留下來，得到一致結果。

結論：具有m個故障進程的系統中，只有存在2m+1個正確的進程才能達成一致，也即共有3m+1個進程。

Byzantine Generals Problem

設計一個協議，一個司令要送一個命令給他的n-1個副官，使得

IC1. 所有忠誠的副官遵守同一個命令。(一致性)

IC2. 假如司令是忠誠的，則每一個忠誠的副官遵守他送出的該命令。(準確性)

約定：忠誠的將軍將遵守協議，而叛徒則可能破壞協議，儘可能的幹繞其它人的判斷。叛徒是匿名的。而且最後不需要確定誰是叛徒。拜佔廷將軍問題就是要讓愛國的將軍達成一致，而不是找叛國的將軍。

Oral Message Algorithm （OM算法）

叛徒少於1/3，拜占庭問題可解

A1) 傳送正確

A2) 接收者知道是誰發的

A3) 沉默（不發信息）可被檢測

OM(n,0):

1. 司令發送命令給所有副官
2. 副官按照接受到的命令行事

OM(n,m):

1. 司令發送命令給所有副官，設副官i收到命令vi
2. 分爲獨立的n-1輪：對每個副官i，將其視爲司令，使用OM(n-1,m-1)將vi發送到所有其它n-2個副官
3. 這樣每個副官都收到n-1條消息，每個副官都按照出現次數更多的命令行事（如果進攻和撤退命令一樣多，則默認撤退）

系統恢復

發生故障後恢復到正確的狀態

• 回退恢復
• 前向恢復

檢查點

獨立檢查點

• 每個進車獨立設立檢查點
• 進程可以回滾到全局一致的狀態

協調檢查點

所有的進程進行同步，以共同將其狀態寫入本地穩定存儲，從而形成全局一致狀態

兩個算法：

• • 分佈式快照 -- 非阻塞式
  • 兩階段鎖定協議 two-phase blocking protocol

two-phase blocking protocol

• 協調者將 Checkpoint_request 消息組播給其它進程
• 當一個進程收到了消息，它就設立一個檢查點，將任何應用程序發給它的後續消息放到隊列裏（進入阻塞狀態），並且發送一個ACK通知協調者
• 當協調者收到了所有的ACKs，就組播一個 Checkpoint_done 消息個允許阻塞的進程繼續執行

 

雲計算

定義 

一種計算能力，提供了計算資源與底層結構之間的抽象，使用戶可以通過網絡方便的、按需使用的來對一個共享資源池進行迅速的配置、部署與使用，並且只需要很少的管理以及與服務商的交互。

服務分類

軟件即服務SaaS (Software as a Service)	Salesfoce online CRM服務
平臺即服務PaaS(Platform as a Service)	Google App Engine Sina App Engine(SAE)
基礎設施即服務IaaS(Infrastructure as Service)	Amazon EC2、S3 阿里雲

特點

• 高可靠性：冗餘副本、負載均衡
• 通用性：支撐千萬變化的實際應用
• 按需服務：按需購買
• 安全：擺脫數據丟失、病毒入侵
• 方便：支持多終端、數據共享

雲計算模式

• 公有云：資源以“按需服務”的方式提供給公用服務；服務以一種效用計算的方式被出租使用
• 私有云：爲一個單獨客戶而構建的，提供對數據、安全性和服務質量的最有效控制。
• 混合雲：安全因素，並非所有的企業信息都能放置在公有云上。

雲計算與雲平臺

• 雲計算是一種計算模式、而不是一種產品
• 按需服務是雲計算的核心理念，類似於水、電等基礎設施
• 雲平臺是實現雲計算模式的產品，是用戶使用雲計算服務的入口，也讓服務商以最小代價滿足用戶請求。

虛擬化

虛擬化是由位於下層的軟件模塊，將其封裝或抽象，提供軟硬件的接口，使得上層的軟件可以直接運行在這個虛擬的環境，和運行原來的環境一樣。

虛擬化與雲計算

虛擬化特點	爲雲計算帶來的好處
封裝與隔離	保證每個用戶有安全可信的工作環境
多實例	保證較高的資源利用率 爲服務器合併提供基礎
硬件無關性	整合異構硬件資源 可實現虛擬機遷移，使資源調度、負載平衡容易實現
特權功能	入侵和病毒檢測
動態調整資源	細粒度的可擴展性

 

邊緣計算

基本思想：把雲計算平臺從移動核心網絡內部遷移到移動接入網邊緣

概念

• 利用靠近數據源的邊緣地帶來完成的運算程序。
• 一種分佈式的計算模式
• 大部分計算在邊緣設備上完成，而不是主要在集中式雲環境中運行

集中式雲環境缺點：

不易擴展、集中而脆弱、安全信任難以實現、更易受到攻擊、控制設備時延高

優點

措施：把大部分計算沉降在靠近設備的邊緣，小部分連接遠處的雲端

• 實時響應時間短（火災、控制燈等），減輕整個IT基礎架構的負擔
• 減少網絡傳輸量，傳輸處理的數據，而非原始數據，防止網絡擁塞
• 邊緣計算實現數據的安全性和隱私性
  • 敏感數據在邊緣設備上生成、處理和保存，而不是通過不安全的網絡傳輸
  • 數據保密性好
• 充分利用智能設備的運算能力
  • 在邊緣設備處存儲和處理數據
  • 利用計算能力使邊緣設備的行爲類似於雲類操作
  • 應用程序可以快速執行，並與端點建立可靠且高度響應的通信

雲計算與邊緣計算的結合

可能結合的一種架構

• 中心雲——集中式
• Fog 和Edge——分佈式

特點

• 集中於分佈相結合
• 邊緣設備根據不同時延要求分配任務給邊緣雲或集中雲