raft

原文地址: HTTP JSON API through the gRPC gateway etcd v3 使用 gRPC 作为消息协议。etcd项目包括一个基于gRPC的 Go客户端 和一个命令行工具， etcdctl ,通过gRPC与etcd集群进行交互.对于没有gRPC支持的语言，etcd提供JSON gRPC网关 ，这个网关提供一个RESTful风格的代理可以将HTTP/JSON请求转换为gRPC消息。 使用 gRPC网关 这个网关接受一个到etcd's buffer协议消息定义的JSON格式的映射,注意 Key 和 Value 字段定义为byte 数组，因此JSON必须使用base64编码,下面的例子使用 curl ,但是每个HTTP/JSON客户端的工作原理都和例子相同。 注意 gRPC网关节点从etcd v3.3发生变化： etcd v3.2以及之前版本只使用 [CLIENT-URL]/v3alpha/* 。 etcd v3.3使用 [CLIENT-URL]/v3beta/* 保持 [CLIENT-URL]/v3alpha/* 使用。 etcd v3.4使用 [CLIENT-URL]/v3/* 保持 [CLIENT-URL]/v3beta/* 使用。 [CLIENT-URL]/v3alpha/* 被抛弃使用。 etcd v3.5以及最新版本只使用 [CLIENT-URL

Raft Raft概述 Raft一致性算法用于保证在分布式的条件下，所有的节点可以执行相同的命令序列，并达到一致的状态。这类的问题可以归结为“Replicated state machines”问题。 Raft一致性算法的保证 Raft特点 相比于Paxos，Raft最大的特点就是可理解性。相信读过Paxos论文的人应该对此深有体会。 Raft把一致性问题，分解成三个比较独立的子问题，并给出每个子问题的解决方法： 选举：描述Raft是如何选择一个leader的，这个部分很受容易理解了。 日志复制：描述Raft的leader是如何把日志复制到集群的各个节点上的。 安全性：描述Raft是如何保证“State Machine Safety Property”。 参考 官方资源 （包括了论文、各个语言的实现、一些学习视频） 根据Raft论文整理的一个中文文章 一个概括性的中文PPT 中文翻译 Paxos 概述 Paxos 协议是一个解决分布式系统中，多个节点之间就某个值（提案）达成一致（决议）的通信协议 。它能够处理在少数派离线的情况下，剩余的多数派节点仍然能够达成一致 paxos两阶段提交 总体说来，paxos就是通过两个阶段确定一个决议： Phase1：确定谁的编号最高，只有编号最高者才有权利提交proposal； Phase2：编号最高者提交proposal

前言 上午一场模拟赛(发布前很久，因为这题题解太长了)，发现T3特别珂怕，打开题解，发现一行字: 不要再问了，再问就是CF 1240E 当场去世.jpg。 在下文中，我们记 \(A\) 为 \(a\) 数组中的最大值，在代码中就是 "_max" 。 题意简述 题目链接 给出一组 \(n\) 块木板以及它们的长度 \(a_i\) ，现在要切割出两块木板使之长度为 \(x\) ，切割 \(x\) 块木板使之长度为 \(y\) 。 求 \(x \times y\) 的最大值。 题解 基本思想 我们有一个非常美妙的使用二分的 \(\Theta(Aln_Alog_A)\) 的做法， 但是我们今天要说的是一个比它优秀的 \(\Theta(Aln_A)\) 的算法。 对于几乎所有的做法，都有两个显然的思想， 枚举 \(y\) ，然后计算 \(x\) ； 贪心地把长度为 \(l\) 的木板分解为 \(l = tx + ky + \delta, t \in [0, 2]\) 其中 \(\delta\) 越小越好。 有了这个思想以后我们还需要按照 \(l / y\) 的值对木板分块(即块的区间 \([ ky, (k+1)y )\) )。 接下来我们可以来进行一波分类讨论。 两个 \(x\) 在同一块木板中被切割出 我们记 \(p_1, p_2\) 为两个点，且 \(p_1\) 距离它所在块的右端点比

In raft paper section 5.4.2 If a leader crashes before committing an entry, future leaders will attempt to finish replicating the entry. However, a leader cannot immediately conclude that an entry from a previous term is committed once it is stored on a majority of servers. There could be a situation where an old log entry is stored on a majority of servers, yet can still be overwritten by a future leader. The author mentioned that to avoid the situation above To eliminate problems like the one in Figure 8, Raft never commits log entries from previous terms by counting replicas. Only log

作者：周振靖 之前的 TiKV 源码解析系列文章介绍了 TiKV 依赖的周边库，从本篇文章开始，我们将开始介绍 TiKV 自身的代码。本文重点介绍 TiKV 最外面的一层——Service 层。 TiKV 的 Service 层的代码位于 src/server 文件夹下，其职责包括提供 RPC 服务、将 store id 解析成地址、TiKV 之间的相互通信等。这一部分的代码并不是特别复杂。本篇将会简要地介绍 Service 层的整体结构和组成 Service 层的各个组件。 整体结构 位于 src/server/server.rs 文件中的 Server 是我们本次介绍的 Service 层的主体。它封装了 TiKV 在网络上提供服务和 Raft group 成员之间相互通信的逻辑。 Server 本身的代码比较简短，大部分代码都被分离到 RaftClient ， Transport ， SnapRunner 和几个 gRPC service 中。上述组件的层次关系如下图所示： 接下来，我们将详细介绍这些组件。 Resolver 在一个集群中，每个 TiKV 实例都由一个唯一的 store id 进行标识。Resolver 的功能是将 store id 解析成 TiKV 的地址和端口，用于建立网络通信。 Resolver 是一个很简单的组件，其接口仅包含一个函数： pub

1.1 简介 摘自coreos官网（etcd v3.2.17） https://coreos.com/etcd/docs/latest/ https://coreos.com/etcd/docs/latest/getting-started-with-etcd.html 1.1.1 概念 注意v2的版本对于linux系统默认仓库不再封装。对于最新的去github上下载。 官网中首先介绍什么是etcd A distributed, reliable key-value store for the most critical data of a distributed system 它是一套开源的可靠的分布式存储（即需要做cluster），用于存储key-value 键值对 同时它不仅仅是存储，它还提供共享配置及服务发现（后面这两个特征非常有特点，主要用于container中），对于leader的选举非常优秀，它的leader选举更换对于前端是无感知的。 应用容器读写数据在etcd上，除此还有支持快照及查看历史事件的功能。 下图是官网给出的etcd的功能及特点 etcd is the backend for service discovery and stores cluster state and configuration 1.1.2 数据模型 etcd的数据模型是非常有特点的。

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

Raft协议 Raft协议基于日志实现了一致性 实现备份的是机制：复制状态机Replicated State Machine,如果两个相同的、确定性的状态机从同一状态开始，以相同顺序输入相同的日志，则两个状态机最终也会保持一致 Raft了实现Consensus Module Consensus Module作为一致性模块对外服务，负责接收客户端的消息，响应请求，并追加到本地日志，一致性模块保证每个机器上的log的一致性 请求到来时，带上(term,commitindex)和append log 去要求Follower追加消息，Follower会先判断(term,index)是否和当前最大的消息相同，如果相同就会追加，否则会拒绝 一致性模块负责复制消息到其他服务器节点，本地日志commit成功后立即应用到状态机 CNew用于服务器增加或者减少节点的情况 Leader：处理与客户端交互，处理消息 Follower：选民，转发请求到leader Candidate:候选人，可以参选成为leader，不是所有Follower都能成为Candidate，只有数据较完整的才可以。如果Candidate发现自己的term落后了就会退回到Follower RequestVote:选举期间的RPC消息 AppendEntries:leader选出后向Follow复制日志的RPC消息

云里雾里，本篇将首先梳理一下 RocketMQ DLedger 多副本关于日志复制的三个核心流程图，然后再思考一下在异常情况下如何保证数据一致性。 1、RocketMQ DLedger 多副本日志复制流程图 1.1 RocketMQ DLedger 日志转发(append) 请求流程图 1.2 RocketMQ DLedger 日志仲裁流程图 1.3 RocketMQ DLedger 从节点日志复制流程图 2、RocketMQ DLedger 多副本日志复制实现要点 上图是一个简易的日志复制的模型：图中客户端向 DLedger 集群发起一个写请求，集群中的 Leader 节点来处理写请求，首先数据先存入 Leader 节点，然后需要广播给它的所有从节点，从节点接收到 Leader 节点的数据推送对数据进行存储，然后向主节点汇报存储的结果，Leader 节点会对该日志的存储结果进行仲裁，如果超过集群数量的一半都成功存储了该数据，主节点则向客户端返回写入成功，否则向客户端写入写入失败。 接下来我们来探讨日志复制的核心设计要点。 2.1 日志编号 为了方便对日志进行管理与辨别，raft 协议为一条一条的消息进行编号，每一条消息达到主节点时会生成一个全局唯一的递增号，这样可以根据日志序号来快速的判断数据在主从复制过程中数据是否一致，在 DLedger 的实现中对应