raft

etcd：从应用场景到实现原理的全方位解读 从etcd的架构开始，深入到源码中解析etcd 1 架构 从etcd的架构图中我们可以看到，etcd主要分为四个部分。 HTTP Server： 用于处理用户发送的API请求以及其它etcd节点的同步与心跳信息请求。 Store：用于处理etcd支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是etcd对用户提供的大多数API功能的具体实现。 Raft：Raft强一致性算法的具体实现，是etcd的核心。 WAL：Write Ahead Log（预写式日志），是etcd的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd就通过WAL进行持久化存储。WAL中，所有的数据提交前都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照；Entry表示存储的具体日志内容。 通常，一个用户的请求发送过来，会经由HTTP Server转发给Store进行具体的事务处理 如果涉及到节点的修改，则交给Raft模块进行状态的变更、日志的记录，然后再同步给别的etcd节点以确认数据提交 最后进行数据的提交，再次同步。 2 新版etcd重要变更列表 获得了IANA认证的端口，2379用于客户端通信，2380用于节点通信，与原先的（4001 peers / 7001 clients）共用。

http://thesecretlivesofdata.com/raft/ CONSENSUS: BRIDGING THEORY AND PRACTICE https://ramcloud.stanford.edu/~ongaro/thesis.pdf https://web.stanford.edu/~ouster/cgi-bin/papers/OngaroPhD.pdf https://understandingpaxos.wordpress.com/ http://www.julianbrowne.com/article/brewers-cap-theorem 使用Paxos前的八大问题 https://zhuanlan.zhihu.com/p/23811020 动画 http://thesecretlivesofdata.com/raft/ 如何浅显易懂地解说 Paxos 的算法？ https://www.zhihu.com/question/19787937 https://raft.github.io/ https://web.stanford.edu/~ouster/cgi-bin/papers/raft-atc14 https://en.wikipedia.org/wiki/Raft_(computer_science) https://en.wikipedia

一致性算法—Paxos、Raft、ZAB 2019年04月21日 20:35:09 bulingma 阅读数 64 更多 分类专栏： 分布式概念 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/bulingma/article/details/89438851 写在前面 1、分布式系统对fault tolerence的一般解决方案是state machine replication（状态机复制）。 2、分布式一致性算法的一种更准确的说法应该是：state machine replication的共识（consensus）算法。 3、pasox其实是一个共识算法。系统的最终一致性，不仅需要达成共识，还会取决于client的行为。 4、分布式系统中有多个节点就会存在节点间通信的问题，存在着两种节点通讯模型：共享内存（Shared memory）、消息传递（Messages passing），以下谈到的算法都是基于消息传递的通讯模型的。它的假设前提是，在分布式系统中进程之间的通信会出现丢失、延迟、重复等现象，但不会出现传错的现象。以下的算法就是为了保证在这样的系统中进程间基于消息传递就某个值达成一致。 一、一致性概述 当前工业实际应用中的一致性模型分类 1.1、弱一致性

这三个都是分布式一致性协议，ZAB基于Paxos修改后用于ZOOKEEPER协议，RAFT协议出现在ZAB协议之后，与ZAB差不多，也有很大区别。 1. Paxos 分布式节点分为3种角色， Proposer， Acceptor， Learner Proposer:提出议案[Mn, Vn] Accptor:决定最终议案 Learner:不参与议案的提出与决定，学习最后的议案 Proposer: 　　1. prepare阶段：提出议案编号M， 向Acceptor集合发送 　　2. 如果收到来自半数以上的Acceptor响应，向Acctoptor发送Accept请求 Acceptor: 　　1. Prepare：响应proposer prepare请求 　　2. Accepte: 响应Accept请求 2. ZAB协议 　　节点分为3种角色1, Follower, Leader, Observer 　　1. 选出leader 　　2. 客户端提出的事物都转给Leader处理 　　类似二阶段协议 　　1. Leader发送Propose给Fowller 　　2. 收到半数以上Ack，发送Commit给Follwer 　　3. Observer不参与Leader选举，同步数据，数据副本。客户端可以读取Observer数据，提高Zookeeper集群工作效率 来源： https://www

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

Raft共识算法在分布式系统中是常用的共识算法之一，论文原文 In Search of an Understandable Consensus Algorithm ，作者在论文中指出Poxas共识算法的两大问题，其一是难懂，其二是应用到实际系统存在困难。针对Paxos存在的问题，作者的目的是提出一个易懂的共识算法，论文中有Designing for understandability单独一小节，其中强调Raft必须是一个实用的、安全可用、有效易懂的共识算法。本文描述了Raft共识算法的细节，很多内容描述及引用图片均摘自论文原文。 Raft概述 我们主要分以下三部分对Raft进行讨论： Leader election——a new leader must be chosen when an existing leader fails. （领导人选举） Log replication——the leader must accept log entries from clients and replicate them across the cluster, forcing the other logs to agree with its own.（日志复制） Safety——the key safety property for 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

尊敬的阿里云用户： 您好！为方便您试用开源 RocketMQ 客户端访问阿里云MQ，我们申请了专门的优惠券，优惠券可以直接抵扣金额。请填写下您公司账号信息，点击上图，了解更多哦。 一、DLedger引入目的 在 RocketMQ 4.5 版本之前，RocketMQ 只有 Master/Slave 一种部署方式，一组 broker 中有一个 Master ，有零到多个 Slave，Slave 通过同步复制或异步复制的方式去同步 Master 数据。Master/Slave 部署模式，提供了一定的高可用性。 但这样的部署模式，有一定缺陷。比如故障转移方面，如果主节点挂了，还需要人为手动进行重启或者切换，无法自动将一个从节点转换为主节点。因此，我们希望能有一个新的多副本架构，去解决这个问题。 新的多副本架构首先需要解决自动故障转移的问题，本质上来说是自动选主的问题。这个问题的解决方案基本可以分为两种： 利用第三方协调服务集群完成选主，比如 zookeeper 或者 etcd。这种方案会引入了重量级外部组件，加重部署，运维和故障诊断成本，比如在维护 RocketMQ 集群还需要维护 zookeeper 集群，并且 zookeeper 集群故障会影响到 RocketMQ 集群。 利用 raft 协议来完成一个自动选主，raft 协议相比前者的优点是不需要引入外部组件

参考文章： 《In Search of an Understandable Consensus Algorithm》 https://raft.github.io/ http://thesecretlivesofdata.com/raft/ 这里有一个非常适合理解raft协议的 小动画 。 1.1.1 简介 概念： raft是一种用于管理log 复制的一致性协议，它和paxos有同样功能，但是比它简单容易理解。 功能： leader 选举、日志复制及安全问题。并且提供了强一致性。 1.1.2 原理 这里以3个节点为例 每个节点都有三种状态：leader、candidate、follower 每个组有三种行为：leader election、log replication、safety。 1） leader election 当启动三个节点时，都处在candidate状态（raft有时间机制，然后发送vote信息给其他节点），当超过一半时会变成candidate，其他两个节点的状态会变为follower。 所有客户端数据的交换都跟leader进行。 2） log replication log replication保证了数据在组中的一致性。log entry是这个的核心。 下图是过程 在第三步的时候，raft协议会使用append entries message心跳检测

近来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 仅用于保证高可用