wordpress修改网站icon,mysql数据库网站,设计网站推荐平面,定西企业网站制作正文 在延伸feature#xff08;分布式系统需要考虑的特性#xff09;的时候#xff0c;我逐渐明白#xff0c;这是因为要满足这些feature#xff0c;才设计了很多协议与算法#xff0c;也提出了一些理论。比如说#xff0c;这是因为要解决去中心化副本的一致性问题分布式系统需要考虑的特性的时候我逐渐明白这是因为要满足这些feature才设计了很多协议与算法也提出了一些理论。比如说这是因为要解决去中心化副本的一致性问题才引入了Paxosraft协议。而每一个分布式系统如分布式存储、分布式计算、分布式消息队列、分布式RPC框架根据业务的不同会使用不同的方法来满足这些feature对这些feature的支持也可能会有权衡比如一致性与可用性的权衡。 所有我觉得从分布式的特性出发来一步步学习分布式是一种可行的方式。 从分布式系统的特征出发 分布式的世界中涉及到大量的协议raft、2pc、lease、quorum等、大量的理论FLP CAP等、大量的系统GFS、MongoDB、MapReduce、Spark、RabbitMQ等。这些大量的知识总是让我们无从下手任何一个东西都需要花费大量的时间特别是在没有项目、任务驱动的时候没有一个明确的目标真的很难坚持下去。 所以我一直在思考能有什么办法能把这些东西串起来当我掌握了知识点A的时候能够自然地想到接下来要学习B知识A和B的关系也许是递进的也许是并列的。我也这样尝试了那就是《什么是分布式系统如何学习分布式系统》一文中我提到的思考一个大型网站的架构然后把这些协议、理论串起来。按照这个想法我的计划就是去逐个学习这些组件。 但是其实在这里有一个误区我认为一个大型网站就是一个分布式系统包含诸多组件这些组件是分布式系统的组成部分而我现在认为一个大型网站包含诸多组件每一个组件都是一个分布式系统比如分布式存储就是一个分布式系统消息队列就是一个分布式系统。 为什么说从思考分布式的特征出发是一个可行的、系统的、循序渐进的学习方式呢因为 1先有问题才会去思考解决问题的办法 由于我们要提高可用性所以我们才需要冗余由于需要扩展性所以我们才需要分片 2解决一个问题常常会引入新的问题 比如为了提高可用性引入了冗余而冗余又带来了副本之间的一致性问题所以引入了中心化副本协议primary/secondary)那么接下来就要考虑primary节点故障时候的选举问题。。。 3这是一个金字塔结构或者说也是一个深度优先遍历的过程。 在这个过程中我们始终知道自己已经掌握了哪些知识还有哪些是已经知道但未了解的知识也能知道哪些是空白即我们知道这里可能有很多问题但是具体是什么还不知道。 那么各个分布式系统如何与这些特征相关联呢不难发现每个分布式系统都会或多或少的体现出这些特征只是使用的方法、算法可能不大一样。所以我们应该思考某一个问题在某个特定系统中是如何解决的。比如元数据管理的强一致性在MongoDB中是如何实现的在HDFS中是如何实现的。这也指导了我们如何去学习一个具体的分布式系统带着问题只关注关心的部分而不是从头到尾看一遍。 下面是到目前为止我对分布式特征的思维导图 对于上图需要声明的是第一不一定完全正确第二不完整。这是因为我自己也在学习中可以看到很多分支很短比如去中心化副本协议不是因为这一块没有内容而是我压根儿还没去了解还没去学习。 我会持续跟新这幅脑图的 下一章介绍一下分布式系统的各个特征。 分布式系统的一般特征 任何介绍分布式系统的文章或者书籍都会提到分布式系统的几个特性可扩展性、高性能、高可用、一致性。这几个特性也是分布式系统的衡量指标正是为了在不同的程度上满足这些特性或者说达到这些指标才会设计出各种各样的算法、协议然后根据业务的需求在这些特性间平衡。 那么本章节简单说明为什么要满足这些特性要满足这些特性需要解决什么问题有什么好的解决方案。 可扩展性 Scalability is the capability of a system, network, or process to handle a growing amount of work, or its potential to be enlarged to accommodate that growth. 可扩展性是指当系统的任务work增加的时候通过增加资源来应对任务增长的能力。可扩展性是任何分布式系统必备的特性这是由分布式系统的概念决定的 分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统 分布式系统的出现是为了解决单个计算机无法完成的计算、存储任务。那么当任务规模增加的时候必然就需要添加更多的节点这就是可扩展性。 扩展性的目标是使得系统中的节点都在一个较为稳定的负载下工作这就是负载均衡当然在动态增加节点的时候需要进行任务可能是计算可能是数据存储的迁移以达到动态均衡。 那么首先要考虑的问题就是如何对任务进行拆分将任务的子集分配到每一个节点我们称这个过程问题PartitionSharding
第一分片分式即按照什么算法对任务进行拆分 常见的算法包括哈希hash一致性哈希consistency hash基于数据范围range based。每一种算法有各自的优缺点也就有各自的适用场景。
第二分片的键partition key partition key是数据的特征值上面提到的任何分片方式都依赖于这个partition key那么该如何选择呢 based on what you think the primary access pattern will be partition key会影响到任务在分片之间的均衡而且一些系统中mongodb几乎是不能重新选择partition key的因此在设计的时候就得想清楚
第三分片的额外好处 提升性能和并发不同的请求分发到不同的分片 提高可用性一个分片挂了不影响其他的分片
第四分片带来的问题 如果一个操作需要跨越多个分片那么效率就会很低下比如数据中的join操作
第五元数据管理 元数据记录了分片与节点的映射关系、节点状态等核心信息分布式系统中有专门的节点节点集群来管理元数据我们称之为元数据服务器。元数据服务器有以下特点 高性能cache 高可用冗余 加 快速failover 强一致性同时只有一个节点对外提供服务
第六任务的动态均衡 为了达到动态均衡需要进行数据的迁移如何保证在迁移的过程中保持对外提供服务这也是一个需要精心设计的复杂问题。 可用性 可用性Availability是系统不间断对外提供服务的能力可用性是一个度的问题最高目标就是7 * 24即永远在线。但事实上做不到的一般是用几个9来衡量系统的可用性如下如所示 也就是如果要达到4个9的可用度99.99%那么一年之中只能有52.6分钟不可用这是个巨大的挑战 为什么分布式系统中必须要考虑可用性呢这是因为分布式系统中故障的概率很高。分布式系统由大量异构的节点和网络组成节点可能会crash、断电、磁盘损坏网络可能丢包、延迟、网络分割。系统的规模放大了出故障的概率因此分布式系统中故障是常态。那么分布式系统的其中一个设计目标就是容错在部分故障的情况下仍然对外提供服务这就是可用性。 冗余是提高可用性、可靠性的法宝。 冗余就是说多个节点负责相同的任务在需要状态维护的场景比如分布式存储中使用非常广泛。在分布式计算如MapReduce中当一个worker运行异常缓慢时master会将这个worker上的任务重新调度到其它worker以提高系统的吞吐这也算一种冗余。但存储的冗余相比计算而言要复杂许多因此主要考虑存储的冗余。 维护同一份数据的多个节点称之为多个副本。我们考虑一个问题当向这个副本集写入数据的时候怎么保证并发情况下数据的一致性是否有一个节点有决定更新的顺序这就是中心化、去中心话副本协议的区别。
中心化与去中心化 中心化就是有一个主节点primary master负责调度数据的更新其优点是协议简单将并发操作转变为顺序操作缺点是primar可能成为瓶颈且在primary故障的时候重新选举会有一段时间的不可用。 去中心化就是所有节点地位平等都能够发起数据的更新优点是高可用缺点是协议复杂要保证一致性很难。 提到去中心化比较有名的是dynamocassandra使用了quorum、vector clock等算法来尽量保证去中心化环境下的一致性。对于去中心化这一块目前还没怎么学习所以下面主要讨论中心化副本集。
节点更新策略 primary节点到secondary节点的数据时同步还是异步即客户端是否需要等待数据落地到副本集中的所有节点。 同步的优点在于强一致性但是可用性和性能响应延迟比较差异步则相反。
数据流向 即数据是如何从Primary节点到secondary节点的有链式和主从模式。 链式的优点时充分利用网络带宽减轻primary压力但缺点是写入延迟会大一些。GFSMongoDB默认情况下都是链式。
部分节点写入异常 理论上副本集中的多个节点的数据应该保持一致因此多个数据的写入理论上应该是一个事务要么都发生要么都不发生。但是分布式事务如2pc是一个复杂的、低效的过程因此副本集的更新一般都是best effort 1pc如果失败则重试或者告诉应用自行处理。
primary的选举 在中心化副本协议中primary节点是如何选举出来的当primary节点挂掉之后又是如何选择出新的primary节点呢有两种方式自治系统依赖其他组件的系统。ps这两个名字是我杜撰的 。。。 所谓的自治系统就是节点内部自行投票选择比如mongodbtfszookeeper 依赖其他组件的系统是指primary由副本集之后的组件来任命比如GFS中的primary由masterGFS的元数据服务器任命hdfs的元数据namenode由zookeeper心跳选出。
secondary是否对外提供服务读服务 中心化复制集中secondary是否对外提供读服务取决于系统对一致性的要求。 比如前面介绍到节点更新策略时可能是异步的那么secondary上的数据相比primary会有一定延迟从secondary上读数据的话无法满足强一致性要求。 比如元数据需要强一致性保证所以一般都只会从primary读数据。而且一般称主节点为activemaster从节点为standbyslave。在这种情况下是通过冗余 加上 快速的failover来保证可用性。 一致性 从上面可以看到为了高可用性引入了冗余副本机制而副本机制就带来了一致性问题。当然如果没有冗余机制或者不是数据状态的冗余那么不会出现一致性问题比如MapReduce。 一致性与可用性在分布式系统中的关系已经有足够的研究形成了CAP理论。CAP理论就是说分布式数据存储最多只能同时满足一致性CConsistency、可用性A Availability、分区容错性PPartition Tolerance中的两者。但一致性和可用性都是一个度的问题是0到1而不是只有0和1两个极端。详细可以参考之前的文章《CAP理论与MongoDB一致性可用性的一些思考》 一致性从系统的角度和用户的角度有不同的等级。
系统角度的一致性 强一致性、若一致性、最终一致性
用户角度的一致性 单调读一致性单调写一致性读后写一致性写后读一致性 高性能 正式因为单个节点的scale up不能完成任务因此我们才需要scale out用大量的节点来完成任务分布式系统的理想目标是任务与节点按一定的比例线性增长。
衡量指标 高并发 高吞吐 低延迟 不同的系统关注的核心指标不一样比如MapReduce本身就是离线计算无需低延迟
可行的办法 单个节点的scaleup 分片partition 缓存比如元数据 短事务
