Designing Data-intensive Applications Ch05

8th May 2021 at 11:06am
Designing Data-intensive Applications

📝 原书笔记:

电脑上如果 PDF 不展示或者展示不正常,使用 Chrome 并安装 PDF Viewer 插件。其他情况请下载文件查看:chapter-05.pdf

重点内容:

  • 为什么要复制数据?
    • 离用户更近,提升可用性,支持更多请求量
  • 复制数据时,采用同步还是异步?
  • 三种复制模式:
    • 单 leader(主从复制)
      • 如何加入新的 follower
      • 如何处理节点故障
      • 同步日志的实现方式:statement-based, row-based, WAL shipping, trigger-based
      • 主从不一致(同步时的延迟导致)引起的问题
        • 读不到自己刚发的数据
        • 先读到多条数据,刷新时数据变少了(回到以前某个状态)
    • 多 leader
      • 多组 leader + follower。组内延用单 leader 的模式,组之间通过各 leader 互为 follower 同步数据
      • 相对单 leader 提升了可用性;不主流;可用于多 datacenter
      • 可以离线编辑的应用(如日历、Google Docs),可以当作多 leader 模式,本地和 server 端的数据分别是两个 leader
      • 难以解决数据冲突问题(但书中给了一些方法)
    • Leaderless
      • 特点:
        • 允许客户端向任意节点写入数据。不保证多条消息的写入顺序在各节点一致
          • 实现上:有些是客户端需要写多个节点;有些是客户端写到一个协调节点(coordinator node),再由这个节点向其他节点写入
        • 可用性非常高,允许一部分节点挂掉
      • Quorums consistency: w + r > n,即读取的节点数与写入的节点数应该有重叠。但这仍不能保证总是读到最新的数据
      • 检测冲突的内容中,happens-before 及后面的内容我没有看了,有需要了解时找一个现成产品看看