11

Kafka 高可用架构 (3)

 3 years ago
source link: https://my.oschina.net/u/1019754/blog/5001230
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Controller选举

当添加一个分区或分区增加副本的时候,都要从所有副本中选举一个新的Leader出来。

Leader如果选举?投票怎么玩?是不是所有的partition副本直接发起投票,开始竞选呢?比如用ZK实现。

利用ZK如何实现选举?ZK的什么功能可以感知到节点的变化(增加或减少)?或者说ZK为什么能实现加锁和释放锁?

用到了3个特点:watch机制;节点不允许重复写入;临时节点。

这样实现是比较简单,但也会存在一定弊端。如果分区和副本数量过多,所有的副本都直接选举的话,一旦某个节点增减,就会造成大量watch事件被触发,ZK的负载就会过重。

kafka早期的版本就是这样做的,后来换了一种实现方式。

不是所有的repalica都参与leader选举,而是由其中的一个Broker统一来指挥,这个Broker的角色就叫做Controller(控制器)。

就像Redis Sentinel的架构,执行故障转移的时候,必须要先从所有哨兵中选一个负责故障转移的节点一样。kafka 也要先从所有Broker中选出唯一的一个Controller。

所有Broker会尝试在zookeeper中创建临时节点/controller,只有一个能创建成功(先到先得)。

如果Controller挂掉了或者网络出现了问题,ZK上的临时节点会消失。其他的Brokder通过watch监听到Controller下线的消息后,开始竞选新的Controller。方法跟之前还是一样的,谁先在ZK里写入一个/cotroller节点,谁就成为新的Controller。

成为Controller节点之后,它的责任也比其他节点重了几分:

  1. 监听Broker变化
  2. 监听Topic变化
  3. 监听Partition变化
  4. 获取和管理Broker、Topic、Partition的信息
  5. 管理Partiontion的主从信息

分区副本Leader选举

Controller确定以后,就可以开始做分区选主的事了。下面就是找候选人了。显然,每个replica都想推荐自己,但所有的replica都有竞选资格吗?并不是,这里有几个概念。

Assigned-Replicas(AR):一个分区的所有副本。 In-Sync Replicas(ISR):上边所有副本中,跟leader数据保持一定程度同步的。 Out-Sync Replicas(OSR):跟leader同步滞后过多的副本。

AR=ISR + OSR。正常情况下OSR是空的,大家正常同步,AR=ISR。

谁能参加选举?肯定不是AR,也不是OR,而是ISR。而且这个ISR不是固定不变的,还是一个动态列表。

前面说过,如果同步延迟超30秒,就踢出ISR,进入OSR;如果赶上来了就加入ISR。

默认情况下,当leader副本发生故障时,只有在ISR集合中的副本才有资格被选举为新的leader。

如果ISR为空呢?群龙不能无首。在这种情况下,可以让ISR之外的副本参与选举。允许ISR之外的副本参与选举,叫做unclean leader election。

unclean.leader.election.enable=false

把这个参数改成true(一般不建议开启,会造成数据丢失)。

Controller有了,候选人也有了ISR,那么根据什么规则确定leader呢?

我们首先来看分布式系统中常见的选举协议有哪些(或者说共识算法)?

ZAB(ZK)、Raft(Redis Sentinel)他们都是Paxos算法的变种,核心思想归纳起来都是:先到先得、少数服从多数。

但kafka没有用这些方法,而是用了一种自己实现的算法。

为什么呢?比如ZAB这种协议,可能会出现脑裂(节点不能互通的时候,出现多个leader)、惊群效应(大量watch事件被触发)。

在文档中有说明:

https://kafka.apachecn.org/documentation.html#design_replicatedlog

提到kafka的选举实现,最相近的是微软的PacificA算法。

在这种算法中,默认是让ISR中第一个replica变成leader。像中国皇帝传位一样,优先传给皇长子。

leader确定之后,客户端的读写只能操作leader节点。follower需要向leader同步数据。

不同的raplica的offset是不一样的,同步到底怎么同步呢?

在之后内容,需要先理解几个概念。

LEO(Log End Offset):下一条等待写入的消息的offset(最新的offset + 1)。

HW(Hign Watermark 高水位):ISR中最小的LEO。Leader会管理所有ISR中最小的LEO为HW。

consumer最多只能消费到HW之前的位置。也就是说,其他副本没有同步过去的消息,是不能被消费的。

kafka为什么这么设计?

如果在同步成功之前就被消费了,consumer group 的offset会偏大,如果leader崩溃,中间会丢失消息。

接着再看消息是如何同步的。

Replica 1与Replica2各同步了1条数据,HW推进了1,变成了7,LEO因Replica2推进了1,变成了7。

Replica 1与Replica2各同步了2条数据,HW和LEO重叠,都到了9。

在这需要了解一下,从节点如何与主节点保持同步?

  1. follower节点会向Leader发送一个fetch请求,leader向follower发送数据后,即需要更新follower的LEO。
  2. follower接收到数据响应后,依次写入消息并且更新LEO。
  3. leader更新HW(ISR最小的LEO)

kafka设计了独特的ISR复制,可以在保障数据一致性情况下又可以提供高吞吐量。

Replica故障处理

follower故障

首先follower发生鼓掌,会被先踢出ISR。

follower恢复之后,从哪开始同步数据呢?

假设Replica1宕机。

恢复以后,首先根据之前的记录的HW(6),把高于HW的消息截掉(6、7)。

然后向Leader同步消息。追上Leader之后(30秒),重新加入ISR。

leader故障

还以上图为例,如果图中Leader发生故障。

首先选一个Leader,因为Replica1优先,它将成为Leader。

为了保证数据一致,其他follower需要把高于HW的消息截掉(这里没有消息需要截取)。

然后Replica2同步数据。

此时原Leader中的数据8将丢失。

注意:这种机制只能保证副本之间的数据一致性,并不能保证数据不丢失或者不重复。


Recommend

  • 171

    携程运维架构揭秘:高可用架构最佳实践之路-51CTO.COM 携程运维架构揭秘:高可用架构最佳实践之路 作者:周源 2017-10-09 09:12:35 携程的架构经历了长期的演变和迭代,其中多个产品...

  • 68

  • 73

    MHA:MasterHA,对主节点进行监控,可实现自动故障转移至其它从节点;通过提升某一从节点为新的主节点,基于主从复制实现,还需要客户端配合实现,目前MHA主要支持一主多从的架构,要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器,一主二从,即一台充当m...

  • 28
    • 微信 mp.weixin.qq.com 6 years ago
    • Cache

    高可用架构

  • 33
    • www.linuxprobe.com 6 years ago
    • Cache

    熟悉MySQL数据库的高可用架构方案

    MySQL高可用设计方案,如果单MySQL的优化始终还是顶不住压力时,这个时候我们就必须考虑MySQL的集群方案了,目前可行的方案有: 一、MySQL Cluster 优势:可用性非常高,性能非常好。每份数据至少可在不同主机...

  • 61

    前两天逛博客偶然发现了某大神写的关于MMM的文章,看完就迫不及待的自己试了一下,大神写的很顺畅,以为自己也能操作的很顺畅,但是实际情况是手脚太不麻利,碰到很多坑,如果大神的文章是“平地起高楼”,那我这篇则是“平房起别墅”,因为我生产环境中已经有两台Mysql...

  • 62
    • 微信 mp.weixin.qq.com 5 years ago
    • Cache

    图解 kafka 的高可用机制

    对于一个复杂的分布式系统,如果没有丰富的经验和牛逼的架构能力,很难把系统做得简单易维护,我们都知道,一个软件的生命周期中,后期维护占了70%,所以系统的可维护性是极其重要的, kafka 能成为大数据领域的事实标准,很大原因是因为...

  • 11

    Kafka宕机引发的高可用问题 问题要从一次Kafka的宕机开始说起。 笔者所在的是一家金融科技公司,但公司内部并没有采用在金融支付领域更为流行的RabbitMQ,而是采用了设计之初就为日志处理而生的Kafka,所以我一直很好...

  • 10

    ELK架构下利用Kafka Group实现Logstash的高可用 系统运维的过程中,每一个细节都值得我们关注 下图为我们的基本日志处理架构

  • 5

    在 Kubernetes 上运行高可用的 Kafka 集群-阳明的博客|Kubernetes|Istio|Prometheus|Python|Golang|云原生 Morning glory Apache Kafka 是目前最流行的分布式消息发布订阅系统,虽然 Kafka 非常强大,但它同样复杂,需...

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK