无痴迷,不成功 阅读(5) 评论(0)

写在前面

在当今信息爆炸的时代,单台计算机已经无法负载日益增长的业务发展,虽然也有性能强大的超级计算机,但是这种高端机不仅费用高昂,也不灵活,一般的企业是负担不起的,而且也损失不起,那么将一群廉价的普通计算机组合起来,让它们协同工作就像一台超级计算机一样地对外提供服务,就成了顺其自然的设想,但是这又增加了软件的复杂度,要求开发的软件需要具备横向扩展能力,比如:Kafka、Elasticsearch、Zookeeper等就属于这一类软件,它们天生都是"分布式的",即可以通过添加机器节点来共同地分摊数据存储和负载压力。

为什么需要集群?

分布在不同区域的计算机,彼此之间通过网络建立通信,相互协作作为一个整体对外提供服务,这就是集群,如果我们开发的系统具备这样的能力,那么理论上就具备无限横向扩容的能力,系统的吞吐量就会随着机器数增加而增长,那么未来当系统出现高负载的时候,就可以很好地应对这种情况。

为什么CAP不能同时满足?

通过上面分析,我们知道实现集群,其实就是采用多台计算机来共同承担和负载系统压力,那么就涉及到多台计算机需要参与一起处理数据,为了保证可用性,一般都会在每台计算机上备份一份数据,这样只要有一个节点保持同步状态,那么数据就不会丢失,比如kafka分区多副本、Elasticsearch的副本分片,由于同一数据块及其副本位于不用的机器,随着时间的推移,再加上不可靠的网络通信,所有机器上的数据必然会不完全一致,这个时候假如发生一种极端情况,所有的机器宕机了,又如何保证数据不丢失呢(其实只有两种方法)?

  1. 保证可用性:选择第一台恢复正常服务的机器(不一定拥有全部数据)作为可信的数据来源,快速恢复集群,即停机时间优于同步。
  2. 保证数据一致性:等待第一台拥有全部数据的机器恢复正常,再恢复集群,即同步优于停机时间,比如禁用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): 所有备份都保存成功返回。

    备注:默认情况下,为了保证分区的最大可用性,当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),即节点间的信任问题,也许区块链可以解决吧,大家可以下去多多研究,然后我们一起讨论,共同学习,一起进步。

写在最后

分享了这么多,请大家总结一下大多数投票机制的优点和缺点?欢迎评论区留言,哈哈,真的要睡觉了,晚安。