NWR，Gossip，Paxos分布式一致性协议

NWR协议

1.NWR是一种在分布式存储系统中用于控制一致性级别的一种策略。在亚马逊的云存储系统中，就应用NWR来控制一致性。
2.N：在分布式存储系统中，有多少份备份数据
3.W：代表一次成功的更新操作要求至少有w份数据写入成功
4.R：代表一次成功的读数据操作要求至少有R份数据成功读取
5.NWR值的不同组合会产生不同的一致性效果，当W+R>N的时候，整个系统对于客户端来讲能保证强一致性。
6.当R+W<=N，无法保证数据的强一致性：因为成功写和成功读集合可能不存在交集，这样读操作无法读取到最新的更新数值，也就无法保证数据的强一致性。

Gossip 协议

1.Gossip 协议也叫 Epidemic 协议 （流行病协议）。原本用于分布式数据库中节点同步数据使用，后被广泛用于数据库复制、信息扩散、集群成员身份确认、故障探测等。
2.gossip 协议利用一种随机的方式将信息传播到整个网络中，并在一定时间内使得系统内的所有节点数据一致。
3.Gossip 其实是一种去中心化思路的分布式协议，解决状态在集群中的传播和状态一致性的保证两个问题。
4.Gossip 协议的消息传播方式有两种：（1）反熵传播：是以固定的概率传播所有的数据。所有参与节点只有两种状态：Suspective(病原)、Infective(感染)。过程是种子节点会把所有的数据都跟其他节点共享，以便消除节点之间数据的任何不一致，它可以保证最终、完全的一致。缺点是消息数量非常庞大，且无限制；通常只用于新加入节点的数据初始化。（2）谣言传播：是以固定的概率仅传播新到达的数据。所有参与节点有三种状态：Suspective(病原)、Infective(感染)、Removed(愈除)。过程是消息只包含最新 update，谣言消息在某个时间点之后会被标记为 removed，并且不再被传播。缺点是系统有一定的概率会不一致，通常用于节点间数据增量同步。
5.Gossip 协议最终目的是将数据分发到网络中的每一个节点。根据不同的具体应用场景，网络中两个节点之间存在三种通信方式：推送模式、拉取模式、推/拉模式。

Paxos协议

1. Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一。
2.在之前讲解2PC 和 3PC的时候在一定程度上是可以解决数据一致性问题的. 但是并没有完全解决就是协调者宕机的情况。
3.诸如机器宕机或网络异常（包括消息的延迟、丢失、重复、乱序，还有网络分区）等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致，并且保证不论发生以上任何异常，都不会破坏整个系统的一致性。
4.如何解决2PC和3PC的存在的问题:（1）引入多个协调者（2）引入主协调者,以他的命令为基准，主协调着负责协调，其他协调者负责跟随。
5.在引入多个协调者之后又引入主协调者.那么这个就是最简单的一种Paxos 算法。
6.Paxos的版本有: Basic Paxos , Multi Paxos, Fast-Paxos, 具体落地有Raft 和zk的ZAB协议。

Basic Paxos相关概念

1.角色介绍:（1）Client:客户端：客户端向分布式系统发出请求，并等待响应。（2）Proposer：提案发起者：提案者提倡客户端请求，试图说服Acceptor对此达成一致，并在发生冲突时充当协调者以推动协议向前发展。（3）Acceptor: 决策者，可以批准提案。并进行投票, 投票结果是否通过以多数派为准, 以如果某个提案被选定，那么该提案里的value就被选定了。（4）Learner: 最终决策的学习者：学习者充当该协议的复制因素(不参与投票)。
2.basic paxos流程一共分为4个步骤: （1）Proposer提出一个提案,编号为N, 此N大于这个Proposer之前提出所有提出的编号, 请求Accpetor的多数人接受这个提案。（2）如果编号N大于此Accpetor之前接收的任提案编号则接收, 否则拒绝。     （3）如果达到多数派, Proposer会发出accept请求, 此请求包含提案编号和对应的内容。（4）如果此Accpetor在此期间没有接受到任何大于N的提案,则接收此提案内容, 否则忽略。

Multi-Paxos

1.针对basic Paxos是存在一定得问题,首先就是流程复杂,实现及其困难, 其次效率低(达成一致性需要2轮RPC调用),针对basic Paxos流程进行拆分为选举和复制的过程.
2.Multi-Paxos在实施的时候会将Proposer，Acceptor和Learner的角色合并统称为“服务器”。因此，最后只有“客户端”和“服务器”。

Raft协议

1.Paxos 是论证了一致性协议的可行性，但是论证的过程据说晦涩难懂，缺少必要的实现细节，而且工程实现难度比较高, 广为人知实现只有 zk 的实现 zab 协议。
2.斯坦福大学RamCloud项目中提出了易实现，易理解的分布式一致性复制协议 Raft。Java，C++，Go 等都有其对应的实现之后出现的Raft相对要简洁很多。引入主节点，通过竞选确定主节点。节点类型：Follower、Candidate 和 Leader。
3.Leader 会周期性的发送心跳包给 Follower。每个 Follower 都设置了一个随机的竞选超时时间，一般为 150ms~300ms，如果在这个时间内没有收到 Leader 的心跳包，就会变成 Candidate，进入竞选阶段, 通过竞选阶段的投票多的人成为Leader。
4.日志复制：  （1）来自客户端的修改都会被传入 Leader。注意该修改还未被提交，只是写入日志中。（2）Leader 会把修改广播到所有 Follower。（3）Leader 会等待大多数的 Follower 也进行了修改并响应后，然后才将修改提交。（4）Leader 会通知的所有 Follower 让它们也提交修改，此时所有节点的值达成一致。
5.网络分区：面对网络分区，Raft甚至可以保持一致。（1）当出现网络分区情况,此时一个集群会被分成多个子集群，其他没有leader节点的集群会重新选出对应的leader。（2）当网络分区恢复后最终E节点Termid最大成为Leader节点,同步节点数据,达成数据一致性。

Lease机制

1.Lease机制，翻译过来即是租约机制，是一种在分布式系统常用的协议，是维护分布式系统数据一致性的一种常用工具。
2.Lease机制的特点：（1）Lease是颁发者对一段时间内数据一致性的承诺；（2）颁发者发出Lease后，不管是否被接收，只要Lease不过期，颁发者都会按照协议遵守承诺；（3）Lease的持有者只能在Lease的有效期内使用承诺，一旦Lease超时，持有者需要放弃执行，重新申请Lease。
3.Lease机制主要解决出现网络问题主节点无法和子节点之间进行心跳检测的时候，子节点会重新选举leader节点。但要我们的分布式系统能够容忍leader节点出错的情况下。

分布式系统设计（心跳检测）

1.在分布式环境下，我们存在着很多节点，当其中某个节点出现故障的时候我们如何得知就是通过心跳检测机制判断，就是以固定的频率进行汇报。心跳汇报的时候还包括着一些元数据信息。方便管理。
2.周期检测心跳机制：Server端每间隔 t 秒向Node集群发起监测请求，设定超时时间，如果超过超时时间，则判断“死 亡”。可以把该节点踢出集群。
3.累计失效检测机制：通过统计节点返回的情况来判断节点的死亡频率，也就是一种重试机制。当累计到一定次数则剔除节点。

高可用HA设计

1.高可用是系统架构设计中必须考虑的因素之一,通常是指,经过设计来减少系统不能提供服务的时间。
2.高可用的设计模式包括三种：主备（Master-SLave）、互备（Active-Active）和集群（Cluster）模式。  （1）主备模式：当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以自动（热备）或手动（冷备）方式将服务切换到主机上运行。比如Mysql和Redis的主从复制。（2）互备模式：指两台主机同时运行各自的服务工作且相互监测情况。在数据库高可用部分，指一个系统存在多个master，每个master都具有read-write能力。（3）集群模式是指有多个节点在运行，同时可以通过主控节点分担服务请求。集群模式需要解决主控节点本身的高可用问题，一般采用主备模式。

高可用HA下"脑裂问题"

1.本来2个相互联系的节点突然间断了联系，两者都以为是对方出了问题，那么就会各自的去争抢资源，从而导致资源被抢光，服务起不来了。或者两者同时进行了读-写操作，破坏了数据。
2.导致脑裂的原因一般有网络问题，心跳链路断裂无法通信，配置不当如：心跳方式不同，软件bug等。
3.解决的方法有：（1）添加多条心跳线，哪怕有其中一条断开还有别的能继续工作。（2）添加第三方协调者，当两者出现分歧的时候由第三方进行调度。（3）使用lease机制，但是要求系统具有一定的容错性。

容错性

1.容错的处理是保障分布式环境下相应系统的高可用或者健壮性，一个典型的案例就是对于缓存穿透问题的解决方案。
2.缓存穿透的容错策略就有临时存放null值，使用BitMaps布隆过滤器。

负载均衡

1.其关键在于使用多台集群服务器共同分担计算任务，把网络请求及计算分配到集群可用的不同服务器节点上，从而达到高可用性及较好的用户操作体验。
2.以Nginx为例，负载均衡有以下6种策略：  （1）轮询：默认方式,每个请求会按时间顺序逐一分配到不同的后端服务器。（2）weight：权重方式,在轮询策略的基础上指定轮询的几率,权重越大,接受请求越多。（3）ip_hash：依据ip分配方式,相同的客户端的请求一直发送到相同的服务器。（4）least_conn：最少连接方式,把请求转发给连接数较少的后端服务器。（5）fair（第三方）：响应时间方式,按照服务器端的响应时间来分配请求，响应时间短的优先分配。（6）url_hash（第三方）依据URL分配方式,按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器。

NWR，Gossip，Paxos分布式一致性协议相关推荐

Paxos分布式一致性协议
为什么80%的码农都做不了架构师?>>> 源码:https://bitbucket.org/sciascid/libpaxos/src 1 前言分布式系统中的节点通信存在 ...
Paxos——分布式一致性协议
目录 1. Paxos的理解困境 2. Paxos和分布式存储系统 3. 确定一个不可变变量的取值 3.1 如何定义"确定一个不可变变量的取值"这样的系统问题? 3.2 确定一个不 ...
分布式一致性协议Raft，以及难搞的Paxos
Raft这玩意,网上已经有好多解读文章了,大概比Paxos还要多一些,所以,这篇,不求细节,但求核心思想方面,追一下本源,然后,给自己做个笔记. Raft是什么,它想解决什么问题? 所以Raft是什么 ...
简述分布式一致性协议（2pc、3pc、paxos、zab）
分布式一致性协议二阶段提交协议(2pc) 三阶段提交协议(3pc) paxos zab 在分布式系统中,每个机器都可以确定自己进行的事务操作是否成功,但是无法直接了解其他机器的操作结果.因此,当一个 ...
分布式一致性协议三部曲-深入理解一致性协议Paxos
在理解分析分布式一致性协议前,我们必须先看下CAP理论 CAP CAP是指在一个分布式系统中,一致性(Consistency).可用性(Availability).分区容错性(Partition to ...
分布式一致性协议三部曲-从paxos幽灵复现看Raft实现原理
幽灵复现 Mutlti-Paxos下存在Leader切换情况,因而可能出现下面的场景第一轮中A被选为 Leader,写下了 1-10 号日志,其中 1-5 号日志形成了多数派,并且已给客户端应答,而 ...
paxos协议对比_分布式一致性协议三部曲-深入理解一致性协议Paxos
CAP二阶段提交协议(2PC)协议详情改进缺陷参与者还都处于锁定事务资源的状态中,而无法继续完成事务操.尽管协调者挂掉后可以重新选举一个协调者,但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问 ...
分布式一致性协议 Gossip 和 Redis 集群原理解析
分布式一致性协议 Gossip 和 Redis 集群原理解析 Redis 是一个开源的.高性能的 Key-Value 数据库.基于 Redis 的分布式缓存已经有很多成功的商业应用,其中就包括阿里 A ...
JUST技术：分布式一致性协议概念及Raft协议简介
分布式系统通常由异步网络连接的多个节点构成,每个节点的计算和存储相互独立.分布式一致性指多个节点对某一变量的取值达成一致,一旦达成一致,则变量的本次取值被确定.本文将简单介绍一致性的一些基本概念,以及 ...
[分布式一致性协议] ------ raft协议的解释与理解
前言在分布式系统中,为了保证容错性,一般会维护多个副本集群,提高系统的高可用,但与之带来的问题就是多个副本的一致性(consensus)问题. 我们认为,对于一个具有一致性的的集群中,同一时刻所有节 ...

NWR，Gossip，Paxos分布式一致性协议

NWR协议

Gossip 协议

Paxos协议

Basic Paxos相关概念

Multi-Paxos

Raft协议

Lease机制

分布式系统设计（心跳检测）

高可用HA设计

高可用HA下"脑裂问题"

容错性

负载均衡

NWR，Gossip，Paxos分布式一致性协议相关推荐

最新文章

热门文章