kafka一致性保证

最新推荐文章于 2024-06-06 10:59:49 发布
最新推荐文章于 2024-06-06 10:59:49 发布
阅读量2.7k 收藏 12
点赞数 3
分类专栏： 消息队列 文章标签： kafka java 大数据
版权声明：本文为博主原创文章，遵循 CC 4.0 BY 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_52851967/article/details/128260238
版权

1、概念

水位标记：

        水位或水印（watermark）一词，表示位置信息，即位移（offset）。Kafka源码中使用的名字是高水位，HW（high watermark）。

副本角色：

        Kafka分区使用多个副本(replica)提供高可用。

LEO和HW：

  每个分区副本对象都有两个重要的属性：LEO和HW。

  • LEO：即日志末端位移(log end offset)，记录了该副本日志中下一条消息的位移值。如果LEO=10，那么表示该副本保存了10条消息，位移值范围是[0, 9]。另外，Leader LEO和Follower LEO的更新是有区别的。
  • HW：即上面提到的水位值。对于同一个副本对象而言，其HW值不会大于LEO值。小于等于HW值的所有消息都被认为是“已备份”的（replicated）。Leader副本和Follower副本的HW更新不同。

        上图中，HW值是7，表示位移是0~7 的所有消息都已经处于“已提交状态”（committed），而LEO值是14，8~13的消息就是未完全备份（fully replicated）——为什么没有14？LEO指向的是下一条消息到来时的位移。 

消费者无法消费分区下Leader副本中位移大于分区HW的消息。

2、Follower副本何时更新LEO

        Follower副本不停地向Leader副本所在的broker发送FETCH请求，一旦获取消息后写入自己的日志中进行备份。那么Follower副本的LEO是何时更新的呢？首先我必须言明，Kafka有两套Follower副本LEO：

  1. 一套LEO保存在Follower副本所在Broker的副本管理机中；
  2. 另一套LEO保存在Leader副本所在Broker的副本管理机中。Leader副本机器上保存了所有的follower副本的LEO。

Kafka使用前者帮助Follower副本更新其HW值；利用后者帮助Leader副本更新其HW。

（1）Follower副本的本地LEO何时更新？

        Follower副本的LEO值就是日志的LEO值，每当新写入一条消息，LEO值就会被更新。当Follower发送FETCH请求后，Leader将数据返回给Follower，此时Follower开始Log写数据，从而自动更新LEO值。

（2）Leader端Follower的LEO何时更新？

        Leader端的Follower的LEO更新发生在Leader在处理Follower FETCH请求时。一旦Leader接收到Follower发送的FETCH请求，它先从Log中读取相应的数据，给Follower返回数据前，先更新Follower的LEO。

3、Follower副本何时更新HW

  • Follower更新HW发生在其更新LEO之后，一旦Follower向Log写完数据，尝试更新自己的HW值。
  • 比较当前LEO值与FETCH响应中Leader的HW值，取两者的小者作为新的HW值。
  • 即：如果Follower的LEO大于Leader的HW，Follower HW值不会大于Leader的HW值。

 Leader副本何时更新LEO？

        和Follower更新LEO相同，Leader写Log时自动更新自己的LEO值。

4、Leader副本何时更新HW值

Leader的HW值就是分区HW值，直接影响分区数据对消费者的可见性 。

Leader会尝试去更新分区HW的四种情况：

  • Follower副本成为Leader副本时：Kafka会尝试去更新分区HW。
  • Broker崩溃导致副本被踢出ISR时：检查下分区HW值是否需要更新是有必要的。
  • 生产者向Leader副本写消息时：因为写入消息会更新Leader的LEO，有必要检查HW值是否需要更新
  • Leader处理Follower FETCH请求时：首先从Log读取数据，之后尝试更新分区HW值

结论：

当Kafka broker都正常工作时，分区HW值的更新时机有两个：

  • Leader处理PRODUCE请求时
  • Leader处理FETCH请求时。

        Leader如何更新自己的HW值？Leader broker上保存了一套Follower副本的LEO以及自己的LEO。当尝试确定分区HW时，它会选出所有满足条件的副本，比较它们的LEO(包括Leader的LEO)，并选择最小的LEO值作为HW值。

需要满足的条件，（二选一）：

  1. 处于ISR中
  2. 副本LEO落后于Leader LEO的时长不大于replica.lag.time.max.ms 参数值(默认是10s)

        如果Kafka只判断第一个条件的话，确定分区HW值时就不会考虑这些未在ISR中的副本，但这些副本已经具备了“立刻进入ISR”的资格，因此就可能出现分区HW值越过ISR中副本LEO的情况——不允许。因为分区HW定义就是ISR中所有副本LEO的最小值。

5、HW和LEO正常更新案例

        我们假设有一个topic，单分区，副本因子是2，即一个Leader副本和一个Follower副本。我们看下当producer发送一条消息时，broker端的副本到底会发生什么事情以及分区HW是如何被更新的。

（1）初始状态

        初始时Leader和Follower的HW和LEO都是0(严格来说源代码会初始化LEO为-1，不过这不影响之后的讨论)。Leader中的Remote LEO指的就是Leader端保存的Follower LEO，也被初始化成0。此时，生产者没有发送任何消息给Leader，而Follower已经开始不断地给Leader发送FETCH请求了，但因为没有数据因此什么都不会发生。值得一提的是，Follower发送过来的FETCH请求因为无数据而暂时会被寄存到Leader端的purgatory中，待500ms ( replica.fetch.wait.max.ms 参数)超时后会强制完成。倘若在寄存期间生产者发来数据，则Kafka会自动唤醒该FETCH请求，让Leader继续处理。

（2） Follower发送FETCH请求在Leader处理完PRODUCE请求之后

  • producer给该topic分区发送了一条消息
  • 此时的状态如下图所示：

如上图所示，Leader接收到PRODUCE请求主要做两件事情： 

  • 把消息写入Log，同时自动更新Leader自己的LEO
  • 尝试更新Leader HW值。假设此时Follower尚未发送FETCH请求，Leader端保存的Remote LEO依然是0，因此Leader会比较它自己的LEO值和Remote LEO值，发现最小值是0，与当前HW值相同，故不会更新分区HW值（仍为0）

        PRODUCE请求处理完成后各值如下，Leader端的HW值依然是0，而LEO是1，Remote LEO也是0。

属性阶段旧值新值备注
Leader LEOPRODUCE处理完成01写入了一条数据
Remote LEOPRODUCE处理完成00还未Fetch
Leader HWPRODUCE处理完成00min(LeaderLEO=1, RemoteLEO=0)=0
Follower LEOPRODUCE处理完成00还未Fetch
Follower HWPRODUCE处理完成00min(LeaderHW=0, FollowerLEO=0)=0

假设此时follower发送了FETCH请求，则状态变更如下：

本例中当follower发送FETCH请求时，Leader端的处理依次是： 

  • 读取Log数据
  • 更新remote LEO = 0（为什么是0？ 因为此时Follower还没有写入这条消息。Leader如何确认Follower还未写入呢？这是通过Follower发来的FETCH请求中的Fetch offset来确定的）
  • 尝试更新分区HW：此时Leader LEO = 1，Remote LEO = 0，故分区HW值= min(Leader LEO,Follower Remote LEO) = 0
  • 把数据和当前分区HW值（依然是0）发送给Follower副本

而Follower副本接收到FETCH Response后依次执行下列操作：

  1. 写入本地Log，同时更新Follower自己管理的 LEO为1
  2. 更新Follower HW：比较本地LEO和 FETCH Response 中的当前Leader HW值，取较小者，Follower HW = 0

        此时，第一轮FETCH RPC结束，我们会发现虽然Leader和Follower都已经在Log中保存了这条消息，但分区HW值尚未被更新，仍为0。

属性阶段旧值新值备注
Leader LEOPRODUCE和Follower FETCH处理完成01写入了一条数据
Remote LEOPRODUCE和Follower FETCH处理完成00第一次fetch中offset为0
Leader HWPRODUCE和Follower FETCH处理完成00min(LeaderLEO=1, RemoteLEO=0)=0
Follower LEOPRODUCE和Follower FETCH处理完成01同步了一条数据
Follower HWPRODUCE和Follower FETCH处理完成00min(LeaderHW=0, FollowerLEO=1)=0

Follower第二轮FETCH

        分区HW是在第二轮FETCH RPC中被更新的，如下图所示：

Follower发来了第二轮FETCH请求，Leader端接收到后仍然会依次执行下列操作： 

  1. 读取Log数据
  2. 更新Remote LEO = 1（这次为什么是1了？ 因为这轮FETCH RPC携带的fetch offset是1，那么为什么这轮携带的就是1了呢，因为上一轮结束后Follower LEO被更新为1了）
  3. 尝试更新分区HW：此时leader LEO = 1，Remote LEO = 1，故分区HW值= min(Leader LEO,Follower Remote LEO) = 1。
  4. 把数据（实际上没有数据）和当前分区HW值（已更新为1）发送给Follower副本作为Response

同样地，Follower副本接收到FETCH response后依次执行下列操作：

  • 写入本地Log，当然没东西可写，Follower LEO也不会变化，依然是1。
  • 更新Follower HW：比较本地LEO和当前Leader LEO取小者。由于都是1，故更新follower HW = 1 。
属性阶段旧值新值备注
Leader LEO第二次Follower FETCH处理完成11未写入新数据
Remote LEO第二次Follower FETCH处理完成01第2次fetch中offset为1
Leader HW第二次Follower FETCH处理完成01min(RemoteLEO,LeaderLEO)=1
Follower LEO第二次Follower FETCH处理完成11未写入新数据
Follower HW第二次Follower FETCH处理完成01第2次fetch resp中的LeaderHW和本地Follower LEO都是1

        此时消息已经成功地被复制到Leader和Follower的Log中且分区HW是1，表明消费者能够消费offset = 0的消息。

（3）FETCH请求保存在purgatory中，PRODUCE请求到来。

        当Leader无法立即满足FECTH返回要求的时候(比如没有数据)，那么该FETCH请求被暂存到Leader端的purgatory中（炼狱），待时机成熟尝试再次处理。Kafka不会无限期缓存，默认有个超时时间（500ms），一旦超时时间已过，则这个请求会被强制完成。当寄存期间还没超时，生产者发送PRODUCE请求从而使之满足了条件以致被唤醒。此时，Leader端处理流程如下：

  1. Leader写Log（自动更新Leader LEO）
  2. 尝试唤醒在purgatory中寄存的FETCH请求
  3. 尝试更新分区HW

6、HW和LEO异常案例

        Kafka使用HW值来决定副本备份的进度，而HW值的更新通常需要额外一轮FETCH RPC才能完成。但这种设计是有问题的，可能引起的问题包括：

  • 备份数据丢失
  • 备份数据不一致

（1）数据丢失

        使用HW值来确定备份进度时其值的更新是在下一轮RPC中完成的。如果Follower副本在标记上方的的第一步与第二步之间发生崩溃，那么就有可能造成数据的丢失。

  • 上图中有两个副本：A和B。开始状态是A是Leader。
  • 假设生产者min.insync.replicas 为1，那么当生产者发送两条消息给A后，A写入Log，此时Kafka会通知生产者这两条消息写入成功。 
代属性阶段旧值新值备注
1Leader LEOPRODUCE和Follower FETCH处理完成01写入了一条数据
1Remote LEOPRODUCE和Follower FETCH处理完成00第一次fetch中offset为0
1Leader HWPRODUCE和Follower FETCH处理完成00min(LeaderLEO=1,FollowerLEO=0)=0
1Follower LEOPRODUCE和Follower FETCH处理完成01同步了一条数据
1Follower HWPRODUCE和Follower FETCH处理完成00min(LeaderHW=0, FollowerLEO=1)=0
2Leader LEO第二次Follower FETCH处理完成12写入了第二条数据
2Remote LEO第二次Follower FETCH处理完成01第2次fetch中offset为1
2Leader HW第二次Follower FETCH处理完成01min(RemoteLEO=1,LeaderLEO=2)=1
2Follower LEO第二次Follower FETCH处理完成12写入了第二条数据
2Follower HW第二次Follower FETCH处理完成01min(LeaderHW=1,FollowerLEO=2)=1
3Leader LEO第三次Follower FETCH处理完成22未写入新数据
3Remote LEO第三次Follower FETCH处理完成12第3次fetch中offset为2
3Leader HW第三次Follower FETCH处理完成12min(RemoteLEO=2,LeaderLEO)=2
3Follower LEO第三次Follower FETCH处理完成22未写入新数据
3Follower HW第三次Follower FETCH处理完成12第3次fetch resp中的LeaderHW和本地FollowerLEO都是2

        但是在broker端，Leader和Follower的Log虽都写入了2条消息且分区HW已经被更新到2，但Follower HW尚未被更新还是1，也就是上面标记的第二步尚未执行，表中最后一条未执行。

        倘若此时副本B所在的broker宕机，那么重启后B会自动把LEO调整到之前的HW值1，故副本B会做日志截断(log truncation)，将offset = 1的那条消息从log中删除，并调整LEO = 1。此时follower副本底层log中就只有一条消息，即offset = 0的消息！

        B重启之后需要给A发FETCH请求，但若A所在broker机器在此时宕机，那么Kafka会令B成为新的Leader，而当A重启回来后也会执行日志截断，将HW调整回1。这样，offset=1的消息就从两个副本的log中被删除，也就是说这条已经被生产者认为发送成功的数据丢失。

        丢失数据的前提是min.insync.replicas=1 时，一旦消息被写入Leader端Log即被认为是committed 。延迟一轮FETCH RPC 更新HW值的设计使follower HW值是异步延迟更新，若在这个过程中Leader发生变更，那么成为新Leader的Follower的HW值就有可能是过期的，导致生产者本是成功提交的消息被删除。

（2）Leader和Follower数据离散

  • 除了可能造成的数据丢失以外，该设计还会造成Leader的Log和Follower的Log数据不一致。
  • 如Leader端记录序列：m1,m2,m3,m4,m5,…；Follower端序列可能是m1,m3,m4,m5,…。

看图：

        假设：A是Leader，A的Log写入了2条消息，但B的Log只写了1条消息。分区HW更新到2，但B的HW还是1，同时生产者min.insync.replicas 仍然为1。

        假设A和B所在Broker同时宕机，B先重启回来，因此B成为Leader，分区HW = 1。假设此时生产者发送了第3条消息(红色表示)给B，于是B的log中offset = 1的消息变成了红框表示的消息，同时分区HW更新到2（A还没有回来，就B一个副本，故可以直接更新HW而不用理会A）之后A重启回来，需要执行日志截断，但发现此时分区HW=2而A之前的HW值也是2，故不做任何调整。此后A和B将以这种状态继续正常工作。

        显然，这种场景下，A和B的Log中保存在offset = 1的消息是不同的记录，从而引发不一致的情形出现。

7、Leader Epoch使用

Kafka解决方案

造成上述两个问题的根本原因在于

  • HW值被用于衡量副本备份的成功与否。
  • 在出现失败重启时作为日志截断的依据。

        但HW值的更新是异步延迟的，特别是需要额外的FETCH请求处理流程才能更新，故这中间发生的任何崩溃都可能导致HW值的过期。

        Kafka从0.11引入了leader epoch 来取代HW值。Leader端使用内存保存Leader的epoch信息，即使出现上面的两个场景也能规避这些问题。

所谓Leader epoch实际上是一对值：<epoch, offset>：

  • epoch表示Leader的版本号，从0开始，Leader变更过1次，epoch+1
  • offset对应于该epoch版本的Leader写入第一条消息的offset。因此假设有两对值：

<0, 0>
<1, 120>

        则表示第一个Leader从位移0开始写入消息；共写了120条[0, 119]；而第二个Leader版本号是1，从位移120处开始写入消息。

  • Leader broker中会保存这样的一个缓存，并定期地写入到一个checkpoint 文件中。
  • 当Leader写Log时它会尝试更新整个缓存：如果这个Leader首次写消息，则会在缓存中增加一个条目；否则就不做更新。
  • 每次副本变为Leader时会查询这部分缓存，获取出对应Leader版本的位移，则不会发生数据不一致和丢失的情况。

（1）规避数据丢失

        只需要知道每个副本都引入了新的状态来保存自己当leader时开始写入的第一条消息的offset以及leader版本。这样在恢复的时候完全使用这些信息而非HW来判断是否需要截断日志。 

（2）规避数据不一致

依靠Leader epoch的信息可以有效地规避数据不一致的问题。 

8、消息重复的场景及解决方案

消息重复和丢失是kafka中很常见的问题，主要发生在以下三个阶段：

  • 生产者阶段
  • broke阶段
  • 消费者阶段

8.1、生产者阶段重复场景

（1）根本原因

  • 生产发送的消息没有收到正确的broke响应，导致生产者重试。
  • 生产者发出一条消息，broke落盘以后因为网络等种种原因发送端得到一个发送失败的响应或者网络中断，然后生产者收到一个可恢复的Exception重试消息导致消息重复。

（2）重试过程

说明： 

  • new KafkaProducer()后创建一个后台线程KafkaThread扫描RecordAccumulator中是否有消息；
  • 调用KafkaProducer.send()发送消息，实际上只是把消息保存到RecordAccumulator中；
  • 后台线程KafkaThread扫描到RecordAccumulator中有消息后，将消息发送到kafka集群；
  • 如果发送成功，那么返回成功；
  • 如果发送失败，那么判断是否允许重试。如果不允许重试，那么返回失败的结果；如果允许重试，把消息再保存到RecordAccumulator中，等待后台线程KafkaThread扫描再次发送；

（3）可恢复异常说明

        异常是RetriableException类型或者TransactionManager允许重试；RetriableException类继承关系如下：

（4） 记录顺序问题  

        如果设置max.in.flight.requests.per.connection 大于1（默认5，单个连接上发送的未确认请求的最大数量，表示上一个发出的请求没有确认下一个请求又发出了）。大于1可能会改变记录的顺序，因为如果将两个batch发送到单个分区，第一个batch处理失败并重试，但是第二个batch处理成功，那么第二个batch处理中的记录可能先出现被消费。

        设置max.in.flight.requests.per.connection 为1，可能会影响吞吐量，可以解决单个生产者发送顺序问题。如果多个生产者，生产者1先发送一个请求，生产者2后发送请求，此时生产者1返回可恢复异常，重试一定次数成功了。虽然生产者1先发送消息，但生产者2发送的消息会被先消费。

8.2、生产者发送重复解决方案

（1）启动kafka的幂等性

        要启动kafka的幂等性，设置： enable.idempotence=true ，以及ack=all 以及retries > 1 。

（2）ack=0，不重试

        可能会丢消息，适用于吞吐量指标重要性高于数据丢失，例如：日志收集。

（3）生产者和broker阶段消息丢失场景

  • ack=0，不重试：生产者发送消息完，不管结果了，如果发送失败也就丢失了。
  • ack=1，leader crash：生产者发送消息完，只等待Leader写入成功就返回了，Leader分区丢失了，此时Follower没来及同步，消息丢失。
  • unclean.leader.election.enable 配置true：允许选举ISR以外的副本作为leader,会导致数据丢失，默认为false。生产者发送异步消息，只等待Lead写入成功就返回，Leader分区丢失，此时ISR中没有Follower，Leader从OSR中选举，因为OSR中本来落后于Leader造成消息丢失。

（4）解决生产者和broker阶段消息丢失

禁用unclean选举，ack=all

  • ack=all / -1,tries > 1,unclean.leader.election.enable : false
  • 生产者发完消息，等待Follower同步完再返回，如果异常则重试。副本的数量可能影响吞吐量，不超过5个，一般三个。
  • 不允许unclean Leader选举。

配置：min.insync.replicas > 1

        当生产者将acks 设置为all (或-1 )时， min.insync.replicas>1 。指定确认消息写成功需要的最小副本数量。达不到这个最小值，生产者将引发一个异常(要么是NotEnoughReplicas，要么是NotEnoughReplicasAfterAppend)。

        当一起使用时， min.insync.replicas 和ack 允许执行更大的持久性保证。一个典型的场景是创建一个复制因子为3的主题，设置min.insync复制到2个，用all 配置发送。将确保如果大多数副本没有收到写操作，则生产者将引发异常。

失败的offset单独记录

        生产者发送消息，会自动重试，遇到不可恢复异常会抛出，这时可以捕获异常记录到数据库或缓存，进行单独处理。

（5）消费者数据重复场景及解决方案

  • 根本原因：数据消费完没有及时提交offset到broker。
  • 场景：消息消费端在消费过程中挂掉没有及时提交offset到broke，另一个消费端启动拿之前记录的offset开始消费，由于offset的滞后性可能会导致新启动的客户端有少量重复消费。

（6）解决方案

  • 取消自动提交：每次消费完或者程序退出时手动提交。这可能也没法保证一条重复。
  • 下游做幂等：一般是让下游做幂等或者尽量每消费一条消息都记录offset，对于少数严格的场景可能需要把offset或唯一ID（例如订单ID）和下游状态更新放在同一个数据库里面做事务来保证精确的一次更新或者在下游数据表里面同时记录消费offset，然后更新下游数据的时候用消费位移做乐观锁拒绝旧位移的数据更新。
悠然予夏
关注
  • 3
    点赞
  • 踩
  • 12
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
聊聊 Kafka：Kafka 如何保证一致性
riemann_的博客
06-06 5585
本文从高水位更新机制、副本同步机制以及 Leader Epoch 几个方面去剖析Kafka 是如何保证一致性的~
kafka如何保证数据的一致性
weixin_35752645的博客
02-07 1017
Kafka保证数据一致性的方式有很多，其中一个是通过使用分布式副本集。分布式副本集是一组Kafka服务器，它们在同一个集群中，共同维护一个副本。当消息被写入Kafka时，它会被复制到多个副本中，从而保证数据的完整性。如果其中一个副本失效，另一个副本可以接管它的工作。这样，Kafka就可以保证数据的一致性。 ...
Kafka 如何基于 KRaft 实现集群最终一致性协调
最新发布
AutoMQ的博客
06-06 637
Controller 的内存状态都通过 Timeline 数据结构来维护，当出现 Leader 切换时，旧的 Leader 会将 Timeline 数据结构的数据回滚到上一个已经被 KRaft 多数派确认的状态，来保证旧 Leader 内存中不会有脏数据。整个集群的状态维护和一致性协调都是基于 KRaft 中的事件。多节点之间的内存状态：KRaft 底层保证了多节点的 KRaft Log 是一致的，然后基于 “内存状态与 KRaft” 的一致性，通过传递性原则，因此多节点之间的内存状态也是一致的；
从kafka如何保证数据一致性看通常数据一致性设计
JAVA领域优质创作者，基于分片网络查询方法专利发明者。
02-18 3383
在数据库系统中有个概念叫事务，事务的作用是为了保证数据的一致性，意思是要么数据成功，要么数据失败，不存在数据操作了一半的情况，这就是数据的一致性。在很多系统或者组件中，很多场景都需要保证数据的一致性，有的是高度的一致性。特别是在交易系统等这样场景。有些组件的数据不一定需要高度保证数据的一致性，比如日志系统。本节从从kafka如何保证数据一致性看通常数据一致性设计。
通过kafka学习数据一致性
wangkai6666的博客
02-18 1340
Kafka通过分区与副本机制、ISR机制、消息提交确认、原子性操作和容错处理等手段，确保数据一致性。这些设计使得Kafka能够在分布式环境中实现高吞吐量、持久化存储、可扩展性和高可靠性等特性从而满足各种复杂场景下的数据一致性需求。
Kakfa怎么保证消息的一致性
m0_65277803的博客
09-07 2385
Kafka的也存在Leader和Follow节点，这样就会有一致性问题。
kafka保证数据可靠性的方式
01-20
而`ack=all`要求所有副本都确认，提供最强的一致性保证，但可能增加延迟。结合`min.insync.replicas`，生产者可以通过持续重试确保所有副本都成功接收消息。 消费者方面，Kafka支持自动或手动提交offset，以记录...
华为kafka.zip
11-20
而Zookeeper则是Apache的一个分布式协调服务，它为分布式应用提供了高可用、一致性以及命名服务等功能，是Kafka正常运行的重要依赖。 首先，我们来详细了解一下Kafka。Kafka是一种分布式流处理平台，由LinkedIn开发...
Kafka尚硅谷.rar
12-08
3. **容错性**：通过副本机制，Kafka能够自动处理节点故障，确保服务的连续性和数据的一致性。 4. **实时处理**：Kafka支持实时数据处理，消息一旦被发布就会立即可供消费，无需等待批处理。 5. **可伸缩性**：...
kafka-tool
03-22
3. **增强的AVRO支持**：集成Schema Registry，简化了AVRO数据的处理，保证了数据的一致性和兼容性。 4. **跨平台**：由于基于Java开发，Kafka Tool可在Windows、Linux和Mac等多平台上运行。 总结，Kafka Tool是...
kafka架构与原理 ，消息的可靠性与一致性幂等性，数据存储、zookeeper、使用场景
.
03-03 2911
Kafka常用命令之kafka-topics.shhttps://blog.csdn.net/qq_29116427/article/details/80202392 Kafka概述 Kafka作为一个商业级消息中间件 ，发布和订阅记录流，它类似于一个消息队列 先了解下Kafka的基本原理，然后通过对kakfa的存储机制、复制原理、同步原理、可靠性和持久性保证等等一步步对其可靠性进行分析...
Kafka面试小结六：kafka如果保证数据一致性？
之乎者也·的博客
10-31 342
leader 发生故障之后，会从 ISR 中选出一个新的 leader，之后，为保证多个副本之间的 数据一致性，其余的 follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 leader 同步数据。follower 发生故障后会被临时踢出 ISR，待该 follower 恢复后，follower 会读取本地磁盘 记录的上次的 HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 leader 进行同步。
Kafka如何保证高可用性，一致性，顺序性等
zhanghe_zht的博客
11-03 5372
1: Kafka如何保证高可用性： Kafka 基本的架构：由多个 broker 组成，每个 broker 是一个节点机器；你创建一个 topic，这个 topic可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个 partition就放一部分数据。每个 partition 的数据都会同步到其它机器上，形成自己的多个 replica 副本。这就是天然的分布式消息队列，就是说一个 topic 的数据，是分散放在多个机器上的，每个机器就放一部分数据。 所
kafka保证数据一致性机制
Piratesa的博客
10-30 1634
为保证 producer 发送的数据，能可靠的发送到指定的 topic，topic 的每个 partition 收到producer 发送的数据后，都需要向 producer 发送 ack（acknowledgement 确认收到），如果producer 收到 ack，就会进行下一轮的发送，否则重新发送数 ...
kafka如何保证数据可靠性和数据一致性
weixin_30325071的博客
09-06 465
数据可靠性 Kafka 作为一个商业级消息中间件，消息可靠性的重要性可想而知。本文从 Producter 往 Broker 发送消息、Topic 分区副本以及 Leader 选举几个角度介绍数据的可靠性。 Producer 往 Broker 发送消息 如果我们要往 Kafka 对应的主题发送消息，我们需要通过 Producer 完成。前面我们讲过 Kafka 主题对应了多个分区，每个分区...
Kafka消息一致性
xingchensuiyue的博客
12-24 2409
Kafka 是互联网行业内常用的一个消息中间，和RabbitMQ、RocketMQ的作用都是解耦生产端和消费端，缓存消息。 优点： 高吞吐，低延迟 可扩展性 持久性，可靠性 容错性 高并发 Kafka是怎么保证端到端之间的消息一致性的呢？ 每一个环节都会可能导致数据丢失或者重复。 1. 生产者 生产者的职责就是，确保生产的消息能到达Kafka，这里一般可以通过ack机制（kafka中的参数）来确定消息是否到达kafka中。 1.1 ack 该参数表示有多少个分区副本收到消息，才认为本次发送是成功的.
Kafka的事务处理和幂等性
互联网知识分享
08-15 449
在消息系统中，幂等性可以保证消息的处理结果与消息的重复处理无关，即使消息被重复消费，也不会对结果产生影响。幂等性消费者的主要思想是使用消息的唯一标识来判断消息是否已经被消费过，如果已经被消费过，则忽略该消息。）：事务是一个不可分割的操作单元，要么全部执行成功，要么全部回滚失败，不会出现部分执行的情况。消息队列事务：将多个消息队列的消息写入Kafka，并保证这些消息的原子性和一致性。）：一旦事务提交，其对数据库的修改应该是永久性的，即使系统发生故障也不会丢失。的事务处理机制，保证消息的原子性和一致性。
kafka数据一致性和防丢失策略
u014070481的博客
10-19 508
一、什么是kafka Apache kafka is a distributed streaming platform，即官方定义kafka 是一个分布式流式计算平台。而在大部分企业开发人员中，都是把 kafka 当成消息系统使用，即它是一个分布式消息队列，kafka的架构运行图如下： kafka的架构运行图 kafka关键的概念如下： Broker：一个服务器实例 Topic：一条消息流 Partition：分区，每个topic可以按特定分区逻辑分区，类似mysql的分表 P...
kafka如何保证数据一致性
06-06
Kafka通过副本机制来保证数据的一致性。具体来说，Kafka将每个分区的数据在多个副本之间进行复制，每个副本都可以独立地接收和处理消息。当消息被写入到主副本时，主副本会将消息复制到其他副本，待所有副本都确认已经收到消息后，主副本才会确认消息已经成功写入。这样就可以保证数据的一致性，即使某些副本失效，也可以通过其他副本来保证数据的可靠性。此外，Kafka还支持ISR（in-sync replicas）机制，即只有在同步副本集合中的副本确认收到消息时，才会认为消息已经写入成功，这也进一步提高了数据的一致性和可靠性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

悠然予夏

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值