kafka消息的可靠性

本文来自网易云社区

作者:田宏增

Kafka的高可靠性的保障来源于其健壮的副本(replication)策略。通过调节其副本相关参数,可以使得Kafka在性能和可靠性之间运转的游刃有余。Kafka从0.8.x版本开始提供partition级别的复制,replication的数量可以在$KAFKA_HOME/config/server.properties中配置。

Kafka中消息是以topic进行分类的,生产者通过topic向Kafka broker发送消息,消费者通过topic读取数据。然而topic在物理层面又能以partition为分组,一个topic可以分成若干个partition。Kafka中的消息以顺序的方式存储在文件中。

Kafka中的topic的partition有N个副本(replicas)。N个replicas中,其中一个replica为leader,其他都为follower, leader处理partition的所有读写请求,follower定期地去复制leader上的数据。

如果leader发生故障或挂掉,一个新leader被选举并被接受客户端的消息成功写入。Kafka确保从同步副本列表中选举一个副本为leader,或者说follower追赶leader数据。

Kafka的ack机制。

当producer向leader发送数据时,可以通过request.required.acks参数来设置数据可靠性的级别:

1(默认):这意味着producer在ISR中的leader已成功收到的数据并得到确认后发送下一条message。如果leader宕机了,则会丢失数据。

0:这意味着producer无需等待来自broker的确认而继续发送下一批消息。这种情况下数据传输效率最高,但是数据可靠性确是最低的。

-1:producer需要等待ISR中的所有follower都确认接收到数据后才算一次发送完成,可靠性最高。但是这样也不能保证数据不丢失,比如当ISR中只有leader时,这样就变成了acks=1的情况。

Kafka中的消息以一下方式存储到文件中。

HW是HighWatermark的缩写,俗称高水位,取一个partition对应的ISR中最小的LEO作为HW,consumer最多只能消费到HW所在的位置。另外每个replica都有HW,leader和follower各自负责更新自己的HW的状态。对于leader新写入的消息,consumer不能立刻消费,leader会等待该消息被所有ISR中的replicas同步后更新HW,此时消息才能被consumer消费。这样就保证了如果leader所在的broker失效,该消息仍然可以从新选举的leader中获取。对于来自内部broKer的读取请求,没有HW的限制。

LEO:LogEndOffset的缩写,表示每个partition的log最后一条Message的位置。

当leader挂了之后,现在B成为了leader,A重新恢复之后需要进行消息的同步,如果使用追加的方式那么就会有冗余消息,所以A将自己的消息截取到HW的位置在进行同步。

网易云免费体验馆,0成本体验20+款云产品!

更多网易研发、产品、运营经验分享请访问网易云社区

相关文章:
【推荐】 Apache流框架Flink,SparkStreaming,Storm对比分析(一)
【推荐】 一行代码搞定Dubbo接口调用

原文地址:https://www.cnblogs.com/163yun/p/9717300.html

时间: 2024-10-10 11:21:02

kafka消息的可靠性的相关文章

Kafka消息的可靠性测试--针对直播业务的方案选择

转自:http://blog.csdn.net/bailove/article/details/44240303 业务场景 来疯直播互动平台,每天有数百万人上下线,有数十万人同时参与互动直播聊天.用户的登陆.退出及用户间的各种交互行为如聊天.送礼.关注.投票.抢沙发等等事件都会产生大量的消息.这些消息具有瞬间爆发性,比如热门直播间刚开播,直播表演的高潮等等.而用户的礼物.星星.喇叭.沙发等这类消息是不允许丢失,必须100%送达.这就需要有一个高性能,高可靠,稳定可拓展的消息服务平台的支撑.它要求

Kafka消息模型

一.消息传递模型 传统的消息队列最少提供两种消息模型,一种P2P,一种PUB/SUB,而Kafka并没有这么做,巧妙的,它提供了一个消费者组的概念,一个消息可以被多个消费者组消费,但是只能被一个消费者组里的一个消费者消费,这样当只有一个消费者组时就等同与P2P模型,当存在多个消费者组时就是PUB/SUB模型. Kafka 的 consumer 是以pull的形式获取消息数据的. pruducer push消息到kafka cluster ,consumer从集群中pull消息,如下图.该博客主要

apache kafka消息服务

apache kafka中国社区QQ群:162272557 apache kafka参考 http://kafka.apache.org/documentation.html 消息队列分类: 点对点: 消息生产者生产消息发送到queue中,然后消息消费者从queue中取出并且消费消息.这里要注意: 消息被消费以后,queue中不再有存储,所以消息消费者不可能消费到已经被消费的消息. Queue支持存在多个消费者,但是对一个消息而言,只会有一个消费者可以消费. 发布/订阅 消息生产者(发布)将消息

一文看懂Kafka消息格式的演变

摘要 对于一个成熟的消息中间件而言,消息格式不仅关系到功能维度的扩展,还牵涉到性能维度的优化.随着Kafka的迅猛发展,其消息格式也在不断的升级改进,从0.8.x版本开始到现在的1.1.x版本,Kafka的消息格式也经历了3个版本.本文这里主要来讲述Kafka的三个版本的消息格式的演变,文章偏长,建议先关注后鉴定. Kafka根据topic(主题)对消息进行分类,发布到Kafka集群的每条消息都需要指定一个topic,每个topic将被分为多个partition(分区).每个partition在

消息中间件-消息的可靠性传递

前言 消息中间件的可靠性消息传递,是消息中间件领域非常重要的方案落实问题(在这之前的MQ理论,MQ选型是抽象层次更高的问题,这里不谈). 并且这个问题与日常开发是存在较大的关联的.可以这么说,凡是使用了MQ的,机会都要考虑这个问题.当然也有一些原始数据采集,日志数据收集等应用场景对此没有过高要求.但是大多数的业务场景,对此还是有着较高要求的.比如订单系统,支付系统,消息系统等,你弄丢一条消息,嘿嘿. 网上对于这方面的博客,大多从单一MQ,或者干脆就是在论述MQ.我不喜欢这样的论述,这样的论述太过

Kafka消息系统监控

1.监控目标 当系统可能或处于亚健康状态时及时提醒,预防故障发生 报警提示 2.监控内容 2.1 机器监控 Kafka服务器指标 CPU Load Disk IO Memory 2.2 JVM监控 主要监控JAVA的 GC time(垃圾回收时间),JAVA的垃圾回收机制对性能的影响比较明显 2.3 Kafka系统监控 1.Kafka总体监控 zookeeper上/kafka08/broker/ids目录下节点数量 leader 选举频率 2.Kafka Broker监控 Broker是否存活

Storm 官方文档翻译 --- 消息的可靠性保障

消息的可靠性保障 Storm 能够保证每一个由 Spout 发送的消息都能够得到完整地处理.本文详细解释了 Storm 如何实现这种保障机制,以及作为用户如何使用好 Storm 的可靠性机制. 消息的“完整性处理”是什么意思 一个从 spout 中发送出的 tuple 会产生上千个基于它创建的 tuples.例如,有这样一个 word-count 拓扑: TopologyBuilder builder = new TopologyBuilder(); builder.setSpout("sent

Kafka 消息监控 - Kafka Eagle

1.概述 在开发工作当中,消费 Kafka 集群中的消息时,数据的变动是我们所关心的,当业务并不复杂的前提下,我们可以使用 Kafka 提供的命令工具,配合 Zookeeper 客户端工具,可以很方便的完成我们的工作.随着业务的复杂化,Group 和 Topic 的增加,此时我们使用 Kafka 提供的命令工具,已预感到力不从心,这时候 Kafka 的监控系统此刻便尤为显得重要,我们需要观察消费应用的详情. 监控系统业界有很多杰出的开源监控系统.我们在早期,有使用 KafkaMonitor 和

Kafka消息重新发送

Kafka消息重新发送   1.  使用kafka消息队列做消息的发布.订阅,如果consumer端消费出问题,导致数据并没有消费,此时不需要担心,数据并不会立刻丢失,kafka会把数据在服务器的磁盘上默认存储7天,或者自己指定有两种方式:1)指定时间,log.retention.hours=168:2)指定大小,log.segment.bytes=1073741824.此时就可以通过重置某个topic的offset来是消息重新发送,进行消费   2.        查看topic的offset