paxos

1.1. 一致性协议概述 前面已经讨论过，在分布式环境下，有很多不确定性因素，故障随时都回发生，也讲了 CAP 理论， BASE 理论 我们希望达到，在分布式环境下能搭建一个高可用的，且数据高一致性的服务，目标是这样，但 CAP 理论告诉我们要达到这样的理想环境是不可能的。这三者最多完全满足 2 个。 在这个前提下， P （分区容错性）是必然要满足的，因为毕竟是分布式，不能把所有的应用全放到一个服务器里面，这样服务器是吃不消的，而且也存在单点故障问题。 所以，只能从一致性和可用性中找平衡。 怎么个平衡法？在这种环境下出现了 BASE 理论： 即使无法做到强一致性，但分布式系统可以根据自己的业务特点，采用适当的方式来使系统达到最终的一致性； BASE 由 Basically Avaliable 基本可用、 Soft state 软状态、 Eventually consistent 最终一致性组成，一句话概括就是：平时系统要求是基本可用，除开成功失败，运行有可容忍的延迟状态，但是，无论如何经过一段时间的延迟后系统最终必须达成数据是一致的。 其实可能发现不管是 CAP 理论，还是 BASE 理论，他们都是理论，这些理论是需要算法来实现的，今天讲的 2PC 、 3PC 、 Paxos 算法， ZAB 算法就是干这事情。 所以今天要讲的这些的前提一定是分布式，解决的问题全部都是在分布式环境下

1.1 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 -临时顺序编号目录节点：客户端与zookeeper断开连接后，该节点被删除

“数据不能丢，服务不能停”，可以说这句话道出了用户对数据库的核心能力的要求。然而，传统的商业数据库必须依赖高可靠的硬件才能实现数据可靠性和服务可用性。OceanBase作为一款成熟的企业级分布式数据库，基于普通PC服务器，就能够做到传统高端硬件环境下的数据可靠性和服务可用性，而且还能做得更好！跟我们一起看看OceanBase的技术秘诀吧！ Part1 前言 说到数据可靠性和服务可用性，在数据库领域真是老生常谈的话题，可以说从数据库诞生之日起就如影随形。如果要用一句话来概括数据库对数据可靠性和服务可用性的要求，可以借用OceanBase数据库创始人阳振坤老师的一句话：“数据不能丢，服务不能停”。可以说，这句话也道出了用户对数据库的一个核心能力要求：除了功能完善、使用方便之外，还要绝对安全、足够健壮。可以说，为了满足这两个看似简单的要求，在数据库领域诞生了大量的技术和论文，也让无数人绞尽了脑汁。 在传统的商业数据库产品（如Oracle、DB2）中，虽然也有一些行之有效的软件技术（如Redo Log、主从热备技术等）用来提高数据可靠性和服务可用性，但整体来说对硬件的稳定性有很强的依赖。而传统的企业级服务器（如IBM 的Mainframe、AS400、Power等）和EMC、IBM等厂商的高端存储产品，能够很好的保证硬件的稳定性，因此也就成为了Oracle为代表的传统数据库产品的理想平台

问题 Paxos 到底解决什么样的问题，动机是什么 Paxos 流程是怎么样的？ Paxos 算法的缺陷是什么 概述 Paxos 是分布式一致性算法，根据少数服从多数的原则多个节点确定某个数值。通过学习 Base Paxos ，我们再进一步优化，提出了 Multi Paxos . 动机 我们先思考为什么会出现一致性问题，原因是我们原本使用一台机器，而使用多台机器后（分布式），发生网络延迟或是其他原因导致所有机器不能同时在线，分布式的好处为了让我们享有可用性的好处，但是多台同时也会带来一致性的问题，最好理解的就是MySQL 中的主从复制，当主在写入的时候从没来得及复制完毕，那么此时的读到的数据是和刚写入的值是不一致的，而过多一会再次读就可以读到正确的值，也就是上面讲到的主从复制保证的最终一致性，于是，起码来说分布式中要解决这两个问题 ： 部分机器挂了 一致性问题 我们来看一下wiki中关于 Paxos 的介绍 ： Paxos is a family of protocols for solving consensus in a network of unreliable processors (that is, processors that may fail). Consensus is the process of agreeing on one result among a

【ZOOKEEPER系列】Paxos、Raft、ZAB 2018-07-11 12:09:49 wangzy-nice 阅读数 2428 更多 分类专栏： zookeeper 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/qq_34370153/article/details/80998622 ZOOKEEPER系列 Paxos、Raft、ZAB Paxos算法 莱斯利·兰伯特（Leslie Lamport）这位大牛在1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。如果你不知道这个人，那么如果你发表过Paper，就一定用过Latex,也是这位大牛的创作， 具体背景直接维基百科就可以，不深入讲解，直接讲Paxos算法。 分布式系统对fault tolorence 的一般解决方案是state machine replication。准确的描述Paxos应该是state machine replication的共识（consensus）算法。 Leslie Lamport写过一篇Paxos made simple的paper，没有一个公式，没有一个证明，这篇文章显然要比Leslie Lamport之前的关于Paxos的论文更加容易理解，但是

　　Paxos是一种基于消息传递的分布式一致性算法，由Leslie Lamport（莱斯利·兰伯特）于1990提出。是目前公认的解决分布式一致性问题的最有效算法之一。 要解决的问题及应用场景 　　Paxos算法要解决的问题，可以理解为：一个异步通信的分布式系统中，如何就某一个值（决议）达成一致。 　　而此处异步通信是指，消息在网络传输过程中存在丢失、超时、乱序现象。 　　其典型应用场景为： 　　在一个分布式系统中，如果各节点初始状态一致，而且每个节点执行相同的命令序列，那么最后就可以得到一个一致的状态。为了保证每个节点执行相同的命令序列，即需要在每一条指令上执行一致性算法（如Paxos算法），来保证每个节点指令一致。 概念定义 　　Proposal：为了就某一个值达成一致而发起的提案，包括提案编号和提案的值。 　　涉及角色如下： 　　Proposer：提案发起者，为了就某一个值达成一致，Proposer可以以任意速度、发起任意数量的提案，可以停止或重启。 　　Acceptor：提案批准者，负责处理接收到的提案，响应、作出承诺、或批准提案。 　　Learner：提案学习者，可以从Acceptor处获取已被批准的提案。 约定 　　Paxos需要遵循如下约定： 　　1、一个Acceptor必须批准它收到的第一个提案。 　　2、如果编号为n的提案被批准了，那么所有编号大于n的提案

近来newsql大热，尤以TIDB最火，pingcap不断打磨TiDB，现如今版本已经迭代到3.0，产品已经基本趋于成熟。 对于TiDB，整体架构图如下图所示 是由四个模块组成，TiDB Server，PD Server，TiKV Server，TiSpark。 TiDB Server 负责接受SQL请求，处理SQL的相关逻辑，并通过PD找到存储计算所需数据的TiKV地址，与TiKV交互获取数据，最终返回结果。TiDB Server是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVD，HAPROXY，F5等）对外提供统一的接入地址。推荐部署俩个实例，前端通过负载均衡组件对外提供服务，当单个实例失效时，会影响正在这个实例上进行的session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。 Placement Driver (简称 PD)，是整个集群的管理模块，其主要的工作有三个，一是存储集群的元信息，（某个Key存储在哪个TiKV节点上）；二是对TiKV集群进行调度和负载均衡（如数据的迁移，Raft group leader的迁移等），三是分配全局唯一且递增的事务ID。PD 通过 Raft 协议保证数据的安全性。Raft 的 leader server 负责处理所有操作，其余的 PD server 仅用于保证高可用

前言 相信大家对 ZooKeeper 应该不算陌生。但是你真的了解 ZooKeeper 是个什么东西吗？如果别人/面试官让你给他讲讲 ZooKeeper 是个什么东西，你能回答到什么地步呢？ 我本人曾经使用过 ZooKeeper 作为 Dubbo 的注册中心，另外在搭建 solr 集群的时候，我使用到了 ZooKeeper 作为 solr 集群的管理工具。前几天，总结项目经验的时候，我突然问自己 ZooKeeper 到底是个什么东西？想了半天，脑海中只是简单的能浮现出几句话：“①Zookeeper 可以被用作注册中心。 ②Zookeeper 是 Hadoop 生态系统的一员；③构建 Zookeeper 集群的时候，使用的服务器最好是奇数台。” 可见，我对于 Zookeeper 的理解仅仅是停留在了表面。 所以，通过本文，希望带大家稍微详细的了解一下 ZooKeeper 。如果没有学过 ZooKeeper ，那么本文将会是你进入 ZooKeeper 大门的垫脚砖。如果你已经接触过 ZooKeeper ，那么本文将带你回顾一下 ZooKeeper 的一些基础概念。 最后，本文只涉及 ZooKeeper 的一些概念，并不涉及 ZooKeeper 的使用以及 ZooKeeper 集群的搭建。 网上有介绍 ZooKeeper 的使用以及搭建 ZooKeeper 集群的文章