paxos

一致性投票算法 ：（分布式网络系统）（共识算法） 过程： Paxos第一阶段：预提案(准备Perpare/诺言Promises) 　　　　提议者Proposer： 　　　　向接受者Acceptor广播预提案，附带接下来提案Proposal的proposal_id 　　接受者Acceptor： 　　　　收到预提案后更新a_proposal_id = max(proposal_id,a_proposal_id)，如果预提案的proposal_id>a_proposal_id，Acceptor回复记录的接受过的proposal_id最大的提案。 　　　　【第一阶段A：Proposer选择一个提议编号n，向所有的Acceptor广播Prepare（n）请求。 　　　　第一阶段B：Acceptor接收到Prepare（n）请求，若提议编号n比之前接收的Prepare请求都要大，则承诺将不会接收提议编号比n小的提议，并且带上之前Accept的提议中编号小于n的最大的提议，否则不予理会。】 Paxos第二阶段：提案阶段(Paoxs接纳Acceptance) 　　　　提议者Proposer： 　　　　　　等待直到收到大多数接受者对预提案的回复，从所有回复的提案组成的法定数目的提案集合K中挑选proposal_id最大的提案，以该提案的值作为本次提案的值。 　　　　　　如果K是空集

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

转自： https://cs.xieyonghui.com/architecture/35.html Paxos是唯一的一致性算法，其他都是paxos不完整版，Google Chubby作者Mike Burrows曾这样评价Paxos。 解决的问题 Paxos算法解决的问题：分布式系统如何就某个值（决议）达成一致。 历史 1990年Leslie Lamport提交Paxos算法论文The Part-Time Parliament，未受太多关注。 2001年发布通俗简化版 Paxos Made Simple ，剔除公式部分。 场景 爱琴海paxos岛住着一群居民，通过议会形式取代神权政治，事情由议会选举决定。 议员总数确定，岛上每个提议都有一个编号，编号不断增长且不能回退。 提议超半数议员同意就会生效。 每个议员有一个记事本，记录曾经同意过或通过的提议编号，编号随提议不断更新。 每个议员只会同意大于当前编号的提议。 若收到小于或等于当前编号的提议会拒绝提议并通知提出方。 岛上议员以义工方式出现，所以，不保证每个提议的投票在同一时间完成。因此，一定时间内议员们手中的编号并不统一。 议会目标： 议员们对提议达成一致看法。 投票 议会开始时，议员们手中记事本编号统一为0。 当议员发出提议时，先查看自己的记事本，在当前记录基础上加1，作为新提议编号，然后，通知其他议员。 其他议员们收到通知

Paxos Paxos是所有分布式环境中关于某个值达成一致的协议，Paxos 一个节点同时包括提议者和接受者。顾名思义：提议者是发起投票；接受者接受投票请求，根据投票请求和自身状态进行响应的回复。为了防止异常丢状态，Paxos在内部持久化三个参数：当前已接受的提案号；当前达成共识的value的值；当前最小的提案号。按照两阶段模式进行操作： 阶段一：Prepare(n) 请求 阻塞新来的老的提案 为什么可以这样？因为 分布式日志进来的时候，Acceptor 会把日志里带的请求里的提案号n和自己的最小提案号进行比较。如果前者大，会更新自己的最小的提案号，向提案者响应同意请求。 这样就保证了提案号小的IO请求永远不会得到Acceptor的响应，由于Propasl 的提案号都是递增的，保证了前者服从后者的原则。 提案者接受到了上面的请求之后，如果同意的数量达成了多数，接着广播Accept(n,val) 到所有Acceptor. 阶段二：Accept(n,val) Acceptor 在这个阶段，会把自己的最小提案号和请求中的提案号n 比较一次。原则同上面阶段一，同意之后：除了更新自己的最小提案号为n之外，还用n 更新自己的已接受提案号，向提议者返回自己当前的最小的提案号。如果不同意，也向提议者返回自己当前的最小的提案号，拒绝请求。 如果提案者收到任何关于Accept(n,val)的拒绝响应

本文转自： https://www.cnblogs.com/bangerlee/p/5991417.html 本文转自 https://www.cnblogs.com/bangerlee/p/5268485.html 本系列文章将整理到我在GitHub上的《Java面试指南》仓库，更多精彩内容请到我的仓库里查看 https://github.com/h2pl/Java-Tutorial 喜欢的话麻烦点下Star哈 文章首发于我的个人博客： www.how2playlife.com 该系列博文会告诉你什么是分布式系统，这对后端工程师来说是很重要的一门学问，我们会逐步了解分布式理论中的基本概念，常见算法、以及一些较为复杂的分布式原理，同时也需要进一步了解zookeeper的实现，以及CAP、一致性原理等一些常见的分布式理论基础，以便让你更完整地了解分布式理论的基础，为后续学习分布式技术内容做好准备。 如果对本系列文章有什么建议，或者是有什么疑问的话，也可以关注公众号【Java技术江湖】联系作者，欢迎你参与本系列博文的创作和修订。 <!-- more --> 引言 《分布式系统理论进阶 - Paxos》 介绍了一致性协议Paxos，今天我们来学习另外两个常见的一致性协议——Raft和Zab。通过与Paxos对比，了解Raft和Zab的核心思想、加深对一致性协议的认识。 Raft