面试官：请谈谈写入消息中间件的数据，如何保证不丢失？【石杉的架构笔记】

时间 2019-11-08

标签面试谈谈写入消息中间件数据如何保证丢失石杉的架构笔记栏目快乐工作繁體版

原文原文链接

欢迎关注我的公众号：石杉的架构笔记（ID:shishan100）程序员

周一至周五早8点半！精品技术文章准时送上！面试

精品学习资料获取通道，参见文末算法

（1）背景引入

这篇文章，给你们聊一下写入Kafka的数据该如何保证其不丢失？

看过以前的文章面试官：消息中间件如何实现每秒几十万的高并发写入？的同窗，应该都知道写入Kafka的数据是会落地写入磁盘的。

咱们暂且不考虑写磁盘的具体过程，先大体看看下面的图，这表明了Kafka的核心架构原理。

（2）Kafka分布式存储架构

那么如今问题来了，若是天天产生几十TB的数据，难道都写一台机器的磁盘上吗？这明显是不靠谱的啊！

因此说，这里就得考虑数据的分布式存储了，其实关于消息中间件的分布式存储以及高可用架构，以前的一篇文章面试一线互联网大厂？那这道题目你必须得会！也分析过了，可是这里，咱们结合Kafka的具体状况来讲说。

在Kafka里面，有一个核心的概念叫作“Topic”，这个topic你就姑且认为是一个数据集合吧。

举个例子，若是你如今有一份网站的用户行为数据要写入Kafka，你能够搞一个topic叫作“user_access_log_topic”，这里写入的都是用户行为数据。

而后若是你要把电商网站的订单数据的增删改变动记录写Kafka，那能够搞一个topic叫作“order_tb_topic”，这里写入的都是订单表的变动记录。

而后假如说我们举个例子，就说这个用户行为topic吧，里面若是天天写入几十TB的数据，你以为都放一台机器上靠谱吗？

明显不太靠谱，因此Kafka有一个概念叫作Partition，就是把一个topic数据集合拆分为多个数据分区，你能够认为是多个数据分片，每一个Partition能够在不一样的机器上，储存部分数据。

这样，不就能够把一个超大的数据集合分布式存储在多台机器上了吗？你们看下图，一块儿来体会一下。

（3）Kafka高可用架构

可是这个时候，咱们又会遇到一个问题，就是万一某台机器宕机了，这台机器上的那个partition管理的数据不就丢失了吗？

因此说，咱们还得作多副本冗余，每一个Partition均可以搞一个副本放在别的机器上，这样某台机器宕机，只不过是Partition其中一个副本丢失。

若是某个Partition有多副本的话，Kafka会选举其中一个Parititon副本做为Leader，而后其余的Partition副本是Follower。

只有Leader Partition是对外提供读写操做的，Follower Partition就是从Leader Partition同步数据。

一旦Leader Partition宕机了，就会选举其余的Follower Partition做为新的Leader Partition对外提供读写服务，这不就实现了高可用架构了？

你们看下面的图，看看这个过程。

（4）Kafka写入数据丢失问题

如今咱们来看看，什么状况下Kafka中写入数据会丢失呢？

其实也很简单，你们都知道写入数据都是往某个Partition的Leader写入的，而后那个Partition的Follower会从Leader同步数据。

可是万一1条数据刚写入Leader Partition，还没来得及同步给Follower，此时Leader Partiton所在机器忽然就宕机了呢？

你们看下图：

如上图，这个时候有一条数据是没同步到Partition0的Follower上去的，而后Partition0的Leader所在机器宕机了。

此时就会选举Partition0的Follower做为新的Leader对外提供服务，而后用户是否是就读不到刚才写入的那条数据了？

由于Partition0的Follower上是没有同步到最新的一条数据的。

这个时候就会形成数据丢失的问题。

（5）Kafka的ISR机制是什么？

如今咱们先留着这个问题不说具体怎么解决，先回过头来看一个Kafka的核心机制，就是ISR机制。

这个机制简单来讲，就是会自动给每一个Partition维护一个ISR列表，这个列表里必定会有Leader，而后还会包含跟Leader保持同步的Follower。

也就是说，只要Leader的某个Follower一直跟他保持数据同步，那么就会存在于ISR列表里。

可是若是Follower由于自身发生一些问题，致使不能及时的从Leader同步数据过去，那么这个Follower就会被认为是“out-of-sync”，从ISR列表里踢出去。

因此你们先得明白这个ISR是什么，说白了，就是Kafka自动维护和监控哪些Follower及时的跟上了Leader的数据同步。

（6）Kafka写入的数据如何保证不丢失？

因此若是要让写入Kafka的数据不丢失，你须要要求几点：

每一个Partition都至少得有1个Follower在ISR列表里，跟上了Leader的数据同步
每次写入数据的时候，都要求至少写入Partition Leader成功，同时还有至少一个ISR里的Follower也写入成功，才算这个写入是成功了
若是不知足上述两个条件，那就一直写入失败，让生产系统不停的尝试重试，直到知足上述两个条件，而后才能认为写入成功
按照上述思路去配置相应的参数，才能保证写入Kafka的数据不会丢失

好！如今我们来分析一下上面几点要求。

第一条，必需要求至少一个Follower在ISR列表里。

那必须的啊，要是Leader没有Follower了，或者是Follower都无法及时同步Leader数据，那么这个事儿确定就无法弄下去了。

第二条，每次写入数据的时候，要求leader写入成功之外，至少一个ISR里的Follower也写成功。

你们看下面的图，这个要求就是保证说，每次写数据，必须是leader和follower都写成功了，才能算是写成功，保证一条数据必须有两个以上的副本。

这个时候万一leader宕机，就能够切换到那个follower上去，那么Follower上是有刚写入的数据的，此时数据就不会丢失了。

如上图所示，假如如今leader没有follower了，或者是刚写入leader，leader立马就宕机，还没来得及同步给follower。

在这种状况下，写入就会失败，而后你就让生产者不停的重试，直到kafka恢复正常知足上述条件，才能继续写入。

这样就可让写入kafka的数据不丢失。

（7）总结

最后总结一下，其实kafka的数据丢失问题，涉及到方方面面。

譬如生产端的缓存问题，包括消费端的问题，同时kafka本身内部的底层算法和机制也可能致使数据丢失。

可是平时写入数据遇到比较大的一个问题，就是leader切换时可能致使数据丢失。因此本文仅仅是针对这个问题说了一下生产环境解决这个问题的方案。

End

（封面,图源网络，侵权删除）

扫描下方二维码，备注：“资料”，获取更多“秘制” 精品学习资料

一大波微服务、分布式、高并发、高可用的原创系列文章正在路上

欢迎扫描下方二维码，持续关注：

石杉的架构笔记（id:shishan100）

十余年BAT架构经验倾囊相授