布吉网站建设哪家效益快,爱剪辑,长安seo排名优化培训,网站建设张家港写在前面 在当今信息爆炸的时代#xff0c;单台计算机已经无法负载日益增长的业务发展#xff0c;虽然也有性能强大的超级计算机#xff0c;但是这种高端机不仅费用高昂#xff0c;也不灵活#xff0c;一般的企业是负担不起的#xff0c;而且也损失不起#xff0c;那么将…写在前面 在当今信息爆炸的时代单台计算机已经无法负载日益增长的业务发展虽然也有性能强大的超级计算机但是这种高端机不仅费用高昂也不灵活一般的企业是负担不起的而且也损失不起那么将一群廉价的普通计算机组合起来让它们协同工作就像一台超级计算机一样地对外提供服务就成了顺其自然的设想但是这又增加了软件的复杂度要求开发的软件需要具备横向扩展能力比如Kafka、Elasticsearch、Zookeeper等就属于这一类软件它们天生都是分布式的即可以通过添加机器节点来共同地分摊数据存储和负载压力。 为什么需要集群 分布在不同区域的计算机彼此之间通过网络建立通信相互协作作为一个整体对外提供服务这就是集群如果我们开发的系统具备这样的能力那么理论上就具备无限横向扩容的能力系统的吞吐量就会随着机器数增加而增长那么未来当系统出现高负载的时候就可以很好地应对这种情况。 为什么CAP不能同时满足 通过上面分析我们知道实现集群其实就是采用多台计算机来共同承担和负载系统压力那么就涉及到多台计算机需要参与一起处理数据为了保证可用性一般都会在每台计算机上备份一份数据这样只要有一个节点保持同步状态那么数据就不会丢失比如kafka分区多副本、Elasticsearch的副本分片由于同一数据块及其副本位于不用的机器随着时间的推移再加上不可靠的网络通信所有机器上的数据必然会不完全一致这个时候假如发生一种极端情况所有的机器宕机了又如何保证数据不丢失呢其实只有两种方法 保证可用性选择第一台恢复正常服务的机器不一定拥有全部数据作为可信的数据来源快速恢复集群即停机时间优于同步。保证数据一致性等待第一台拥有全部数据的机器恢复正常再恢复集群即同步优于停机时间比如禁用kafka的unclean leader选举机制就是这种策略。其实当大多数机器不可用时就需要在可用性和一致性之间进行妥协了所以另一个更符合分布式系统的Base理论又被创造出来了。 如何解决分布式存储问题 当由多台计算机组成的集群对外提供服务时其实就是对外提供读、写的能力。 数据块技术data block 为了将数据合理、均匀地写到各个机器上提高集群写能力为了将读请求负载均衡到不同的节点提高集群的读能力为了解耦数据存储和物理节点提高分布式读写并行处理的能力聪明的工程师引入了一个逻辑数据存储单位统称为数据块比如Kafka的分区(partion)、Elasticsearch的分片(shard)这样的虚拟化大大提高了集群读写的灵活性。 备注所以啊名字不重要知其所以然最重要。 协调节点coordination node 实际上当集群作为一个整体处理数据时可能每一个节点都会收到读写请求但是数据又是分散在不同的节点上所以就需要每个节点都清楚地知道集群中任意一个数据块的位置然后再将请求转发到相应的节点这就是“协调节点”的工作。比如Elasticsearch的master节点管理集群范围内的所有变更主分片管理数据块范围内的所有变更。 大多数投票机制quorum 百度百科quorum翻译法定人数指举行会议、通过议案、进行选举或组织某种专门机构时法律所规定的必要人数未达法定人数无效。 由于网络分区的存在这个机制被广泛地应用于分布式系统中比如集群节点之间选举Master数据块之间选举Header等在分布式存储中也被称为Quorum读写机制即写入的时候保证大多数节点都写入成功一般的做法会选举一个主数据块(header)保证它写成功然后再同步到冗余的副本数据块读取的时候保证读取大多数节点的数据一般的做法是由协调节点分发请求到不同的节点然后将所有检索到的数据进行全局汇总排序后再返回由于读写都是大多数那么中间肯定存在最新的重叠数据这样就能保证一定能读到最新的数据。 从上面分析可以得出只要大多数节点处于活跃可用状态那么整个集群的可用性就不会受到影响只要大多数据块处于活跃可用的状态那么就能持续地提供读写服务只要有一个数据块完成了同步状态那么数据就不会丢失这其实就是通过一种冗余机制来尝试处理fail/recover模式的故障通俗点讲就是容忍单点故障至少需要部署3个节点容忍2点故障至少需要部署5个节点机器节点越多分区容忍性就越强即通过增加机器数来降低由于机器故障影响服务的概率顿悟了吧嘿嘿所以保证集群可用的前提就是有奇数个节点、奇数个数据块保持活跃可用状态不然就无法选举出master或header。 大多数投票机制运用起来也非常灵活当分布式系统追求强一致性时需要等待所有的数据快及其副本全部写入成功才算完成一次写操作即写全部(write all)可以理解一种事务保证要么全部写入要么一个都不写入比如kafka从0.11.0.0 版本开始 当producer发送消息到多个topic partion时就运用了这种机制来保证消息交付的exactly-once语义是不是很帅而且这种情况下从任意一个节点都能读到最新的数据读性能最高当分布式系统追求最终一致性时只需等待主数据块(leader)写入成功即可再由主数据块通过消息可达的方式同步到副本数据块。 为了能够满足不同场景下对数据可靠性和系统吞吐量的要求最大化数据持久性和系统可用性很多组件都提供了配置项允许用户定义这个大多数的法定数量下面我们就来谈谈一些常用组件的配置 Elasticsearch 由上图可以看到整个集群由三个运行了Elasticsearch实例的节点组成有两个主分片每个分片又有两个副分片总共有6个分片拷贝Elasticsearch内部自动将相同的分片放到了不同的节点非常合理和理想。当我们新建一个文档时 1、客户端向 Node 1 发送新建文档的写请求。2、节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3因为分片 0 的主分片目前被分配在 Node 3 上。3、Node 3 在主分片上面执行请求。如果成功了它将请求并行转发到 Node 1 和 Node 2 的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功协调节点向客户端报告成功。这就是Elasticsearch处理写请求的典型步骤顺序同时每种业务场景对数据可靠性的要求和系统性能也不一样所以Elasticsearch提供了Consistence配置项 1、one主分片处于活跃可用状态就可以处理写请求。 系统吞吐量最高但数据可能会丢失对数据可靠性要求不是很高的场景非常适合比如实时的时序数据处理日志。2、all主分片和所有副本分片处于活跃可用状态才允许处理写请求。 系统吞吐量最低但数据不会丢失。处理关键的业务数据非常合适。3、quorum必须有大多数的分片拷贝处于活跃可用状态才允许处理写请求。 平衡系统吞吐量和数据可靠性一般业务系统都使用这个配置。Kafka 当向Kafka 写数据时producers可以通过设置ack来自定义数据可靠性的级别 0不等待broker返回确认消息。1: leader保存成功返回。-1(all): 所有备份都保存成功返回。 备注默认情况下为了保证分区的最大可用性当acksall时只要ISR集合中的副本分区写入成功kafka就会返回消息写入成功。如果要真正地保证写全部(write all)那么我们需要更改配置transaction.state.log.min.isr来指定topic最小的ISR集合大小即设置ISR集合长度等于topic的分区数。 如果所有的节点都挂掉还有Unclean leader选举机制的保证建议大家下去阅读kafka《官方指南》设计部分深入理解kafka是如何通过引入ISR集合来变通大多数投票机制从而更好地保证消息交付的不同语义。 什么是集群脑裂 对于分布式系统自动处理故障的关键就是能够精准地知道节点的存活状态(alive)。有时候节点不可用不一定就是其本身挂掉了极有可能是暂时的网络故障在这种情况下如果马上选举一个master节点那么等到网络通信恢复正常的时候岂不是同时存在两个master这种现象被形象地称为“集群脑裂”先留给大家下去思考吧。呵呵明天要早起碎觉了大家晚安。 备注设计一个正在高可用的分布式系统需要考虑的故障情况往往会很复杂大多数组件都只是处理了fail/recover模式的故障即容忍一部分节点不可用然后等待恢复并没有处理拜占庭故障(Byzantine)即节点间的信任问题也许区块链可以解决吧大家可以下去多多研究然后我们一起讨论共同学习一起进步。 写在最后 分享了这么多请大家总结一下大多数投票机制的优点和缺点欢迎评论区留言哈哈真的要睡觉了晚安。 补充大多数投票机制的优缺点 由于昨晚太晚了第二天又要早起参加团建活动对于最后就抛出的问题希望大家下去总结一下大多数投票的优缺点现在就来补充一下。 优点 大多数投票机制延迟取决于最快的服务器即等待数据备份完成的等待时间取决于最快的follower比如副本因子是3header占据1位再有1位最快的follower同步完成就满足大多数了。 缺点 大多数(n1)的节点挂掉就无法选举leader从而整个集群彻底失去可用性比如为了冗余单点故障通常需要三个节点备份数据但是当其中两台挂掉时整个集群就挂了。仅仅靠冗余数据来避免单点故障是不够通常对磁盘空间需求量为2n1倍相应地也会导致写吞吐量下降2n1倍这种高昂的存储方式并不适合存储原始数据这就是为什么quorum算法更适合共享集群配置数据如zookeeper这也是kafka为什么要引入一个同步状态备份集合(ISR)通过降低所需的备份数据而带来额外的吞吐量和磁盘空间从而提高kafka处理海量实时数据的能力。 转载于:https://www.cnblogs.com/justmine/p/9275730.html
