raft

本文介绍Ocelot中的服务发现（Service Discovery），Ocelot允许指定一个服务发现提供器，之后将从中寻找下游服务的host和port来进行请求路由。 关于服务发现的详细介绍请 点击 。 在Ocelot中使用了 Consul 作为服务发现的provider。 1、Consul下载安装 从 官方下载页 选择合适的平台下载，解压出一个二进制文件并保存到相应位置，并将路径存入path中，本文以windows版本为例（其他平台操作类似）。 打开 cmd/powershell 运行 consul agent -dev 输出如下文本表示成功以dev方式启动consul ==> Starting Consul agent... ==> Consul agent running! Version: 'v1.0.7' Node ID: '3fc1edca-b635-56cc-b767-01a942423f73' Node name: 'Weidaicheng-PC' Datacenter: 'dc1' (Segment: '<all>') Server: true (Bootstrap: false) Client Addr: [127.0.0.1] (HTTP: 8500, HTTPS: -1, DNS: 8600) Cluster Addr: 127.0.0.1 (LAN:

https://www.cnblogs.com/xybaby/p/10124083.html 正文   raft是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。在这里强调了是在工程上，因为在学术理论界，最耀眼的还是大名鼎鼎的Paxos。但Paxos是：少数真正理解的人觉得简单，尚未理解的人觉得很难，大多数人都是一知半解。本人也花了很多时间、看了很多材料也没有真正理解。直到看到raft的论文，两位研究者也提到，他们也花了很长的时间来理解Paxos，他们也觉得很难理解，于是研究出了raft算法。    raft是一个共识算法（consensus algorithm），所谓共识，就是多个节点对某个事情达成一致的看法，即使是在部分节点故障、网络延时、网络分割的情况下。这些年最为火热的加密货币（比特币、区块链）就需要共识算法，而在分布式系统中，共识算法更多用于提高系统的容错性，比如分布式存储中的复制集（replication），在 带着问题学习分布式系统之中心化复制集 一文中介绍了中心化复制集的相关知识。raft协议就是一种leader-based的共识算法，与之相应的是leaderless的共识算法。   本文基于论文 In Search of an Understandable Consensus Algorithm 对raft协议进行分析，当然，还是建议读者直接看论文。

Paxos Paxos总共有三个角色 1:提议者（Proposers） 2:接受者（Acceptors） 3:学习者（Learns） 一致性的目标是一组参与者在每次商议中对一个值形成共同的共识。 从Propsers提交值给一组Acceptors开始就开启一次一致性商议，Acceptors在接受某次提案的值，并且超过某次阀值后，这个值就会在网络中传播。 为了让Paxos协议能正常工作，第一个约束是： Acceptors必须接受它收到的第一个提案的值。 这会导致一个问题，考虑一下这个情况，多个Proposers发送提案的值，多个Acceptors接收到多个值。因为Acceptors只接收第一个收到的值，所以形成不了 大多数结果。Paxos给每次的提案附加唯一的标记来允许Acceptors同时接收到多个提案。 对每次提案附加一个唯一标记，某次提案过程中，如果大多数Acceptors接受提案的值，这个值就叫做chosen value。可以通过多个提案，但是必须保证 多个提案对于同一个值有相同的值。这样就引出第二个约束： 如果已经选择了提案的值 V，每次更高的提案都必须选择值 V。 网络通讯异步进行，所以会存在某些Acceptors未收到chosen value，但是这个并不会违反约束1和约束2. Propsers在发送消息给acceptors时使用如下几个约束。这个过程叫做prepare

　　Consul 是一套开源的分布式服务发现和配置管理系统，由 HashiCorp 公司用 Go 语言开发。它具有很多优点。包括：基于 raft 协议，比较简洁； 支持健康检查, 同时支持 HTTP 和 DNS 协议 支持跨数据中心的 WAN(广域网) 集群 提供图形界面 跨平台，支持 Linux、Mac、Windows。 　　consul是使用go语言开发的服务发现、配置管理中心服务。内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如 ZooKeeper 等）。服务部署简单，只有一个可运行的二进制的包。每个节点都需要运行agent，他有两种运行模式server和client。每个数据中心官方建议需要3或5个server节点以保证数据安全，同时保证server-leader的选举能够正确的进行。 　　raft（分布式一致性协议）：见《 一致性算法之：Raft 》　 　　@client 　　CLIENT表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到SERVER，本身是不持久化这些信息。 　　@server 　　SERVER表示consul的server模式，表明这个consul是个server，这种模式下，功能和CLIENT都一样

分布式一致性理论 CAP 理论 一个分布式系统 不可能同时满足 一致性（ C:Consistency )，可用性（ A: Availability ）和分区容错性（ P：Partition tolerance ）这三个基本需求， 最多只能同时满足其中的 2 个 。 如下： 选项 描述 C(Consistence) 一致性 ，指数据在多个副本之间能够保持一致的特性（ 严格的一致性 ）。 A(Availability) 可用性 ，指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。 P(Network partitioning) 分区容错性 ，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。 Base 理论 BASE 是 Basically Available (基本可用) ，Soft state （软状态）,和 Eventually consistent （最终一致性）三个短语的缩写。 既是无法做到 强一致性 （ Strong consistency ），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到 最终一致性 （ Eventual consistency ） 基本可用 允许出现响应时间损失或者功能损失。 软状态 允许系统中的数据存在中间状态

参考： Paxos协议基本原理， http://blog.csdn.net/malefactor/article/details/51365744 微信PaxosStore：深入浅出Paxos算法协议， http://www.infoq.com/cn/articles/wechat-paxosstore-paxos-algorithm-protocol 分布式一致性算法--Paxos， https://www.cnblogs.com/cchust/p/5617989.html 前言 Paxos 一致性协议可以说是一致性协议研究的起点，也以难以理解闻名。其实协议本身并没有多难理解，它的难理解性主要体现在：为何如此设计协议以及如何证明其正确性。本文尝试通过流程图来说明协议的内容以及基本应用过程，不涉及如何证明其正确性。 基本概念 Paxos 可以分为两种： Single-Decree Paxos ：决策单个 Value Multi-Paxos ：连续决策多个 Value，并且保证每个节点上的顺序完全一致，多 Paxos 往往是同事运行多个单 Paxos 协议共同执行的结果。 本文只关注单 Paxos 的原理，理解了单 Paxos，多 Paxos 也就不难理解了。 Paxos 协议中的三种角色 倡议者（Proposer） ：倡议者可以提出提议（数值或者操作命令）以供投票表决 接受者

SOFAStack （ S calable O pen F inancial A rchitecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 本文为《剖析 | SOFAJRaft 实现原理》最后一篇，本篇作者胡宗棠，来自中国移动。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号： SOFA:JRaftLab/ ，文末包含往期系列文章。 SOFAJRaft： https://gitee.com/sofastack/sofa-jraft 导读 本文主要介绍 SOFAJRaft 在日志复制和管理中所采用的快照机制。考虑到单独介绍 SOFAJRaft 中的快照机制原理和实现或许有一些唐突，我会先通过一个读者都能够看得明白的例子作为切入点，让大家对快照这个概念、它可以解决的主要问题，先有一个比较深刻的理解。 一、快照的概念与特点 SOFAJRaft 是对 Raft 共识算法的 Java 实现。既然是共识算法，就不可避免的要对需要达成共识的内容，在多个服务器节点之间进行传输，一般将这些共识的内容称之为日志块

Paxos算法 Paxos算法是解决分布式系统中如何就某个值达成协议。典型的场景就是选举主机，zookeeper选举主机使用的zab算法就是Paxos的一个实现。 Paxos的三个角色 Proposer：提议者，提出方案的角色 Acceptor：接受者，接收方案的角色 Learner：学习者，确定接受者是否超过半数的节点同意某个提案 Paxos分为三个阶段 阶段1：发送编号 每一个提议者都会提供一个编号N，并先半数以上的接受者发送编号。 接受者接收到编号后，用伪代码表示 Integer N_p； //提议者编号 Object V_p ; //提议者提案 Integer N_a ; //接受者编号 Object V_a ; //接受者提案 if ( N_a == null ) { //接收者没有接受过编号 N_a = N_p ; } else if ( N_p < N_a ) { //提议者的编号小于接收者的编号，拒绝提议者的编号 return ; } else { //接受提议者的编号 N_a = N_p ; if ( V_a != null ) { //额外的，如果接受者已经有提案了，那么提议者将自己的提案设置为接受者的提案，否则提议者会在阶段二自己定义提案 V_p = V_a； } } 阶段2：发送提案 提议者再次给接受者发送提案 Integer N_p； //提议者编号

etcd raft选举机制 etcd 是一个分布式的k/V存储系统。核心使用了RAFT分布式一致性协议。一致性这个概念，它是指多个服务器在状态达成一致，但是在一个分布式系统中，因为各种意外可能，有的服务器可能会崩溃或变得不可靠，它就不能和其他服务器达成一致状态。这样就需要一种Consensus协议，一致性协议是为了确保容错性，也就是即使系统中有一两个服务器当机，也不会影响其处理过程。 为了以容错方式达成一致，我们不可能要求所有服务器100%都达成一致状态，只要超过半数的大多数服务器达成一致就可以了，假设有N台服务器，N/2 +1 就超过半数，代表大多数了。 raft协议核心要点： Leader选举（Leader Election） 日志同步 （Log Replication） leader收到client的更新请求后，会讲更新的内容同步给所有follower。 集群状态的正确性 （Safety） 保证日志的一致性 保证选举的正确性 服务器状态： leader 处理所有客户端交互，日志复制等，一个任期只有一个。 follower 完全被动的选民，是只读的。 candidate 候选人，可以被选举为新领导。 状态之间的转换： 任期（terms） 如上图，蓝色代表 Election 模式，绿色代表 Operation 模式 在每个任期内最多一个leader 有些可能没有leader

After reading paxos and raft paper, I have following confusion: paxos paper only describe consensus on single log entry, which is equivalent the leader election part of the raft algorithm. What's the advantage of paxos's approach over the simple random timeout approach in raft's leader election? It is a common misconception that the original Paxos papers don't use a stable leader. In Paxos Made Simple on page 6 in the section entitled “The Implementation” Lamport wrote: The algorithm chooses a leader, which plays the roles of the distinguished proposer and the distinguished learner. This is