【翻】跨数据中心的事务

以下是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」转载请注明。
如果觉得有趣，微信扫一扫关注公众号。