从Paxos到Zookeeper 分布式一致性原理与实践
从Paxos到Zookeeper 分布式一致性原理与实践
第一章 分布式架构
集中式到分布式
—分布式特点
- 分布性
分布式系统中的多合计算机都会在空问上随意分布，同时，机器的分布情况也会随 时变动。 - 对等性
分布式系统中的计算机没有主/ 从之分，既没有控制整个系统的主机，也没有被控 制的从机，组成分布式系统的所有计算机节点都是对等的。副本(Rcplica )是分布 式系统最常见的概念之一，指的是分布式系统对数据和服务提供的 一种冗氽方式。 在常见的分布式系统中，为了对外提供高可用的服务，我们往往会对数据和服务进 行副本处理。数据副本是指在不同的节点上持久化同一份数据，当某一个节点上存 储的数据丟失时，可以从副本上读取到该数据，这是解决分布式系统数据丟失问题 最为有效的手段。另一类副本是服务副本，指多个节点提供同样的服务，每个节点 都有能力接收来自外部的请求并进行相应的处理。 - 并发性
在“问题的提出” 部分，我们已经提到过与“更新的并发性” 相关的内容。在一个 计算机网络中，程序运行过程中的并发性操作是非常常见的行为，例如同 一个分布 式系统中的多个节点，可能会并发地操作一些共享的资源，诸如数据库或分布式存 储等，如何准确并高效地协调分布式并发操作也成为 了分布式系统架构与设计中最 大的 挑 战 之一 。 - 缺乏全局时钟
在上面的讲解中，我们已经了解到， 一个典型的分布式系统是由 一系列在空间上随 意分布的多个进程组成的，具有明显的分布性，这些进程之间通过交换消, 息来进行 相互通信。因此，在分布式系统中，很难定义两个事件究竟谁先谁后，原因就是因 为分布式系统缺乏 一个全局的时钟序列控制。 - 故障总是会发生
组成分布式系统的所有计算机，都有可能发生任何形式的故障。 一个被大量工程实 践所检验过的黄金定理是:任何在设计阶段考虑到的异常情况， 一定会在系统实际 运行中发生，并且，在系统实际运行过程中还会遇到很多在设计时未能考虑到的异 常放障。所以，除非需求指标元许，在系统设计时不能放过任何异常情况。
—分布式问题
通行异常
网络分区
三态
节点故障
ACID 到 CAP/BASE
— ACID
— 分布式事务
— CAP理论
CAP理论告诉我们，一个分布式系统不可能同时满足 一致性(C:Consistency)、可用性 .(A: Availability)和分区容错性(P: Partitiontolerance)这三个基本需求，最多只能同
时满足其中的两项。
一致性
在分布式环境中，一致性是指数据在多个副本之间是否能够保特 一致的特性。在 一致性 的需求下，当一个系统在数据 一致的状态下执行更新操作后，应该保证系统的数据仍然 处 于一 致 的 状 态 。可 用性
可用性是指系统提供的服务必须一直处 于可用的状态，对于用户的每一个操作请求总是 能够在有限的时间内返回结果。分区容错性
分区容错性约束 了 一个分布式系统需要具有如 下特性:分布式系统在遇到任何网络分区
放障的时候，仍然需要能够保证对外提供满足 一致性和可用性的服务，除非是整个网络 环境都发生了故障。
— BASE理论
基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性—一但请注 意，这绝不等价于系统不可用。以下两个就是“基本可用” 的典型例子。
- • 响应时间上的损失:正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户 相应的查询结果，但由于出现故障 (比如系统部分机房发生断电或断网故障)，查 询结果的响应时间增加到了1~ 2秒。
- • 功能上的损失:正常情况下，在一个电子商务网站上进行购物，消费者几乎能够 顺利地完成每一 笔订单，但是在一些书日大促购物高峰的时候，由 于消贵者的购 物行为激增，为了保护购物系统的稳定性，部分消贺者可能会被引1导到一个降级 页面。
弱状态
弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该 中间状态的存在不会影响系统的整体可用性，即元许系统在不同节点的数据副本之间进 行数据同步的过程存在延时。
最终一致性
最终 一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到 一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而 不需要实时保证系统数据的强 一致性。
最终一致性变种
最终 一致性存在以下五类主要变种。
- 因果一致性 ( Causal consistency )
因 果 一 致 性 是 指 ， 如 果 进 程 A 在 更 新 完 某 个 数 据 项 后 通 知 了进 程 B ， 那 么 进 程 B 之 后 对 该 数 据 项 的 访 问 都 应 该 能 够 获 取 到 进 程 A 更 新 后 的 最 新 值 ，并 且 如 果 进 程 B 要对该数据项进行更新操作的话，务必基于进程 A 更新后的最新值，即不能发生 丟失更新情况。与此同时，与进程^ 无因果关系的进程C的数据访问则没有这样 的限制。 - 读己之所写( Read rour writes )
该己之所写是指，进程^ 更新一个数据项之后，它自己总是能够访问到更新过的 垠新值，而不会吞到旧值。也就是说，对于单个数据获取者来说，其谈取到的数据， 一定不会比自己上次写人的值1旧。因此，读己之所写也可以看作是 一种特殊的因果 一致性。 - 会话一致性( Session consistency)
会话一致性;将对系统数据的访问过程框定在了一个会话当中:系统能保证在同一 个 有效的会话中实现“谈己之所写” 的一致性，也就是说，执行更能操作之后，容户 端能够在同 一个会话中始终读取到该数据项的最新值。 - 单调读一致性(Monotonicreadconsisrener ) 单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统 对于该进程后续的任何数据访问都不应该返回更旧的值。
- 单调写一致性 ( Monotonic write consistency )
单调写 一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序地执行。
第二章 一致性协议
2PC 和 3PC
Paxos算法
第三章 Psxos工程实践
Chubby
HyperTable
第四章 Zookeeper 与 Paxos
第五章 使用Zookeeper
实践应用 – 使用指南进行查阅
第六章 Zookeeper的典型应用场景
重点应用。
典型应用场景和实现：
–Push / Pull模式 - 订阅/发布
Zookeeper 采用的是推拉相结合的方式:客户端向服务端注册 自己需要关注的节点，一旦该节点的数据发生变更，那么服务端就会向相应的客户端发 送Watcher 事件通知，客户端接收到这个消息通知之后，需要主动到服务端获取最新的 数据。
—实现方式
推送（Push）方式的实现方式：
在推送方式下，服务注册中心会主动向感兴趣的服务提供更新的通知，并推送新的服务状态或配置信息。
通知机制：服务注册中心通过一种通知机制将更新信息推送给服务。这个通知机制可以基于长连接、轮询、事件回调等方式实现。
长连接方式：服务注册中心与服务之间建立长连接，保持通信通道的打开状态。当更新事件发生时，注册中心通过已建立的长连接直接将信息推送给服务。
轮询方式：服务定时向注册中心查询是否有更新事件发生。注册中心保留服务的连接信息，在有更新时回应服务的请求，并将新的信息一起返回。
事件回调方式：服务在注册时提供回调函数，注册中心在有更新事件时调用服务提供的回调函数，通知服务更新。
拉取（Pull）方式的实现方式：
在拉取方式下，服务需要主动向注册中心请求获取最新的服务状态或配置信息。
轮询方式：服务定时向注册中心拉取最新的信息。服务通过一定的轮询周期和频率，不断向注册中心发送请求以获取最新的信息。
定时触发方式：服务根据一定的策略和定时器，在特定的时间点触发请求，从注册中心获取最新的信息。
需要注意的是，推送方式和拉取方式并非是互斥的，往往可以结合使用。例如，在关键时刻或特定的事件发生时，使用推送方式实时通知服务；而在正常情况下使用拉取方式保持更新，以降低服务端的负载。具体的实现方式可以根据系统需求和技术栈的选择进行定制。
—优缺点：
服务发现可以通过两种主要方式实现：push（推送）和pull（拉取）。下面是它们各自的优缺点：
Push（推送）实现方式：
优点：
- 实时性好：当服务的状态或配置信息发生变化时，服务注册中心可以立即将更新推送给感兴趣的服务。
- 减轻服务压力：服务注册中心负责推送更新信息，服务不需要主动去轮询或拉取，减轻了服务的负担。
- 简化配置：服务可以只关注接收到的变更信息而不需要维护与服务注册中心的长连接。
缺点：
- 实现复杂：推送机制需要建立和维护客户端与服务注册中心之间的长连接，这对于一些网络环境较差或需要考虑安全性的场景来说相对复杂。
- 可靠性问题：由于推送是异步的，可能存在消息丢失或传递延迟的风险，导致部分服务错过更新。
Pull（拉取）实现方式：
优点：
- 简单可靠：相对于推送方式，拉取方式更简单，而且服务可以确定地在拉取更新后执行相应的操作，保证了可靠性。
- 适用性广：拉取机制适用于各种网络环境，不需要长连接和异步推送。
缺点：
- 延迟较高：因为服务需要主动去轮询或拉取更新，所以拉取方式相对于推送方式可能存在一定的延迟。
- 增加负载：轮询频率过高会增加服务的负载，特别是当集群规模较大时，服务注册中心可能会面临较高的请求负载。
综上所述，推送方式适用于要求实时性较高的场景，可以减轻服务的压力，但实现上比较复杂和容易受到传输延迟的影响。拉取方式相对简单可靠，适用于各种网络环境，但可能会导致一定的轮询延迟和增加服务负载。根据具体的系统需求和场景特点，选择适合的实现方式更加合适。
–负载均衡
大型分布式系统中的应用：
–Hadoop
第七章 Zookeeper技术内幕
原理剖析