怎样换网站关键词,网站建设怎么更改图片,wordpress站点打不开,福建建设工程有限公司网站我们暂且不考虑写磁盘的具体过程#xff0c;先大致看看下面的图#xff0c;这代表了 Kafka 的核心架构原理。Kafka 分布式存储架构那么现在问题来了#xff0c;如果每天产生几十 TB 的数据#xff0c;难道都写一台机器的磁盘上吗?这明显是不靠谱的啊!所以说#xff0c;这…我们暂且不考虑写磁盘的具体过程先大致看看下面的图这代表了 Kafka 的核心架构原理。Kafka 分布式存储架构那么现在问题来了如果每天产生几十 TB 的数据难道都写一台机器的磁盘上吗?这明显是不靠谱的啊!所以说这里就得考虑数据的分布式存储了我们结合 Kafka 的具体情况来说说。在 Kafka 里面有一个核心的概念叫做“Topic”这个 Topic 你就姑且认为是一个数据集合吧。举个例子如果你现在有一份网站的用户行为数据要写入 Kafka你可以搞一个 Topic 叫做“user_access_log_topic”这里写入的都是用户行为数据。然后如果你要把电商网站的订单数据的增删改变更记录写 Kafka那可以搞一个 Topic 叫做“order_tb_topic”这里写入的都是订单表的变更记录。然后假如说咱们举个例子就说这个用户行为 Topic 吧里面如果每天写入几十 TB 的数据你觉得都放一台机器上靠谱吗?明显不太靠谱所以 Kafka 有一个概念叫做 Partition就是把一个 Topic 数据集合拆分为多个数据分区你可以认为是多个数据分片每个 Partition 可以在不同的机器上储存部分数据。这样不就可以把一个超大的数据集合分布式存储在多台机器上了吗?大家看下图一起来体会一下。Kafka 高可用架构但是这个时候我们又会遇到一个问题就是万一某台机器宕机了这台机器上的那个 Partition 管理的数据不就丢失了吗?所以说我们还得做多副本冗余每个 Partition 都可以搞一个副本放在别的机器上这样某台机器宕机只不过是 Partition 其中一个副本丢失。如果某个 Partition 有多副本的话Kafka 会选举其中一个 Parititon 副本作为 Leader然后其他的 Partition 副本是 Follower。只有 Leader Partition 是对外提供读写操作的Follower Partition 就是从 Leader Partition 同步数据。一旦 Leader Partition 宕机了就会选举其他的 Follower Partition 作为新的 Leader Partition 对外提供读写服务这不就实现了高可用架构了?大家看下面的图看看这个过程Kafka 写入数据丢失问题现在我们来看看什么情况下 Kafka 中写入数据会丢失呢?其实也很简单大家都知道写入数据都是往某个 Partition 的 Leader 写入的然后那个 Partition 的 Follower 会从 Leader 同步数据。但是万一 1 条数据刚写入 Leader Partition还没来得及同步给 Follower此时 Leader Partiton 所在机器突然就宕机了呢?大家看下图如上图这个时候有一条数据是没同步到 Partition0 的 Follower 上去的然后 Partition0 的 Leader 所在机器宕机了。此时就会选举 Partition0 的 Follower 作为新的 Leader 对外提供服务然后用户是不是就读不到刚才写入的那条数据了?因为 Partition0 的 Follower 上是没有同步到最新的一条数据的。这个时候就会造成数据丢失的问题。Kafka 的 ISR 机制是什么?现在我们先留着这个问题不说具体怎么解决先回过头来看一个 Kafka 的核心机制就是 ISR 机制。这个机制简单来说就是会自动给每个 Partition 维护一个 ISR 列表这个列表里一定会有 Leader然后还会包含跟 Leader 保持同步的 Follower。也就是说只要 Leader 的某个 Follower 一直跟他保持数据同步那么就会存在于 ISR 列表里。但是如果 Follower 因为自身发生一些问题导致不能及时的从 Leader 同步数据过去那么这个 Follower 就会被认为是“out-of-sync”被从 ISR 列表里踢出去。所以大家先得明白这个 ISR 是什么说白了就是 Kafka 自动维护和监控哪些 Follower 及时的跟上了 Leader 的数据同步。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 了或者是刚写入 LeaderLeader 立马就宕机还没来得及同步给 Follower。在这种情况下写入就会失败然后你就让生产者不停的重试直到 Kafka 恢复正常满足上述条件才能继续写入。这样就可以让写入 Kafka 的数据不丢失。总结最后总结一下其实 Kafka 的数据丢失问题涉及到方方面面。譬如生产端的缓存问题包括消费端的问题同时 Kafka 自己内部的底层算法和机制也可能导致数据丢失。但是平时写入数据遇到比较大的一个问题就是 Leader 切换时可能导致数据丢失。所以本文仅仅是针对这个问题说了一下生产环境解决这个问题的方案。
