通过kafka学习数据一致性

这篇具有很好参考价值的文章主要介绍了通过kafka学习数据一致性。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

kafka哪些环节存在数据不一致

数据复制

数据从主节点(leader)复制到从节点(follower)的过程中,由于网络延迟、节点故障或其他原因
可能导致从节点未能及时获取或处理主节点的数据变更,从而产生数据不一致

消息提交

消息提交涉及多个阶段,包括生产者发送消息、消息被写入日志、消息被复制到从节点等。
如果在这个过程中发生错误或异常,可能导致消息丢失或重复,进而引发数据不一致。

消费者处理

消费者在处理消息时,如果因为某些原因(如网络中断、消费者进程崩溃等)未能成功处理消息
而消息又被重新投递给其他消费者处理,也可能导致数据不一致。

分区重新分配

在Kafka中,如果分区的leader节点发生故障,Kafka会触发分区重新分配,将leader切换到其他节点
在这个过程中,如果切换不及时或切换过程中发生错误,可能导致数据不一致。

kafka如何保证数据一致性

一条消息从生产到消费完成,可以划分三个阶段:
• 生产阶段:从消息在 Producer 创建出来,经过网络传输发送到 Broker 端。
• 存储阶段:消息在 Broker 端存储,如果是集群,消息会在这个阶段被复制到其他的副本上
• 消费阶段:Consumer 从 Broker 上拉取消息,经过网络传输发送到Consumer上

消息传递语义

首先当 Producer 向 Broker 发送数据后,会进行 commit,如果 commit 成功,由于 Replica 副本机制的存在,则意味着消息不会丢失,但是 Producer 发送数据给 Broker 后,遇到网络问题而造成通信中断,那么 Producer 就无法准确判断该消息是否已经被提交(commit),这就可能造成 at least once 语义。

在 Kafka 0.11.0.0 之前, 如果 Producer 没有收到消息 commit 的响应结果,它只能重新发送消息,确保消息已经被正确的传输到 Broker,重新发送的时候会将消息再次写入日志中;而在 0.11.0.0 版本之后, Producer 支持幂等传递选项,保证重新发送不会导致消息在日志出现重复。为了实现这个, Broker 为 Producer 分配了一个ID,并通过每条消息的序列号进行去重。也支持了类似事务语义来保证将消息发送到多个 Topic 分区中,保证所有消息要么都写入成功,要么都失败,这个主要用在 Topic 之间的 exactly once 语义。

启用幂等传递的方法配置:enable.idempotence = true
启用事务支持的方法配置:设置属性 transcational.id = “指定值”

从 Consumer 角度来剖析, Offset 是由 Consumer 自己来维护的, 如果 Consumer 收到消息后更新 Offset, 这时 Consumer 异常 crash 掉, 那么新的 Consumer 接管后再次重启消费,就会造成 at most once 语义(消息会丢,但不重复)。
如果 Consumer 消费消息完成后, 再更新 Offset,如果这时 Consumer crash 掉,那么新的 Consumer 接管后重新用这个 Offset 拉取消息, 这时就会造成 at least once 语义(消息不丢,但被多次重复处理)。

默认 Kafka 提供「at least once」语义的消息传递,允许用户通过在处理消息之前保存 Offset的方式提供 「at most once」 语义。如果自己实现消费幂等,理想情况下这个系统的消息传递就是「exactly once」, 也就是保证不丢失、且只会被精确的处理一次,但是这样是很难做到的。

kafka如何保证消息不丢失?

生产阶段

Kafka生产者异步发送消息并返回一个Future代表发送结果

首先需要获取返回结果判断是否发送成功。
消息队列通过最常用的请求确认机制,来保证消息的可靠传递:当代码调用发消息方法时,消息队列的客户端会把消息发送到 Broker,Broker 收到消息后,会给客户端返回一个确认响应,表明消息已经收到了。客户端收到响应后,完成了一次正常消息的发送。

Producer(生产者)保证消息不丢失的方法:
1. 发送确认机制:
Producer可以使用Kafka的acks参数来配置发送确认机制。
通过设置合适的acks参数值,Producer可以在消息发送后等待Broker的确认。
确认机制提供了不同级别的可靠性保证,包括:
• acks=0:Producer在发送消息后不会等待Broker的确认,这可能导致消息丢失风险。
• acks=1:Producer在发送消息后等待Broker的确认,确保至少将消息写入到Leader副本中。
• acks=all或acks=-1:Producer在发送消息后等待Broker的确认,确保将消息写入到所有ISR(In-Sync Replicas)副本中。这提供了最高的可靠性保证。

2. 消息重试机制:
Producer可以实现消息的重试机制来应对发送失败或异常情况。
如果发送失败,Producer可以重新发送消息,直到成功或达到最大重试次数。
重试机制可以保证消息不会因为临时的网络问题或Broker故障而丢失。

Broker存储阶段

正常情况下,只要 Broker 在正常运行,就不会出现丢失消息的问题
但是如果 Broker 出现了故障,比如进程死掉了或者服务器宕机了,还是可能会丢失消息的。

在kafka高性能设计原理中了解到kafka为了提高性能用到了 Page Cache 技术
在读写磁盘日志文件时,其实操作的都是内存,然后由操作系统决定什么时候将 Page Cache 里的数据真正刷入磁盘
如果内存中数据还未刷入磁盘服务宕机了,这个时候还是会丢消息的。

为了最大程度地降低数据丢失的可能性,可以考虑以下方法:
持久化配置优化:可以通过调整 Kafka 的持久化配置参数来控制数据刷盘的频率,从而减少数据丢失的可能性。例如,可以降低 flush.messages 和 flush.ms 参数的值,以更频繁地刷写数据到磁盘。
副本因子增加:在 Kafka 中,可以为每个分区设置多个副本,以提高数据的可靠性。当某个 broker 发生故障时,其他副本仍然可用,可以避免数据丢失。
使用acks=all:在生产者配置中,设置 acks=all 可以确保消息在所有ISR(In-Sync Replicas)中都得到确认后才被视为发送成功。这样可以确保消息被复制到多个副本中,降低数据丢失的风险。
备份数据:定期备份 Kafka 的数据,以便在发生灾难性故障时可以进行数据恢复。

消费阶段

消费阶段采用和生产阶段类似的确认机制来保证消息的可靠传递,客户端从 Broker 拉取消息后,执行用户的消费业务逻辑,成功后,才会给 Broker 发送消费确认响应。如果 Broker 没有收到消费确认响应,下次拉消息的时候还会返回同一条消息,确保消息不会在网络传输过程中丢失,也不会因为客户端在执行消费逻辑中出错导致丢失。

自动提交位移:Consumer可以选择启用自动提交位移的功能。当Consumer成功处理一批消息后,它会自动提交当前位移,标记为已消费。这样即使Consumer发生故障,它可以使用已提交的位移来恢复并继续消费之前未处理的消息。
手动提交位移:Consumer还可以选择手动提交位移的方式。在消费一批消息后,Consumer可以显式地提交位移,以确保处理的消息被正确记录。这样可以避免重复消费和位移丢失的问题。

数据一致系统设计特点

保证数据一致性,需要通过成功后commit的操作,消费过程中记录消费标记。成功与失败的情况都打上标志
Kafka作为一个分布式发布-订阅消息系统,其数据一致性的系统设计特点主要包括以下几个方面:

分区与副本机制

Kafka将数据分成多个分区(Partition),每个分区在集群中有多个副本(Replica)。
这些副本分布在不同的Broker上,以实现数据的冗余备份和高可用性。
当某个Broker发生故障时,其他Broker上的副本可以接管服务,保证数据的持续可用。

ISR(In-Sync Replicas)机制:
ISR是Kafka中用于维护数据一致性的重要机制。它包含所有与Leader保持同步的副本。
当ISR中的副本数量不足时,Kafka会暂停写入操作,以防止数据不一致。
只有当ISR中的副本数量恢复到一定数量时,才会恢复写入操作。

消息提交确认

生产者发送消息到Kafka时,需要等待消息被写入ISR中的副本并得到确认,以确保消息被成功存储
消费者在处理消息时也需要定期提交偏移量(Offset),以便在发生故障时能够从正确的位置继续消费。

原子性操作

Kafka保证消息在分区内的顺序性和原子性。
在同一分区内的消息会按照发送的顺序被消费,且不会被其他消息插入打断。
这有助于保证数据的一致性和正确性。

容错处理

当Kafka集群中的节点发生故障时,Kafka会自动进行故障转移和恢复操作。
这包括从ISR中选择新的Leader、重新同步数据等,以确保数据的持续可用和一致性。

总结

Kafka通过分区与副本机制、ISR机制、消息提交确认、原子性操作和容错处理等手段,确保数据一致性。
这些设计使得Kafka能够在分布式环境中实现高吞吐量、持久化存储、可扩展性和高可靠性等特性
从而满足各种复杂场景下的数据一致性需求。文章来源地址https://www.toymoban.com/news/detail-826342.html

到了这里,关于通过kafka学习数据一致性的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 缓存面试解析:穿透、击穿、雪崩,一致性、分布式锁、Redis过期,海量数据查找

    在程序内部使用缓存,比如使用map等数据结构作为内部缓存,可以快速获取对象。通过将经常使用的数据存储在缓存中,可以减少对数据库的频繁访问,从而提高系统的响应速度和性能。缓存可以将数据保存在内存中,读取速度更快,能够大大缩短数据访问的时间,提升用户

    2024年02月14日
    浏览(54)
  • 分布式系统中数据库和缓存双写一致性的实现技术

    标题:分布式系统中数据库和缓存双写一致性的实现技术 在分布式系统中,为了确保数据库和缓存之间的数据一致性,双写一致性成为了一个关键的挑战。本文将深入探讨如何利用一些常见的技术手段来保证数据库和缓存的双写一致性,以及通过举例说明这些技术是如何在实

    2024年01月16日
    浏览(57)
  • 【103期】RabbitMQ 实现多系统间的分布式事务,保证数据一致性

    org.springframework.boot spring-boot-starter-amqp mysql mysql-connector-java runtime org.projectlombok lombok true org.springframework.boot spring-boot-starter-jdbc com.alibaba fastjson 1.2.17 3.2.1.2配置文件内容: server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/test?useUnicode=tru

    2024年04月14日
    浏览(65)
  • 分布式系统架构设计之分布式数据存储的扩展方式、主从复制以及分布式一致性

    在分布式系统中,数据存储的扩展是为了适应业务的增长和提高系统的性能。分为水平扩展和垂直扩展两种方式,这两种方式在架构设计和应用场景上有着不同的优势和局限性。 水平扩展是通过增加节点或服务器的数量来扩大整个系统的容量和性能。在数据存储领域,水平扩

    2024年02月03日
    浏览(76)
  • [Etcd]分布式系统中如何使用乐观锁保证Mysql和Etcd数据最终一致性

    在写业务代码时,很多时候需要保证数据存储在不同中间件中的一致性。以笔者为例,就遇到了需要将mysql中已存储的数据转存到etcd中,同时还要考虑到并发场景下如何保证数据最终一致性的问题。 该问题形象地表示的话,可以将时间线展开如下 服务A1更新db数据为 {\\\"key1\\\":

    2024年02月02日
    浏览(52)
  • 分布式系统的一致性级别划分及Zookeeper一致性级别分析

    在谈到Zookeeper的一致性是哪种级别的一致性问题,以及CAP原则中的C是哪一种一致性级别时有些疑惑。 下面是大多数文章中提到的一致性级别 一致性(Consistency)是指多副本(Replications)问题中的数据一致性。可以分为强一致性、顺序一致性与弱一致性。 1.1 强一致性(Stric

    2024年04月12日
    浏览(60)
  • MySQL 和 Redis 如何保证数据一致性,通过MySQL的binlog实现

    1、简介         MySQL 和 Redis 如何保证数据一致性,目前大多讨论的是先更新Redis后更新MySQL,还是先更新MySQL 后更新Redis,这两种方式在实际的应用场景中都不能确保数据的完全一致性,在某些情况下会出现问题,本文介绍使用 Canal 工具,通过将自己伪装成MySQL的从节点,读

    2024年02月02日
    浏览(59)
  • 分布式一致性算法Paxos

            Paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法,是目前公认的解决分布式一致性问题最有效的算法之一。Google Chubby的作者Mike Burrows曾经狂妄的说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品。         Paxos算法是

    2023年04月16日
    浏览(61)
  • 【分布式】一致性哈希和哈希槽

    当我们拥有了多台存储服务器之后,现在有多个key,希望可以将这些个key均匀的缓存到这些服务器上,可以使用哪些方案呢? 1.1 直接哈希取模 这是一种最容易想到的方法,使用取模算法hash(key)% N,对key进行hash运算后取模,N是机器的数量。key进行hash后的结果对3取模,得

    2024年02月03日
    浏览(49)
  • RocketMQ分布式事务 -> 最终一致性实现

    · 分布式事务的问题常在业务与面试中被提及, 近日摸鱼看到这篇文章, 阐述的非常通俗易懂, 固持久化下来我博客中, 也以便于我二刷 转载源 : 基于RocketMQ分布式事务 - 完整示例 本文代码不只是简单的demo,考虑到一些异常情况、幂等性消费和死信队列等情况,尽量向可靠业务

    2024年02月15日
    浏览(56)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包