一些私人网站,关于做网站的策划书,怎么免费建立网店网站,高校校园网站建设与运行1. CAP理论
一致性【Consistency】#xff1a;所有节点访问最新的数据可用性【Availability】#xff1a;非故障节点响应正常分区容错性【Partition Tolerance】#xff1a;分布式系统出现网络分区#xff0c;仍能对外提供服务
附#xff1a;网络分区#xff1a;分布式…1. CAP理论
一致性【Consistency】所有节点访问最新的数据可用性【Availability】非故障节点响应正常分区容错性【Partition Tolerance】分布式系统出现网络分区仍能对外提供服务
附网络分区分布式系统中由于出现网络故障或其他原因【物理断开人为配置更改安全攻击等】导致原本联通的网络被分割成多个独立的子网子网之间节点无法通信。解决的方式通常是分布式的超时和重试策略服务发现的动态识别连接采用Raft等一致性协议 CAP理论不是3选2而是在出现P网络分区【必须处理的问题】的时候只能保证数据的强一致性或者节点可用性。 举例说明就是当网络出现分区某个节点1在进行写操作如果要保证数据一致性C那就要别的节点234.都要禁止写操作那这就是违法了A可用性。总得来说就是满足所有非故障节点都正常运行的话那么数据一致性是无法保证的。但是如果没有发生分区的话那就要保证如何实现CA。 2. BASE理论–基于CA的平衡对于AP的补充
基本可用【Basically Available】允许损失部分性能/功能上的可用性软状态【Soft-state】允许不同节点数据之间同步存在延时最终一致性【Eventually Consistent】经过上面的性能损失、非核心功能不可用后数据慢同步后最终能够达到数据强一致性的状态。 附分布式一致性的三种级别强一致性【写什么读什么】、弱一致性【某个时刻一致就行】、最终一致性【最后一致就行】。 那实现最终一致性的方式是什么呢 思想就是在数据方面解决比如增加一个版本号数据更新时增加。读时修复【读取数据时不同节点数据不一致更新数据状态】。写时修复【写数据时修复-更推荐】。异步修复【定时检测数据一致性修复】。 ACID是数据库实例内部的数据-事务完整性理论CAP是分布式系统-设计理论。
3. 分布式系统中如何保证一致性
事务一致性操作的正确性所有节点最终状态是一致的。如追踪电商平台的“优惠券”状态订单和优惠券之间是强关联的。
副本一致性数据多个副本之间是一致性的保证数据更新时的分区同步。如下面的基于图书馆的Raft算法理解。
3.1 事务一致性
在分布式中影响事务一致性的原因通常是因为各个微服务之间解耦【每个服务都有独立数据存储】产生了跨数据库事务。MySQL如何根据Redo和Undo log来实现事务一致性 总结补充Redo Log【正向修改-向前补偿】记录对数据库的增删改正向操作也就是数据变更的SQL语句用于重做恢复而Undo Log【逆向恢复-向后补偿】记录的是数据变更前足够的恢复原始数据的信息即之前的状态事务提交后会被清理。 常见的解决方案 技术角度数据版本控制【参考MySQL】、事务协议2PC、3PC、XA协议、TCC补偿模式等 2PC两阶段提交-准备阶段和提交阶段经典分布式事务协议由协调者发出请求所有参与者做出应答任何一者回复“拒绝”所有事务撤销。 2PC的问题点 同步阻塞问题这也是事务的常见问题了意思就是prepare阶段锁定的资源别的事务也要就必须阻塞等待事务完成。 单点故障问题这也是3PC加了preCommit来解决的问题意思就是一阶段prepare成功但是二阶段commit宕机导致资源处于锁定状态事务无限期等待【故障】。 数据不一致问题同二二阶段commit失败数据也会因此不一致。 3PC三阶段提交-可以提交阶段、预提交阶段、最终提交阶段表面上增加了预提交显得更可靠用来确认所有的参与事务都已经准备好提交但实际增加了通信开销的同时并不能解决极端情况无法提交回滚的问题。 3PC的问题点 字面意思“更可靠”preCommit的存在是给最终提交上了个保险检测事务参与者都准备好了那就commit但很显然【存在极端情况】rollback请求没收到的话数据也会不一致。 XA传统的XA模式也是三阶段【seata XA二阶段不作详解】【1. 开始事务-生成全局事务XID 2. prepare阶段-确定是否可以提交 3. commit/rollback阶段-最终阶段释放资源】与2PC/3PC作区分的话大概就是TM会首先开启一个全局事务并生成唯一标识XID各个AP通过本地RM向TM上注册TM首先会发送prepare请求确定是否commit这期间也是通过XID来管理的当所有的分支事务都说ready了那就最终执行commit否则rollback最后TM完成收尾释放资源。 补充AP【应用服务】TM【事务管理器-Transaction Manager】RM【资源管理器-Resource Manager】 XID的作用每个分支事务都要带XID注册到TM同时XID可以隔离和区分识别是哪个全局事务同时在日志中记录XID和相关事务可以便于系统后期查询和恢复。 TCCtry-confirm-cancel 分布式解决方案略 业务角度事务分类-关键事务、可补偿性事务、可重试性事务 关键事务核心功能一旦提交失败立马回滚。如核心下单操作用户信息保存失败事务立马回滚避免优惠券和库存的一致性。可补偿性事务正向操作提交失败反向代偿。如优惠券和库存正向扣券减库存不行反向释放优惠券加库存代偿。可重试性事务业务操作中由于网络波动等原因导致失败可以通过重新多次执行来达到最终目的。如发送验证码登陆场景。 可重试性事务可以支持Retry自定义注解配置或者MQ的Retry幂等保障可重复性 场景落地实现大致可分为-查询模型、任务检测模型、对账模型 查询查询接口是否完成确定业务是否重新调用还是执行后续流程。自检系统周期性跟踪对未执行任务检测并更新状态。对账把不同业务的数据都拿来一点点对不一致就进行报警需人工介入。
3.2 副本一致性
基于Paxos的Raft算法
分布式系统中由于网络分区或者节点故障等问题不同节点对系统值有不同的认知共识算法就是为了确保多个节点对某个值或一系列值达成一致性意见。 基本共识问题的核心是在分布式系统中如果一个正确节点提出了某个值在异步系统的其他正确节点最终会同意这个值或者所有正确节点都同意不选择任何值。拜占庭共识算法是要考虑到系统中可能存在恶意节点这些节点可能会发送错误信息或执行非预期行为。Raft的Leader选举算法用于协调其他节点的操作。2PC和3PC通常用于确保分布式数据库系统中事务的原子性和一致性。Paxos和Raft适用于需要强一致性和高可用性的场景。 Paxos的核心思想就是Baisc Paxos【多节点value共识】和Multi-Paxos【执行多次Baisc Paxos对一系列值达成共识】。
基础知识点
Raft算法是一种分布式一致性算法角色有三个【Leader-领导者Candidate-候选者Follower-跟随者】核心思想是选举出一个Leader由这个领导者负责管理数据复制和一致性。节点之间的通信用的是RPC【RequestVote RPC-候选人选举发起AppendEntries RPC-心跳机制复制日志InstallSnapshot RPC-发送快照给落后者】
raft算法首先会将时间划分为任意长度的term任期term号用连续数字表示每一个任期的开始都是leader选举。当然多个Candidate竞选一个Leaderterm期结束没有再继续下一个任期竞选通信交换term号来判断小的更新成大的过期的自动变成follower。
日志entry携带termindexcmd。log是由entry组成的数组标识是index最新的最先添加到Leader的log数组中。
leader选举的过程是1、增加term号2、给自己投票3、重置选举超时计时器4、发送请求投票的RPC给其它节点。
算法理解背景就是目前有一个图书馆图书馆里面有很多分馆每个分馆都有一个分馆主和一本借书记录【全一致】如何用Raft思想保证每个借书记录在某个时间点读取的借书信息都是相同的
在领导者选举【Leader Election】阶段原馆长辞职后图书馆会自动启动一个选举过程来选出新馆长。新馆长上任后首要任务是确保所有分馆的借书记录是一致的。新馆长会将新的借书记录首先更新到自己的日志中然后同步到其他分馆确保所有分馆的日志都是最新的并且记录是有效的这体现了安全性。如果发现有分馆的记录不一致新馆长会强制这些分馆更新到自己的记录保证一致性。在分馆出现故障时新馆长能够从其他分馆获取最新的记录信息并更新故障分馆确保系统的高可用性。新馆长定期发送心跳消息与分馆建立联系如果分馆在一定时间内没有收到心跳它们会认为新馆长可能已经不在了然后可能会开始新的领导者选举过程。
面试常见问题
Raft分为哪几部分leader选举、任期管理、日志复制、日志压缩、心跳机制、租约管理等Raft选举发起的时机刚启动/leader挂掉/每个任期开始计时器最先归0的先发起成员变更。Raft如何决定把票投出去大概意思就是candidate通过投票RPC携带term_id和index的log日志与接收到的follower进行比较如果本地follower的log比candidate的更新则拒绝投票term_id最小更新相同term_id的话日志哪个多就说了算。Raft网络分区数据一致性如何解决分区的话就先在一个区内存在的follower进行选举选举出leader后来处理客户端的请求和日志如果故障修复则老leader退出变成follower且此时的任何更新都要以新的leader为准。通过日志恢复来保持数据的一致性Raft和Paxos的区别Raft拥有最新日志的节点才能成为leadermulti-paxos没有限制。Raft的leader有任期。Raft的lease租约机制每个term任期内只有持有租约lease的节点才能成为leader到期后必须重发租约。
