深入理解分布式系统

1星价 ¥70.2 (6.5折)

2星价￥70.2 定价￥108.0

作者：唐伟志

出版社：电子工业出版社

本类榜单：计算机/网络

分类：计算机/网络 > 计算机理论

买过本商品的人还买了

暂无评论

图文详情

ISBN：9787121428111
装帧：80g胶版纸
册数：暂无
重量：暂无
开本：16开
页数：316
出版时间：2022-03-01
条形码：9787121428111 ; 978-7-121-42811-1

本书特色

适读人群：本书适合对分布式感兴趣的读者面向初学者：通过理论和实践结合的方式介绍分布式系统，帮助读者夯实分布式基础知识；面向实践者：实现简单的Paxos共识算法，分析HDFS、ZooKeeper、etcd、Kubernetes等分布式系统案例。

内容简介

《深入理解分布式系统》主要讲解分布式系统常用的基础知识、算法和案例，经笔者对文献海洋中晦涩艰深的原理和算法进行提炼，辅以图示和代码，并结合实际经验进行分析总结而成。通过阅读本书，读者可以快速、轻松地掌握分布式系统的基本原理，以及Paxos或Raft共识算法，并通过典型的案例学习如何设计大型分布式系统。《深入理解分布式系统》首先介绍什么是分布式系统、分布式系统带来的挑战，以及如何对分布式系统进行建模，这部分内容偏向概念性介绍。接着介绍了分布式数据的基础知识，包括数据分区技术、数据复制技术、CAP定理、一致性模型和隔离级别，尝试厘清一些十分容易混淆的术语，比如一致性、线性一致性、*终一致性和一致性算法等。本书还介绍了分布式系统的核心算法——Paxos和Raft算法，不仅补充了大量图示进行讲解，还从零实现了一个Paxos算法。此外，本书分析了常见的分布式事务，并讨论了分布式系统中的时间问题，整理了一些实际发生的编程陷阱。*后结合一些对工业界产生重大影响的论文或开源系统，学习前人在设计大型分布式系统时的思路、取舍和创新。

第1章认识分布式系统 1.1 什么是分布式系统 1.2 为什么需要分布式系统 1.3 分布式系统的示例 1.3.1 搜索引擎 1.3.2 加密货币 1.4 分布式系统的挑战 1.4.1 网络延迟问题 1.4.2 部分失效问题 1.4.3 时钟问题 1.5 每个程序员都应该知道的数字 1.6 本章小结第2章分布式系统模型 2.1 两将军问题 2.2 拜占庭将军问题 2.3 系统模型 2.3.1 网络链路模型 2.3.2 节点故障类型 2.3.3 按时间划分系统模型 2.4 消息传递语义 2.5 本章小结第3章分布式数据基础 3.1 分区 3.1.1 水平分区算法 3.1.2 分区的挑战 3.2 复制 3.2.1 单主复制 3.2.2 多主复制 3.2.3 无主复制 3.3 CAP定理 3.3.1 PACELC定理 3.3.2 BASE 3.4 一致性模型 3.4.1 线性一致性 3.4.2 实现线性一致性 3.4.3 线性一致性的代价 3.4.4 顺序一致性 3.4.5 因果一致性 3.4.6 *终一致性 3.4.7 以客户端为中心的一致性模型 3.5 隔离级别 3.6 一致性和隔离级别的对比 3.7 本章小结第4章分布式共识 4.1 分布式共识简介 4.1.1 什么是分布式共识 4.1.2 为什么要达成共识 4.2 异步系统中的共识 4.2.1 FLP不可能定理 4.2.2 故障屏蔽 4.2.3 使用故障检测器 4.2.4 使用随机性算法 4.3 同步系统中的共识 4.4 Paxos 4.4.1 基本概念 4.4.2 问题描述 4.4.3 Paxos算法实现流程 4.4.4 案例 4.4.5 活锁 4.5 实验：使用Go语言实现Paxos共识算法 4.5.1 定义相关结构体 4.5.2 定义消息结构体 4.5.3 算法实现流程 4.5.4 学习提案 4.5.5 实现单元测试 4.6 Multi-Paxos 4.6.1 确定日志索引 4.6.2 领导者选举 4.6.3 减少请求 4.6.4 副本的完整性 4.6.5 客户端请求 4.6.6 配置变更 4.6.7 完整实现 4.6.8 Paxos练习题 4.7 其他Paxos变体 4.7.1 Disk Paxos 4.7.2 Cheap Paxos 4.7.3 Fast Paxos 4.7.4 Mencius 4.7.5 EPaxos 4.7.6 Flexible Paxos 4.7.7 WPaxos 4.7.8 CASPaxos 4.7.9 其他 4.8 Raft算法 4.8.1 系统模型 4.8.2 基本概念 4.8.3 领导者选举 4.8.4 日志复制 4.8.5 领导者更替 4.8.6 选举限制举例 4.8.7 延迟提交之前任期的日志条目 4.8.8 清理不一致的日志 4.8.9 处理旧领导者 4.8.10 客户端协议 4.8.11 实现线性一致性 4.8.12 配置变更 4.8.13 配置变更存在的Bug 4.8.14 极端情况下的活性问题 4.8.15 日志压缩 4.8.16 基于内存的状态机的快照 4.8.17 基于磁盘的状态机的快照 4.8.18 性能优化 4.8.19 Raft练习题 4.9 Paxos vs Raft 4.10 拜占庭容错和PBFT算法 4.11 本章小结第5章分布式事务 5.1 什么是分布式事务 5.2 原子提交 5.2.1 两阶段提交 5.2.2 三阶段提交 5.2.3 Paxos提交算法 5.2.4 基于Quorum的提交协议 5.2.5 Saga事务 5.3 并发控制 5.3.1 两阶段锁 5.3.2 乐观并发控制 5.3.3 多版本并发控制 5.4 Percolator 5.5 本章小结第6章时间和事件顺序 6.1 物理时钟 6.2 时钟同步 6.3 逻辑时钟 6.4 向量时钟 6.5 分布式快照 6.6 本章小结第7章案例研究 7.1 分布式文件系统 7.1.1 GFS的目标 7.1.2 架构 7.1.3 读取文件 7.1.4 写入文件 7.1.5 一致性模型 7.1.6 其他 7.2 分布式协调服务 7.2.1 ZooKeeper架构 7.2.2 数据模型 7.2.3 ZooKeeper实现 7.2.4 客户端API 7.2.5 其他 7.3 分布式表格存储Bigtable 7.3.1 数据模型 7.3.2 架构 7.3.3 SSTable和LSM Tree 7.3.4 其他优化 7.4 分布式键值存储Dynamo 7.4.1 架构 7.4.2 请求协调 7.4.3 成员管理和故障检测 7.5 分布式NoSQL数据库Cassandra 7.5.1 数据模型 7.5.2 架构 7.5.3 协调请求 7.5.4 一致性级别 7.5.5 轻量级事务 7.5.6 二级索引 7.5.7 批处理 7.6 分布式数据库Spanner 7.6.1 数据模型 7.6.2 架构 7.6.3 TrueTime 7.6.4 读写事务 7.6.5 只读事务 7.6.6 快照读和模式变更事务 7.7 分布式批处理 7.7.1 MapReduce 7.7.2 Spark 7.8 分布式流处理框架Flink 7.8.1 计算模型 7.8.2 系统架构 7.8.3 时间处理 7.8.4 分布式快照 7.8.5 端到端的精确一次语义 7.9 本章小结

展开全部

节选

原子提交在分布式领域更普遍地被称为提交问题（The Commit Problem）。事务的一大好处就是保证了原子性，所有的操作要么都执行，要么都不执行（All Or Nothing）。原子性可以说是事务*重要的特性，软件开发人员依靠事务的原子性，能够安全地将一系列相关的、不可分割的操作组合成一个整体，实现许多业务需求。但保证原子性并非易事—不仅仅是在分布式系统中，在单机系统中亦如此。原因是原子性涉及了硬件和软件，而两者都可能出现意外故障。即使是向文件中写入一些简单的字节，也需要额外的工作来保证写入的原子性，保证即使硬盘在执行写入操作的时候出现故障，文件也不会被损坏。我们先简单回顾单机事务的原子性的实现。常见的机械磁盘一般可以保证512字节的原子写，所谓原子写也就是说，即便遭遇突然断电等意外情况，一般的机械磁盘也可以保证当前512字节的成功写入；如果写入的数据大于512字节，则原子写得不到保障。为了在更通用的情况下实现原子性，常见方法是使用日志或WAL这类技术。简单地说，先将操作的元数据写入一个单独的日志文件，同时还有表示操作是否完成的标记。倘若系统在写入过程中发生故障，那么基于这些数据，系统恢复后依然能够识别出哪些操作在故障发生前已完成，然后通过撤销所有的操作来回滚事务；或者通过完成剩余未执行的操作来继续提交事务。基于硬盘原子写和日志文件来实现事务原子性的方法，在文件系统和数据库中广泛使用。但分布式系统中的原子性问题更加复杂，因为节点分布在不可靠的网络中。此外，我们不仅需要确保一个操作在一个节点上的原子性，还要确保一个操作在多个节点上的原子性，也就是说，操作要么在所有的节点上都生效，要么不在任何一个节点上生效，每个节点提交或中止事务的操作要保持一致。我们还是用银行转账来举例。假设一个分布式系统中的两台服务器，用户A的账户余额存储在服务器N1上，用户B的账户余额存储在服务器N2上，他们的账户上都有100元。接下来用户A要转账10元给用户B，事务需要同时修改用户A和用户B的数据。假设事务先给服务器N2上用户B的账户加上10元，再给服务器N1上用户A的账户减去10元。由于数据分布在两台完全不同的服务器上，很可能出现一些意想不到的故障，可能在给用户B的账户加上10元后，服务器N1宕机了，无法对用户A扣钱；甚至服务器没有宕机也可能触发异常，例如可能在请求服务器N1的时候发现用户A的账户余额已经不足10元了，不能再对用户A的账户减去10元（数据库约束账户不能为负数）。不管怎样，服务器N1没有完成它在事务中的那部分工作，但服务器N2又完成了它的任务。分布式事务的原子性通过原子提交协议（Atomic Commit Protocol，ACP）来实现，原子提交协议也叫原子提交算法，原子提交协议必须满足以下三个特性： ?? 协定性（Agreement）。所有进程都决议出同一个值，相当于所有进程要么一起提交事务，要么一起中止事务，不存在两个进程一个提交事务另一个中止事务的情况。 ?? 有效性（Validity）。如果所有进程都决定提交事务并且没有任何故障发生，那么*终整个系统将提交事务；只要有一个进程决定中止事务，系统*终将中止事务。 ?? 终止性（Termination）。终止性又分为弱终止条件（Weak Termination Condition）和强终止条件（Strong Termination Condition）。弱终止条件是指，如果没有任何故障发生，那么所有进程*终都会做出决议（提交或终止事务）；强终止条件也称为非阻塞条件（Non-Blocking Condition），是指没有发生故障的进程*终会做出决议。满足强终止条件的提交算法被称作非阻塞提交算法，而满足弱终止条件但不满足强终止条件的提交算法被称作阻塞提交算法。值得注意的是，协定性约束了两个进程不能决议出不同的值，因此，原子提交协议严格不允许一个出错的进程和一个正确的进程做出不同的决定。如果一个进程出错一段时间后又恢复，则会导致提交算法出现不一致。其实从这三个特性可以看出，原子提交协议实际上解决了分布式共识问题（见第4章）的一个子类，即对事务的提交或中止达成共识。