- 多線程的最大副作用:
并發
.
- 如果多個邏輯控制流在時間上發生了重疊, 就會產生并發.
- 邏輯控制流是指一次程序操作.
- 如讀取或者更新內存變量的值.
-
更新的并發性
: 多線程同時更新內存值而產生的并發.
- 分布式一致性
- 目標:
- 增加系統可用性, 防止因單點故障引起的系統不可用.
- 提高系統的整體性能, 通過負載均衡, 讓分布在不同地方的數據副本都能為用戶提供服務.
- 缺陷:
- 為了解決復制延遲, 阻塞寫入動作直到所有的復制完成, 會嚴重影響寫入的性能.
- 在不影響系統運行性能前提下,保證數據一致性是不可能的.
- 一致性的級別:
-
強一致性
. 最好的用戶體驗, 但是會影響性能. -
弱一致性
. 盡可能快地但不保證數據一致狀態.- 分為會話一致性和用戶一致性.
- 最終一致性. 保證一定時間內,達到數據一致狀態.
- 屬于弱一致性的特例. 是目前最被廣泛接收的.
-
- 目標:
- 分布式架構
- 常見問題
- 通信異常,節點故障.
-
網絡分區
:- 部分節點的網絡延遲過大, 導致只有部分節點間能夠正常通信的現象.
- 請求與響應的
三態
: 成功,失敗,超時.
- ACID.
- Atomicity: 事務中的所有操作只能全部執行或者全部不執行.
- Consistency: 事務的執行不能破壞?數據庫中數據的完整性和一致性.
- 當?數據庫在一些事務尚未完成時發生故障, 會導致部分修改寫入, 而處于不一致狀態.
- Isolation: 并發環境中,事物相互隔離.
- Read Uncommitted.允許臟讀.
- Read Committed. 允許不可重復讀(一次事物多次讀取相同值時, 原始讀取不可重復).
- Repeatable Read(鎖定?行). 事務過程中多次讀取同一數據,其值和開始時是一致的. 可能有幻影數據(鎖定?行范圍).
- Serializable. 所有事務串行執行,不?支持并發.
- Durability: 事務成功結束后,其對?數據庫的更新要被永久保存下來.
- 分布式事務
- 由多個分布式的操作(子事務)序列組成, 嵌套型的事務. 需要兼顧可用性和一致性.
- CAP. 最多只能同時滿足其中的兩項. 分區容錯性是必須的,平衡的是Consistency和Availability.
- Consistency. 數據在多個?副本間的一致性.
- Availability. 用戶的每個請求總能在有限的時間內返回結果.
- Partition tolerance. 遇到任何網絡分區(子網絡)故障時,對外提供滿足一致性和可用性的服務.除非整個網絡故障.
- BASE 理論.
既然無法達到?強一致性, 那么采用適當的方式來達到最終一致性.
- Basically Available. 出現不可預知的故障時, 允許損失部分可用性.
- 造成響應時間上的損失, 功能上的損失.
- Soft state. 允許系統中的數據存在中間狀態.
- 即數據副本間的同步存在延遲.
- Eventually Consistent. 它包含五種變種:
- Causal consistency. 更新進程完成后通知進程B,進程B拿到的是更新后的數據.
- Read your writes. 進程更新數據后,自己總是能讀取到更新過的新值.
- Session consistency. 在同一會話中實現
read your writes
的一致性. - Monotonic read consistency. 進程讀取某數據項后,后續的數據訪問不能返回舊值.
- Monotonic write consistency. 保證來自同一進程的寫操作順序地執行.
- 核心:
犧牲強一致性來獲得可用性.
- Basically Available. 出現不可預知的故障時, 允許損失部分可用性.
- 常見問題
- 一致性協議
- 跨越多個分布式節點的事務操作,需引入協調器(Coordinator)來調度,節點稱為參與者(Participant).
- Coordinator 調度Participan t的行為, 并最終決定是否要把事務真正進行?提交.
- 兩階段提交協議(2PC, Two-Phase Commit).
- 關系型?數據庫的通用做法, 屬于強一致性算法.
- 階段:
- 提交事務請求(投票); 要么返回失敗,要么本地執行事務,寫本地的redo/undo日志,但不提交.
- 執行事務提交(執行).
- 采用先嘗試后提交的方式.
- 缺點:
- 同步阻塞(participant 會一直等待它人的響應/ 或participant 占用公共資源時);
- 單點問題(coordinator);
- 數據不一致性(階段二如果有節點沒有收到提交消息時, coordinator 就宕機時);
- 太過保守(coordinate 只能依靠超時來處理長時間無響應的participant).
- 當coordinator 發送了commit 后宕機, 且唯一接收到commit 消息的participant 也宕機后, 重新選舉的coordinator 也無法知曉是否應該commit.
- 三階段提交協議(3PC)
- 階段:
- CanCommit, PreCommit, Do Commit.
- participant 在PreCommit 階段執行事務操作,并將Undo 和Redo 信息記錄到事務log 中.
- 改動點:
- 在協調者和參與者之間引入超時機制.
- 新插入的準備階段, 保證了在最后提交階段之前, 各參與節點的狀態是一致的.
- 缺點:
- 進入Do commit階段,參與者在等待(協調者的提交/中斷指令)超時后,會繼續進行事務提交. 可能導致數據的不一致性.
- 優勢:
- 降低了參與者的阻塞范圍, 且在單點故障后繼續達成一致性.
- 階段:
- 跨越多個分布式節點的事務操作,需引入協調器(Coordinator)來調度,節點稱為參與者(Participant).