什么网站可以接效果图做,清远网站建设,wordpress缩进去的边栏,做外贸网站设计上需要注意什么Python微信订餐小程序课程视频
https://edu.csdn.net/course/detail/36074
Python实战量化交易理财系统
https://edu.csdn.net/course/detail/35475
分布式协议
分布式理论概念
1. 分布式数据一致性
分布式数据一致性#xff0c;指的是数据在多个副本中存储时#xff…Python微信订餐小程序课程视频
https://edu.csdn.net/course/detail/36074
Python实战量化交易理财系统
https://edu.csdn.net/course/detail/35475
分布式协议
分布式理论概念
1. 分布式数据一致性
分布式数据一致性指的是数据在多个副本中存储时各副本中的数据是一致的。
在分布式系统中数据往往有多个副本。多个副本就需要保证数据的一致性。这就带来了同步的问题因为网络延迟等因素我们几乎没有办法保证可以同时更新所有机器中的所有数据一定会有一刻会出现数据不一致。
那么实际应用中我们如何既保证数据一致性同时又不影响系统运行的性能呢于是一致性级别的概念由此诞生。
2. 一致性级别
强一致性
它要求系统写入什么读出来的也会是什么用户体验好但是实现起来对系统的性能影响比较大
弱一致性
这种级别不承诺立即可以读到写入的值也不承诺多久之后数据能够达到一致但会尽可能的保证到某个时间节点后数据能够达到一致状态。
最终一致性
最终一致性也是弱一致性的一种它无法保证数据更新后所有后续的访问能看到最新数据而是需要一个时间这个时间之后可以保证一致。
如微信的2小时到账
3. CAP理论
CAP定理它指出一个分布式系统不可能同时满足以下三点
一致性 Consistency所有节点访问时都是同一份最新的数据副本可用性Availability每次请求都能获取到非异常的响应但不保证数据最新分区容错性Partition tolerance分布式系统遇到任何网络分区故障的时候仍然能够对外提供服务除非整个网络环境都发生了故障
4. BASE理论
BASE全称是Basically Available基本可用Soft state软状态和Eventually consistent最终一致性三个短语的缩写。
Base理论的核心思想是既然无法做强一致性那么每个应用可以根据自身业务特定采用适当的方式使系统达到最终一致性。
基本可用出现了不可预知的故障但还是能用。只是相对正常系统来说可能响应变慢部分功能缺失。软状态指系统的数据存在中间状态并认为该状态不会影响系统的整体可用性。即允许不同副本的数据存在延迟最终一致性上面说的软状态不能一直是软状态必须要有时间期限。在期限过后应当保证所有副本数据一致
分布式一致性协议
1. 两阶段提交
两阶段提交协议简称2PC2 Prepare Commit,是比较常用的解决分布式事务问题的方式要么所有参与进程提交事务要么都取消事务。 阶段一事务询问。协调者向所有资源发送事务的内容参与者执行事务并响应结果给协调者。
阶段二协调者根据上一阶段的结果向所有参与者发送提交或回滚请求
优缺点
优点原理简单
缺点
同步阻塞在二阶段提交的执行过程中所有参与该事务操作的逻辑都处于阻塞状态。单点问题当协调者出现问题那么整个二阶段提交都无法运转数据不一致在阶段二中执行事务提交时如果因为局部网络问题导致尚未向所有的参与者发送完Commit请求就宕机的话就会导致出现数据不一致的现象。
2. 三阶段提交
三阶段提交是二阶段提交的改进版将2PC的”提交事务请求“过程一分为二共形成了由CanCommitPreCommit和doCommit三个阶段组成的事务处理协议。 第一阶段CanCommit阶段类似于2PC的准备第一阶段。协调者向参与者发送commit请求参与者如果可以提交就返回Yes响应否则返回No响应。
第二阶段PreCommit阶段)协调者根据参与者的反应情况来决定是否可以执行事务的PreCommit操作。
如果是YES向参与者发送预提交请求通知参与者执行事务操作。如果是NO向参与者发送abort请求
第三阶段doCommit阶段根据上一阶段的结果进行真正的事务提交或中断。
如果第三阶段中协调者挂掉或者协调者和参与者出现网络问题参与者都会在等待超时之后继续进行事务提交
2PC和3PC的对比
3PC对于协调者和参与者都设置了超时机制在2PC中只有协调者拥有超时机制即如果在一定时间内没有收到参与者的消息则默认失败,主要是避免了参与者在长时间无法与协调者节点通讯协调者挂掉了的情况下无法释放资源的问题因为参与者自身拥有超时机制会在超时后自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。通过CanCommit、PreCommit、DoCommit三个阶段的设计相较于2PC而言多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的 。PreCommit是一个缓冲保证了在最后提交阶段之前各参与节点的状态是一致的。
3. NWR协议
NWR是一种在分布式存储系统中控制一致性级别的一种策略。
N在分布式存储系统中有多少份备份数据W代表一次成功的更新操作要求至少有W份数据写入成功R代表一次成功的读数据操作要求至少有R份数据成功读取
NWR值的不同组合会产生不同的一致性效果当WRN时整个系统对于客户端来讲能保证强一致性。而WR 举例W2 R2 N3
上述例子WRN这种情况下Read和Writer肯定会在某个或多个节点有交集重合就表示强一致性。
4. Gossip 协议
Gossip协议也叫Epidemic协议流行病协议。原本用于分布式数据库中节点同步数据使用后被广泛用于数据库复制、信息扩散、集群成员身份确认、故障探测等。
gossip 协议利用一种随机的方式将信息传播到整个网络中并在一定时间内使得系统内的所有节点数据一致。Gossip 其实是一种去中心化思路的分布式协议解决状态在集群中的传播和状态一致性的保证两个问题
Gossip原理
Gossip 协议的消息传播方式有两种反熵传播 和 谣言传播
反熵传播
是以固定的概率传播所有的数据。所有参与节点只有两种状态Suspective(病原)、Infective(感染)
谣言传播
是以固定的概率仅传播新到达的数据。所有参与节点有三种状态Suspective(病原)、Infective(感染)、Removed(愈除)。过程是消息只包含最新update谣言消息在某个时间点之后会被标记为 removed并且不再被传播
三种通信方式推送模式、拉取模式、推/拉模式
优缺点
综上所述我们可以得出Gossip是一种去中心化的分布式协议数据通过节点像病毒一样逐个传播。因为是指数级传播整体传播速度非常快。
优点
扩展性允许节点的任意增加和减少新增节点的状态最终会与其他节点一致容错任意节点的宕机和重启都不会影响Gossip消息的传播具有天然的分布式系统容错特性去中心化无需中心节点所有节点都是对等的任意节点无需知道整个网络状况只要网络连通任意节点可把消息散播到全网最终一致性Gossip协议实现信息指数级的快速传播因此在有新信息需要传播时消息可以快速地发送到全局节点在有限的时间内能够做到所有节点都拥有最新的数据。
缺点
消息延迟:节点随机向少数几个节点发送消息消息最终是通过多个轮次的散播而到达全网不可避免的造成消息延迟。消息冗余:节点定期随机选择周围节点发送消息而收到消息的节点也会重复该步骤不可避免的引起同一节点消息多次接收增加消息处理压力
5. Paxos协议
Paxos协议其实说的就是Paxos算法。Paxos算法是基于消息传递且具有高度容错特性的一致性算法是目前公认的解决分布式一致性问题最有效的算法之一。
自Paxos问世以来就持续垄断了分布式一致性算法。开源的ZooKeeper以及MySQL 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法解决分布式一致性问题。然而Paxos的最大特点就是难不仅难以理解更难以实现.
Paxos解决了什么问题
在常见的分布式系统中总会发生诸如机器宕机或网络异常包括消息的延迟、丢失、重复、乱序还有网络分区等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中快速且正确地在集群内部对某个数据的值达成一致并且保证不论发生以上任何异常都不会破坏整个系统的一致性
Paxos的版本有Basic PaxosMulti PaxosFast-Paxos具体落地有Raft和zk的ZAB协议。
Basic Paxos
角色概念
Client客户端Proposer提案发起者。提案者提倡客户端请求试图说服Accptor对此达成一致Acceptor决策者可以批准提案Learner最终决策的学习者学习者充当该协议的复制因素不参与投票 Basic Paxos流程图 客户端发起一个请求它的值为1Proposer发起一个提案编号为1Acceptor收到的提案编号比本地的大就通过Proposer就将客户端的值和提案一起再发给AcceptorAcceptor接收后复制给Learners
异常情况下
如果Acceptor中有一个发生了故障但是只要大多数是正常的Basic Paxos协议仍然成功Proposer传递给Acceptor的时候故障了的话这时需要选出新的Proposer如果多个提议者发生冲突了那么也是重新提议。
6. Raft协议
Paxos协议的出现为分布式强一致性提供了很好的理论基础。但是实现比较复杂。然后斯坦福大学RamCloud项目中提出了易实现易理解的分布式一致性复制协议Raft。JavaCGo 等都有其对应的实现。
Raft协议引入主节点通过竞选确认主节点。节点类型有Follower、Candidate、Leader。
Raft相关概念
节点状态
Leader主节点 接受client更新请求写入本地后同步给其他副本Follower从节点从Leader中接受更新请求然后写入本地日志文件。对客户端提供读请求Candidate候选节点如果follower在一段时间内未收到leader心跳则判断leader可能故障发起选主提议。节点状态就会从follower变成Candidate状态直到选主结束
termId任期号时间被划分为一个个任期每次选举后会产生一个新的termIdRequestVote请求投票candidate在选举过程中发起收到多数派响应后成为leader。
Leader 会周期性的发送心跳包给Follower。每个Follower都设置了一个随机的竞选超时时间一般为 150ms~300ms如果在这个时间内没有收到 Leader 的心跳包就会变成Candidate进入竞选阶段,通过竞选阶段的投票多的人成为Leader
竞选阶段流程
这个是Raft完整版http://thesecretlivesofdata.com/raft/动画演示
github也提供一个https://raft.github.io/动画演示地址 .
初始阶段下所有节点都是follower节点每个follower节点都会等待一个随机的竞选超时时间如果超时时间后没收到Leader发来的心跳包就会进入竞选阶段如果节点A的随机超时时间最短那么它先进入竞选阶段。节点A会发送投票请求给其他所有节点其他节点会对投票请求进行回复如果超一半的节点回复了那么该Candidate就会变成Leader之后Leader会周期性的发送心跳给FollowerFollower收到心跳后会重新开始计时
如果多个Follower成为Candidate并且票数相同那么就需要重新开始投票。当重新开始投票时由于每个节点的随机竞选超时时间不同因此能下一次再次出现多个Candidate并获得相同票数的概率很低。
日志复制
来自客户端的修改会被传入Leader但修改还未提交只是写入日志Leader会把修改复制到所有followerLeader会等待大多数的Follower也进行了修改然后才将修改提交此时Leader会通知所有的Follower让它们提交修改此时所有节点的值达成一致
网络分区
面对网络分区Raft也可以保持一致。
举例说明
当发生分区后肯定会因为接受不到Leader的心跳而重新发生选举就会出现两个Leader。这样就分成了2部分。
Leader B节点Follower ALeader EFollower CFlollwer D
原来的节点总数是5大多数等于3.那么客户端往LeaderB上发的消息都是未提交的。只有发给E才能被提交。
等网络恢复后E节点Termid较大成为Leader节点并同步节点数据。Leader B降为Follower节点
7. Lease机制
Lease机制翻译过来是租约机制是维护分布式系统数据一致性的一种常用工具。
Lease机制有如下几个特点
Lease是颁发者对一段时间内数据一致性的承诺颁发者发出Lease后不管是否被接受只要Lease不过期颁发者都会被按照协议遵守承诺Lease的持有者只能在Lease的有效期内使用承诺一旦Lease超时持有者需要放弃执行重新申请Lease Lease机制能解决什么问题呢
分布式系统中如何确认一个节点是否正常工作。考虑如下场景 Node1是主节点剩下4个副本如果Node1发生网络抖动Node1本身是正常的没有宕机导致从节点无法接收到心跳。他们就会再选出一个主节点。
这种场景解决思路有4种
设计能容忍双主的协议Raft协议通过TermId大的通过给低的Lease机制去中心化-Gossip协议
Lease如何处理这种情况呢
引入了一个中心节点负责下发有时效性的Lease给主节点这个有效期内不管你出啥问题我就认你如果网络出现问题了重新选了主节点。Lease未过期新的主节点去申请会被拒绝网络恢复了原来的主节点可以继续续期如果是原来的主节点是真的宕机了那么它的有效期过后新的主节点就能申请成功了。
Lease时间长短一般取1-10秒。太短网络压力太大太长则收回承诺的时间也长影响可用性
Lease的容错
主节点宕机 Lease的机制天生可容忍网络、Lease接收方的出错时间即Lease剩余过期时长中心节点异常 中心节点异常会使得所有节点没有Lease解决办法是使用小集群作为颁发者时差问题 中心节点和主节点之间可能存在时差问题需要校对
应用
GFS(Google 文件系统)中Master通过lease机制决定哪个是主副本lease在给各节点的心跳响应消息中携带。收不到心跳时则等待lease过期再颁发给其他节点。chubby中paxos选主后从节点会给主颁发lease在期限内不选其他节点为主。另一方面主 节点给每个client节点发送lease用于判断client死活。
