在当今信息爆炸的时代,单台计算机已经没法负载日益增加的业务发展,虽然也有性能强大的超级计算机,可是这种高端机不只费用高昂,也不灵活,通常的企业是负担不起的,并且也损失不起,那么将一群廉价的普通计算机组合起来,让它们协同工做就像一台超级计算机同样地对外提供服务,就成了顺其天然的设想,可是这又增长了软件的复杂度,要求开发的软件须要具有横向扩展能力,好比:Kafka、Elasticsearch、Zookeeper等就属于这一类软件,它们天生都是"分布式的",便可以经过添加机器节点来共同地分摊数据存储和负载压力。html
分布在不一样区域的计算机,彼此之间经过网络创建通讯,相互协做做为一个总体对外提供服务,这就是集群,若是咱们开发的系统具有这样的能力,那么理论上就具有无限横向扩容的能力,系统的吞吐量就会随着机器数增长而增加,那么将来当系统出现高负载的时候,就能够很好地应对这种状况。node
经过上面分析,咱们知道实现集群,其实就是采用多台计算机来共同承担和负载系统压力,那么就涉及到多台计算机须要参与一块儿处理数据,为了保证可用性,通常都会在每台计算机上备份一份数据,这样只要有一个节点保持同步状态,那么数据就不会丢失,好比kafka分区多副本、Elasticsearch的副本分片,因为同一数据块及其副本位于不用的机器,随着时间的推移,再加上不可靠的网络通讯,全部机器上的数据必然会不彻底一致,这个时候假如发生一种极端状况,全部的机器宕机了,又如何保证数据不丢失呢(其实只有两种方法)?算法
其实当大多数机器不可用时,就须要在可用性和一致性之间进行妥协了,因此另外一个更符合分布式系统的Base理论又被创造出来了。apache
当由多台计算机组成的集群对外提供服务时,其实就是对外提供读、写的能力。数组
为了将数据合理、均匀地写到各个机器上,提升集群写能力;为了将读请求负载均衡到不一样的节点,提升集群的读能力;为了解耦数据存储和物理节点,提升分布式读写并行处理的能力,聪明的工程师引入了一个逻辑数据存储单位,统称为数据块,好比Kafka的分区(partion)、Elasticsearch的分片(shard),这样的虚拟化大大提升了集群读写的灵活性。服务器
备注:因此啊,名字不重要,知其因此然最重要。网络
实际上当集群做为一个总体处理数据时,可能每个节点都会收到读写请求,可是数据又是分散在不一样的节点上,因此就须要每一个节点都清楚地知道集群中任意一个数据块的位置,而后再将请求转发到相应的节点,这就是“协调节点”的工做。好比:Elasticsearch的master节点管理集群范围内的全部变动,主分片管理数据块范围内的全部变动。负载均衡
百度百科: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内部自动将相同的分片放到了不一样的节点,很是合理和理想。 当咱们新建一个文档时:
这就是Elasticsearch处理写请求的典型步骤顺序,同时每种业务场景对数据可靠性的要求和系统性能也不同,因此Elasticsearch提供了Consistence配置项:
Kafka 当向Kafka 写数据时,producers能够经过设置ack来自定义数据可靠性的级别:
备注:默认状况下,为了保证分区的最大可用性,当acks=all时,只要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,好比副本因子是3,header占据1位,再有1位最快的follower同步完成,就知足大多数了。
大多数(n+1)的节点挂掉就没法选举leader,从而整个集群完全失去可用性,好比:为了冗余单点故障,一般须要三个节点备份数据,可是当其中两台挂掉时,整个集群就挂了。仅仅靠冗余数据来避免单点故障是不够,一般对磁盘空间需求量为2n+1倍,相应地也会致使写吞吐量降低2n+1倍,这种高昂的存储方式并不适合存储原始数据,这就是为何quorum算法更适合共享集群配置数据,如zookeeper,这也是kafka为何要引入一个同步状态备份集合(ISR),经过下降所需的备份数据而带来额外的吞吐量和磁盘空间,从而提升kafka处理海量实时数据的能力。