【读书笔记】Distributed systems for fun and profit
本文是 Distributed systems for fun and profit 的读书笔记。
第一章
任何计算机系统都需要解决的两个基本问题：
- 存储
- 计算
分布式系统的优势：
- 可扩展性，可以随着规模增长提升系统的计算、存储、网络等等的资源
- 高性能，包括快速响应时间、高吞吐量和高效的计算机资源的使用
- 高可用性（容错），考虑到可能发生的错误并且设计相应的的系统或算法来容忍这种错误，你无法为你未考虑到的场景做容错
分布式系统的物理限制：
- 节点数量
- 节点之间的距离
分布式系统中常用的设计技巧：
- 分区（partition）
- 备份（replicate）
第二章
系统模型是对分布式系统的抽象，如何才能构建一个系统模型呢？
存在的问题：
- 节点，节点可能发生crash
- 连接，连接随时都可能发生断开
- 时序，在分布式系统中由于没有统一的时钟，所以节点之间无法正常的同步（Lamport timestamps）
- 同步系统模型：
- 异步系统模型：
FLP理论。FLP理论告诉我们，想要设计一个完全正确的分布式系统模型是不可能的。
CAP理论。在设计分布式系统的时候，需要参考CAP理论，根据不同的侧重使用不同的设计：
- 可用性，即需要能够向外提供服务
- 分区容错性，分布式系统需要分区和容错
- 数据（强）一致性：多种一致性模型，包括很多强一致性模型和弱一致性模型。
ACID和BASE代表了两种截然相反的设计哲学，它们都是一种分布式系统的设计方式。而Paxos和Raft都是为了解决这个问题而作出的努力，它们都是一种十分具体的设计方式。
第三章：时序（Time and order）问题
因为物理时钟无法再使用，我们需要使用逻辑时钟：
- Lamport clocks（Raft算法中日志同步好像用的就是这种算法？）
- vector clocks：Lamport clocks的扩展
第四章：复制(强一致性)
复制（replication）
- 同步复制，一旦某个节点出现问题，可能导致整个系统不可用
- 异步复制，有可能导致数据丢失，或者在多个节点上数据读取结果不一致
复制算法：
- Primary/backup Replication
- 2PC
- 3PC
- Paxos
- Raft
- ZAB
第五章：复制（最终一致性）
最终一致性
参考
https://www.cnblogs.com/bangerlee/p/6216997.html
以下为一些思考或总结的内容
为什么要使用分布式系统：如果只有一台负载，存在着问题，无法高可用、高性能、高可扩展性
分布式系统会产生多个节点：
- 通过节点完整数据复制的方式：不是不可以，而是不够灵活，且数据恢复时浪费带宽
- 基于分片和备份的方式管理数据（使用何种策略产生分片和备份？副本的管理机制：中心化 || 去中心化？），系统成为分布式的。
分布式会引入几个问题：节点、网络 crash、时序问题，解决这些问题？
- 副本协议（使用何种策略拆分和管理副本）
- 租约机制（lease）
- 选举机制（quorum）（节点、副本）
- 日志技术
- 两阶段、三阶段提交
- 分布式一致性协议。。。
中心化的选举：直接由master指定某一个副本（或节点）为Primary，通过lease管理，Primary需要不断地告诉master自己还活着
去中心化的选举：Raft协议，选举前是去中心化的，选举结束后整个系统是一个中心化的系统，master管理整个系统
如何实现高可用（使用同质的服务）：
主备（fail over）：如果涉及到数据则备机还需要备份同步master的数据
负载均衡（load balance）
传统数据库的扩容：同构系统
大规模存储系统的可扩展性：异构系统（存储节点和负载之间是异构的，其实就是副本的概念，异构系统带来更高的数据同步和扩容效率）
副本数据在备份时，需要保证一定的一致性，即原始数据到备份数据之间的一致性
一些常用的思想：
- 多数派(quorum)的思路帮助我们在网络分化的情况下达成决议一致性，在leader选举的场景下帮助我们选出唯一leader
- 租约(lease)在一定期限内给予节点特定权利，也可以用于实现leader选举