【翻】跨數據中心的事務

如下是Google的資料，純粹做爲記錄用， 來自2009年的PPT

http://snarfed.org/transactio...

先是一些分佈式的經驗

Of three properties of distributed data systems - consistency,
availability, partition tolerance - choose two.
Eric Brewer, CAP theorem, PODC 2000

Scaling is hard.
Various

一致性

• 弱一致

• 最終一致

• 強一致

• 用例：寫後讀

弱一致

• 寫入後，可能或不能讀到結果

• 盡力而爲

• 「瓶中信」

• App Engine: memcache

• VoIP, 在線視頻

• 實時多人遊戲

最終一致

• 寫入後，最終能讀到寫入結果

• App Engine: mail

• 搜索引擎索引

• DNS, SMTP, snail mail

• Amazon S3，SimpleDB

強一致

• 寫入後，就能讀到結果

• App Engine: datastore

• 文件系統

• 關係數據庫

• Azure tables

前面有什麼

• 一致性？

• 爲何用事務？

• 爲何跨數據中心？

• 技術與妥協

• 結論

爲何用事務？

• 老例子：從A到B轉帳

  • 從A扣錢

  • 給B加錢

• 若是這期間發生什麼了？

  • 另外一次A或B間的轉帳

  • 機器掛了

  • …

• 正確性

• 一致性

• 執行不可變

• ACID

爲何跨數據中心

• 災難性失敗

• 預期的失敗

• 常規維護

• 地理

  • CDN, 邊緣緩存

爲何不跨數據中心？

• 在數據中心內

  • 高帶寬：1-100Gbps內部鏈接

  • 低延遲：機架內<1ms，機架間1-5ms

  • 損耗很小

• 數據中心間

  • 低帶寬：10Mbps-1Gbps

  • 高延遲：50-150ms

  • 光纖要錢

多路

• 困難的問題。

• 一致性？更難

• 還要實時寫？最難

• 怎麼辦？

選項1：無容災

• 容災很爛

  • 大面積數據丟失

  • 例子：SVColo

• 提供服務上不怎麼樣

  • 沒有異地

選項2：帶故障轉移的一主

• 更好，但不夠理想

  • 中等質量的容災

  • 丟失數據的時間窗

  • 失敗數據可能會不一致

• Amazon Web Services

  • EC2，S3, SQS: 選擇美國或歐洲

  • EC2: 可用區（Zone），彈性負載均衡（Elastic Load Balancing）

• 銀行，金融，等

• 異地讀，沒有寫

選項3：真多通道

• 不一樣數據中心中多寫

• 兩路：困難

• 多路：更難

• 處理容災失敗，地理問題

• 要爲延遲買單

技術與權衡

備份

• 作個副本

• 弱一致

• 一般無事務

主備複製

• 一般異步

  • 有吞吐，低延遲的好處

• 大可能是關係數據庫

  • 例如MySQL二進制日誌

• 弱/最終一致性

  • 粒度很重要！

• 數據庫：當前的

• 多主複製*

• 合併併發寫

• 異步，最終一直

• 須要序列化協議

  • 例如 時間戳 單調遞增的時間戳

  • 主選舉

  • 或者分佈一致性協議

• 無全局事務！

• 數據庫：無強一致

兩段提交

• 半分佈式一致協議

  • 協調人

• 1：提議，2：投票，3：提交/放棄

• 重量級，同步，高延遲

• 3PC做爲異步有多餘一步

• 數據庫：吞吐性差

• Paxos*

• 全分佈式一致性協議

• "Either Paxos, or Paxos with cruft, or broken"

  • Mike Burrows

• 多數票寫；少數票失敗

• 協議相似2PC/3PC

  • 輕量，但仍高延遲

Paxos對於數據存儲

• 在同一個數據中心？不

Paxos對於App Engine

• 協調變更的狀態

• 一般經過鎖服務

• Apps

• Memcache

• 離線處理

• 結論*

• 沒有銀彈

• 但仍然值得作

• 強調妥協權衡

---

文章來自微信平臺「麥芽麪包」
微信公衆號「darkjune_think」轉載請註明。
若是以爲有趣，微信掃一掃關注公衆號。