在哪个网站上做蓝思测评,如何自己开发手机app,百度搜索官方网站,四面山网站建设分布式系统
CAP 理论
CAP 理论是分布式系统设计中的一个基本原则#xff0c;它提供了一个思考和权衡一致性、可用性和分区容错性之间关系的框架。 CAP 理论的三个要素如下#xff1a;
一致性#xff08;Consistency#xff09;#xff1a;在分布式系统中的多个副本或节…分布式系统
CAP 理论
CAP 理论是分布式系统设计中的一个基本原则它提供了一个思考和权衡一致性、可用性和分区容错性之间关系的框架。 CAP 理论的三个要素如下
一致性Consistency在分布式系统中的多个副本或节点之间保持数据的一致性。也就是说如果有多个客户端并发地读取数据在任何时间点上它们都应该能够观察到相同的数据。可用性Availability系统在任何时间点都能正常响应用户请求即使部分节点挂了如果一个系统不能提供响应或响应时间过长则认为系统不可用。分区容忍性Partition tolerance指系统在遇到网络分区或节点失效的情况下仍能够继续工作并保持数据的一致性和可用性。
CAP 理论指出在分布式系统中不能同时满足一致性、可用性和分区容错性这三个特性只能是 CP 或者是 AP在分布式系统中分区是无法避免的当分区发生时我们必须在一致性和可用性之间做出选择。
CP强一致性和分区容错性设计。这样的系统要求保持数据的一致性并能够容忍分区故障但可用性较低例如在分区故障期间无法提供服务。AP高可用性和分区容错性设计。这样的系统追求高可用性而对一致性的要求较低。在分区故障期间它可以继续提供服务但数据可能会出现部分不一致。
在 C 一致性要求下就必须要拒绝用户的请求而拒绝了用户的请求就违背了 A 可用性所以 C 和 A 在分布式环境下是永无无法同时满足的分布式系统要么是 CP 模式要么是 AP 模式。BASE理论
BASE 理论是对分布式系统CAP理论中一致性与可用性权衡的进一步解释它更注重实际业务中如何通过放松一致性来获得高可用性。 BASE 是指
基本可用性Basically Available系统保证在出现故障或异常情况下依然能够正常对外提供服务尽管可能会有一定的性能损失或功能缺失。在分布式系统中为了保证系统的可用性有时会牺牲一致性。软状态Soft State系统中的数据的状态并不是强一致的而是柔性的。在分布式系统中由于网络延迟、节点故障等因素数据可能存在一段时间的不一致。最终一致性Eventually Consistent系统会保证在一段时间内对数据的访问最终会达到一致的状态。即系统允许数据副本在一段时间内存在不一致的状态但最终会在某个时间点达到一致。
BASE 理论强调系统的可用性和性能尽可能保证系统持续提供服务而不是追求强一致性。在实际应用中为了降低分布式系统的复杂性和提高性能可以采用一些方法来实现最终一致性如版本管理、异步复制等技术手段。
CAP理论常被用于说明分布式系统设计的极限和理论上的权衡而BASE理论则更多地指导具体实践如何在CAP理论所描述的限制下构建灵活且健壮的系统。
分布式共识理论
共识算法如Paxos、Raft和Zab等解决分布式系统中多节点间如何就某个值如配置信息、状态达成一致性的问题。
Raft算法“任期号”Term和索引Index是维护一致性和日志顺序的关键概念。
任期号是一个单调递增的整数它标记了集群领导权变动的时间段。每次选举都会产生一个新的任期号并且任期号随着时间推移只会增加不会减少。这个机制有助于防止“脑裂”现象即防止多个节点同时认为自己是合法的领导者。
在Raft算法中当一个Follower节点在一段时间内没有收到当前Leader的心跳包时它会成为Candidate并开始新一轮的选举此时任期号加一。如果该节点获得大多数节点的投票那么它就会成为新的Leader并以新的任期号开始发送心跳和日志条目给其他节点。任期号也用于解决网络分区和消息延迟问题。例如一个过时的Leader其身份属于旧任期尝试向集群中的其他节点发送命令但由于任期号比当前任期低这些节点会拒绝执行这些命令并告知该Leader其任期已经过时。索引是日志条目在日志中的位置表征了特定日志条目在整个日志序列中的顺序。索引保证了日志条目可以按照严格的顺序进行复制和应用到状态机上。
当一个Leader接收到客户端的请求时它会生成一个带有当前任期号和唯一索引的日志条目。然后Leader会将包含此日志条目的信息复制到集群中的其他节点。一旦条目被成功复制到大多数节点它就可以被提交并应用到状态机上。Leader可以使用索引和任期号来确定不一致的位置并通过发送缺失的条目来恢复日志的一致性。日志同步的概念服务器接收客户的数据更新/删除请求这些请求会落地为命令日志。只要输入状态机的日志命令相同状态机的执行结果就相同。所以Raft的核心就是leader发出日志同步请求follower接收并同步日志最终保证整个集群的日志一致性。
核心流程
首先选出leaderleader节点负责接收外部的数据更新/删除请求然后日志复制到其他follower节点同时通过安全性的准则来保证整个日志复制的一致性如果遇到leader故障followers会重新发起选举出新的leader
具体流程
Leader接收所有客户端请求然后转化为log复制命令发送通知其他节点完成日志复制请求。每个日志复制请求包括状态机命令 任期号同时还有前一个日志的任期号和日志索引。状态机命令表示客户端请求的数据操作指令任期号表示leader的当前任期。
follower收到日志复制请求的处理流程
1follower会使用前一个日志的任期号和日志索引来对比自己的数据
如果相同接收复制请求回复ok否则回拒绝复制当前日志回复error
2leader收到拒绝复制的回复后继续发送节点日志复制请求不过这次会带上更前面的一个日志任期号和索引
3如此循环往复直到找到一个共同的任期号日志索引。此时follower从这个索引值开始复制最终和leader节点日志保持一致
4日志复制过程中Leader会无限重试直到成功。如果超过半数的节点复制日志成功就可以任务当前数据请求达成了共识即日志可以commite提交了
两个特点
1如果在不同日志中的两个条目有着相同索引和任期号则所存储的命令是相同的这点是由leader来保证的
2如果在不同日志中的两个条目有着相同索引和任期号则它们之间所有条目完全一样这点是由日志复制的规则来保证的
参考https://zhuanlan.zhihu.com/p/610671151
应用
在设计分布式系统时根据具体的场景和需求可能会结合这两种理论。例如一个电商平台可能会在订单处理系统中优先考虑一致性CAP的C而在商品浏览中优先保证可用性和最终一致性BASE。这样即使在面对网络问题和服务器故障时用户仍能够浏览商品而订单处理则采取措施确保交易数据的准确性。
