paxos算法

目录 6.2 Zookeeper在大型分布式系统中的应用 6.2.1 Hadoop YARN介绍 如何解决ResourceManager单点问题，实现高可用？ 6.2.3 Kafka 术语介绍 问题 Kafka与Zookeeper Broker注册管理 Topic注册管理 生产者负载均衡 消费者负载均衡 消费分区与消费者关系 消息消费进度Offset记录 消费者注册 负载均衡 1）Range策略 2）RoundRobin策略 资料 6.3 Zookeeper在阿里巴巴的实践与应用 6.3.2 案例二 RPC服务框架：Dubbo 服务提供者 服务消费者 监控中心 6.3.3 案例三 基于MySQL Binlog的增量订阅和消费组件：Canal Canal基本工作原理 Canal Server主备切换设计 Canal Client的HA设计 6.3.4 案例四 分布式数据库同步系统：Otter 分布式SEDA模型 数据模型 任务处理流程(多阶段任务协调处理) 6.2 Zookeeper在大型分布式系统中的应用 6.2.1 Hadoop YARN介绍 YARN是Hadoop为了提高计算节点的扩展性，同时为了支持多计算模型和提供资源的细粒度调度而引入的全新一代分布式协调框架。 核心为ResourceManager，资源管理中心，负责集群中所有资源的统一管理和分配。 （可理解为YARN的大脑

一．Spanner功能概要 Spanner具有 高扩展性 ， 多版本 （multi-version）、 世界级分布 （globally-distributed）及 同步复制 （synchronously-replicated）等特性。 Spanner立足于高抽象层次，使用Paxos协议横跨多个数据集把数据分散到世界上不同数据中心的状态机中。世界范围内响应，出故障时客户副本之间的自动切换。当数据总量或服务器的数量发生改变时，为了平衡负载和处理故障，Spanner自动完成数据的重切片和跨机器（甚至跨数据中心）的数据迁移。 Spanner可以轻松的横跨数百个数据中心将万亿级数据库行扩展到数百万台机器中。高可靠性更是让应用程序如虎添翼，即使面对大范围的自然灾害，可靠性仍然能得到良好的保障（因为Spanner有着世界级的数据转移）。最初的用户来自F1 — 使用了美国境内的5个拷贝。多数其他应用程序都是在同一个地理区域将数据复制3到5份，使用相对独立的故障模式。也就是说多数的应用程序会选择低延迟超过高有效性，只用一两个数据中心来保障数据的可靠性。 Spanner的 主旨是数据中心的管理 ，但是在分布系统基础设施的特色上同样是下足了功夫。尽管Bigtable很讨一些项目欢心，我们还是收到了一些Bigtable在某些应用程序（复杂的、不断变化的架构或者需要在大区域响应中保持强一致性

 介绍常见的分布式一致性协议 一．CAP/BASE 1. CAP理论  CAP理论又称之为布鲁尔定理（Brewer’S theorem），认为在设计一个大规模可扩放的网络服务时候不能同时兼容：一致性（consistency）、可用性（Availability）、分区容错（Partition-tolerance）。  一致性：在分布式系统中的所有数据备份，在同一时刻是否有同样的值。（等同于所有节点访问同一份最新的数据副本）  可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。  分区容忍性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择  CAP理论容易理解，网上也有关于该理论的说明，包括模型的简易证明；弱条件下模型的成立等。  参考资料： http://www.cnblogs.com/mmjx/archive/2011/12/19/2290540.html http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html 2. BASE理论  BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写

在分布式算法领域，有个非常重要的算法叫Paxos, 它的重要性有多高呢，Google的Chubby [1]中提到 all working protocols for asynchronous consensus we have so far encountered have Paxos at their core. 关于Paxos算法的详述在维基百科中有更多介绍，中文版介绍的是choose value的规则[2]，英文版介绍的是Paxos 3 phase commit的流程[3]，中文版不是从英文版翻译而是独立写的，所以非常具有互补性。Paxos算法是由Leslie Lamport提出的，他在Paxos Made Simple[4]中写道 The Paxos algorithm, when presented in plain English, is very simple. 当你研究了很长一段时间Paxos算法还是有点迷糊的时候，看到上面这句话可能会有点沮丧。但是公认的它的算法还是比较繁琐的，尤其是要用程序员严谨的思维将所有细节理清的时候，你的脑袋里更是会充满了问号。Leslie Lamport也是用了长达9年的时间来完善这个算法的理论。 实际上对于一般的开发人员，我们并不需要了解Paxos所有细节及如何实现，只需要知道Paxos是一个分布式选举算法就够了

本文转载自：https://www.cnblogs.com/felixzh/p/5869212.html Zookeeper的功能以及工作原理 1.ZooKeeper是什么？ ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户 2.ZooKeeper提供了什么？ 1)文件系统 2)通知机制 3.Zookeeper文件系统 每个子目录项如 NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。 有四种类型的znode： 1、PERSISTENT-持久化目录节点 客户端与zookeeper断开连接后，该节点依旧存在 2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点 客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 3、EPHEMERAL-临时目录节点 客户端与zookeeper断开连接后，该节点被删除 4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点