通过zookeeper浅谈一致性算法

这篇具有很好参考价值的文章主要介绍了通过zookeeper浅谈一致性算法。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

CAP定理介绍

CAP 定理指的是在一个分布式系统中,Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可兼得。

通俗来说:

一致性(C):当系统数据发生更新操作后,各个主机中的数据仍然处于一致的状态。

可用性(A):对于用户的每一个请求,系统总是可以在有限的时间内对用户做出响应。

分区容错性(P):分布式系统在遇到任何网络分区故障时,仍能够保证对外提供满足一致性或可用性的服务。

对于分布式系统来说,网络🛜环境是相对不可控制的,出现网络分区是不可避免的。网络分区的出现很可能就会带来脑裂问题(例如:机房之间的网络通信出现故障),这就会导致集群分裂成两个或多个,它们都认为只有自己没有崩溃,都可以独立运行。对于zk这分布式协调系统来说,数据的一致性是基本的要求,它需要保证在任何时刻访问都能得到一致性的数据结果,所以分区容错性是需要保证的。zk默认是通过“过半机制”防止脑裂的。

不难发现,一致性和可用性是不能同时保证的。原因:数据同步是需要时间的,在同步的期间,若允许client访问,则client从不同节点读取到的数据就可能是不同的(牺牲了一致性保证了可用性)。若不允许client访问,则client在同步期间无法获取服务,但是在同步后无论访问哪个节点读取的数据都会是一样的(牺牲了可用性从而保证一致性)。

网络分区是指在分布式系统中,由于网络故障、节点故障等原因,导致集群中的节点被分割成多个独立的子集,每个子集之间无法进行通信的现象。网络分区会导致分布式系统的可用性和一致性受到影响,因此需要采取一定的措施来避免或解决网络分区问题。

BASE 理论

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent(最终一致性)三个短语的简写,BASE 是对 CAP 中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的结论,是基于 CAP 定理逐步演化而来的。

BASE 理论的核心思想是:即使无法做到强一致性,但每个系统都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性。

1.基本可用:分布式系统出现不可预知故障的时候,允许损失部分可用性。体现在:响应时间上的损失 和 功能上的损失(服务降级)。

2.软状态:允许系统数据存在的中间状态,并认为该中间状态的存在不会影响系统的整体可用性。例如允许zk之间的数据同步存在一定的数据延迟。

3.最终一致性:强调所有的数据副本在经过一段时间后,最终能够达到一个一致性的状态。

从zk的角度谈cp

在zk集群中,leader节点宕机后,整个集群会有一段时间是不能被访问的,后面又可以访问了。在这段不可访问的时间内,zk集群是在做leader选举,期间是不接受客户端的读写操作的。也可以这么理解在leader选举期间,zk集群是处于瘫痪期间的,同步完毕后读取到的数据是一致性的数据。满足了一致性,牺牲了一定的可用性。

分布式一致性

通俗来说,分布式事务是将多个操作组成一个事务来完成,并且这多个操作要么一起成功,要么一起失败。这个很有名的一个处理分布式事务的组件就是阿里的seats。一般分布式一致性是由分布式事务实现的,需要保证客户端从分布式系统中的每一个server节点获取的数据,在某一段时间是可以保证是一致的(最终一致性)。

2PC算法:每一个server对本地事务的确认,需要经历两个阶段,prepare阶段和commit阶段。在MySQL中通过2pc保证Redo和Binlog的保持一致。1)当事务提交时InnoDB存储引擎进行prepare操作,将数据写入到binglog日志中。2)InnoDB存储引擎将事务写入到Redo Log文件中。在seata的事务模式中XA,AT,TCC都是2PC的。

3PC算法:在2PC的基础上新增一个Accept阶段(提交指令阶段)。该阶段主要是事务协调者(TC)向资源管理者(RM)发送accept指令,RM收到指令后判断是否可以完成自己的事物并且将判断结果给TC。

Paxos算法:该算法要解决的问题是在分布式系统中如何就某个决议达成一致。ZAB(Zookeeper Atomic Broadcast)协议是Paxos算法的一种工业实现。在zookeeper中使用一个单一主进程来接收并处理客户端的所有请求(写请求),当数据发生变更,ZAB采用原子广播协议,以事务提案 Proposal 的形式广播到所有的副本进程上并且为每一个事务分配一个全局递增的编号Xid. 客户端连接到一个z k集群后,如果是读请求,那么当前节点就会根据自己保存的数据对其进行相应数据返回。如果是写请求并且不是leader节点,那么当前节点就会首先将请求转发给leader节点,leader节点以提案的方式广播该写操作,只有超过过半的节点同意该写操作该写请求才会被提交,然后leader广播给所有的follower节点,通知它们同步数据。文章来源地址https://www.toymoban.com/news/detail-724208.html

到了这里,关于通过zookeeper浅谈一致性算法的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 分布式一致性算法Paxos

            Paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法,是目前公认的解决分布式一致性问题最有效的算法之一。Google Chubby的作者Mike Burrows曾经狂妄的说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品。         Paxos算法是

    2023年04月16日
    浏览(47)
  • 分布式一致性算法——Paxos 和 Raft 算法

    本文隶属于专栏《100个问题搞定大数据理论体系》,该专栏为笔者原创,引用请注明来源,不足和错误之处请在评论区帮忙指出,谢谢! 本专栏目录结构和参考文献请见100个问题搞定大数据理论体系 Paxos和Raft算法都是 分布式一致性算法 ,它们的目的都是 在一个分布式系统

    2024年01月20日
    浏览(53)
  • 分布式系统共识机制:一致性算法设计思想

    这次以一个宏观的角度去总结 自己学习过的一致性算法。一致性算法的目标就是让分布式系统里的大部分节点 保持数据一致。 区块链中的共识算法,pow、pos这类就属于这个范围,但他们仅仅是在区块链领域内应用的,下面介绍一致性算法是在分布式系统中 应用广泛的,当然

    2023年04月16日
    浏览(42)
  • 论文阅读-Pegasus:通过网络内一致性目录容忍分布式存储中的偏斜工作负载

    论文名称: Pegasus: Tolerating Skewed Workloads in Distributed Storage with In-Network Coherence Directories 高性能分布式存储系统面临着由于偏斜和动态工作负载引起的负载不平衡的挑战。本文介绍了Pegasus,这是一个利用新一代 可编程交换机ASIC 来平衡存储服务器负载的新型存储系统。Pegasus使

    2024年02月20日
    浏览(50)
  • 一文通吃:从 ZooKeeper 一致性,Leader选举讲到 ZAB 协议与 PAXOS 算法(上)

    本文首发自「慕课网」,想了解更多IT干货内容,程序员圈内热闻,欢迎关注\\\"慕课网\\\"或慕课网公众号! 作者:大能 | 慕课网讲师 本文将从ZooKeeper集群如何保证一致性,讲到zookeeper保证数据一致性的协议,然后展开讲Zookeeper集群Leader选举,包括集群三种节点的类型,ZAB协议中

    2024年02月07日
    浏览(44)
  • 浅谈缓存最终一致性的解决方案

    作者:clareguo,腾讯 CSIG 后台开发工程师 来源:腾讯技术工程open in new window 到底是更新缓存还是删除缓存? 到底是先更新数据库,再删除缓存,还是先删除缓存,再更新数据库? 对于互联网业务来说,传统的直接访问数据库方式,主要通过数据分片、一主多从等方式来扛住读

    2024年01月16日
    浏览(44)
  • ZooKeeper是如何保证数据一致性的?

             目录 一、分布式一致性原理 二、ZooKeeper架构         2.1 ZAB 协议操作顺序性         2.2 领导者选举         成员身份         成员状态         领导者选举 三、总结         在分布式系统里的多台服务器要对数据状态达成一致,其实是一件很有难度和挑

    2024年04月11日
    浏览(36)
  • 深入理解高并发下的MySQL与Redis缓存一致性问题(增删改查数据缓存的一致性、Canal、分布式系统CAP定理、BASE理论、强、弱一致性、顺序、线性、因果、最终一致性)

    一些小型项目,或极少有并发的项目,这些策略在无并发情况下,不会有什么问题。 读数据策略:有缓存则读缓存,然后接口返回。没有缓存,查询出数据,载入缓存,然后接口返回。 写数据策略:数据发生了变动,先删除缓存,再更新数据,等下次读取的时候载入缓存,

    2024年03月20日
    浏览(39)
  • 【分布式】一致性哈希和哈希槽

    当我们拥有了多台存储服务器之后,现在有多个key,希望可以将这些个key均匀的缓存到这些服务器上,可以使用哪些方案呢? 1.1 直接哈希取模 这是一种最容易想到的方法,使用取模算法hash(key)% N,对key进行hash运算后取模,N是机器的数量。key进行hash后的结果对3取模,得

    2024年02月03日
    浏览(35)
  • 分布式数据库-事务一致性

    version: v-2023060601 author: 路__ 分布式数据库的“强一致性”应该包含两个方面: serializability(串行) and linearizability(线性一致) ,上述图为“Highly Available Transactions: Virtues and Limitations”论文中对于一致性模型的介绍。图中箭头表示一致性模型之间的关系。对于异步网络上的分

    2024年02月08日
    浏览(39)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包