原来代码如下 KafkaSpoutConfig<String, String> kafkaSpoutConfig = KafkaSpoutConfig.builder(kafka_server, "monmetric") // .setProp(ConsumerConfig.GROUP_ID_CONFIG, "kafkaSpoutTestGroup") .setProp(ConsumerConfig.MAX_PARTITION_FETCH_BYTES_C…

Kafka简介及使用PHP处理Kafka消息 Kafka 是一种高吞吐的分布式消息系统,能够替代传统的消息队列用于解耦合数据处理,缓存未处理消息等,同时具有更高的吞吐率,支持分区.多副本.冗余,因此被广泛用于大规模消息数据处理应用. Kafka的特点: 以时间复杂度为O(1)的方式提供消息持久化能力,即使对TB级以上数据也能保证常数时间复杂度的访问性能. 高吞吐率.即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输.[据了解,Kafka每秒可以生产约25万消息(50 MB),…

背景现象 1.20晚上8点业务线开始切换LBS相关流量,在之后的1个小时时间内,积压量呈上升趋势,一路到达50W左右,第二天的图没贴出具体是50W数字,以下是第一天晚上的贴图部分. 现象一: 现象二: 当时现场图后来就找不回来了,凭印象说明了一下数字. 简要说明一下上述两个图 图一:其实很明显,明显看出,消费者消费速度明显跟不上生产者的发送速度,导致出现积压情况. 图二:图二就有点意思了,因为上游通过Kafka消息队列发送消息给我,分区数是20个.由于消费组内消费者实例是17个,所以从宏观上分析…

关于 Topic 和 Partition: Topic: 在 kafka 中,topic 是一个存储消息的逻辑概念,可以认为是一个消息集合.每条消息发送到 kafka 集群的消息都有一个类别.物理上来说,不同的 topic 的消息是分开存储的,每个 topic 可以有多个生产者向它发送消息,也可以有多个消费者去消费其中的消息. Partition: 每个 topic 可以划分多个分区(每个 Topic 至少有一个分区),同一 topic 下的不同分区包含的消息是不同的.每个消息在被添加到分区时,…

1. 消费者位置(consumer position) 因为kafka服务端不保存消息的状态,所以消费端需要自己去做很多事情.我们每次调用poll()方法他总是返回已经保存在生产者队列中还未被消费者消费的消息.消息在每一个分区中都是顺序的,那么必然可以通过一个偏移量去确定每一条消息的位置. 偏移量在消费消息的过程中处于重要的作用.如果是自动提交消息,那么poll()方法会去在每次获取消息的时候自动提交获取最后一条消息的偏移量,告诉服务器我们已经消费到这个位置,下次从下一个位置开始消费. 我们把更…

事故背景: 我们公司与合作方公司有个消息同步的需求,合作方是消息生产者,我们是消息消费者,他们通过kafka给我们推送消息,我们实时接收,然后进行后续业务处理.昨天上午,发现他们推送过来的广场门店信息我们都没有消费,导致我们系统和他们系统数据不一致,从而导致无法提单,无法出报表(报表有误)等各种问题 排查过程: (1)因为coco身体不适,上午请假去医院了,所以这个问题就转给我们team的专门运维的同事了,电话大概给他说明了代码路径,可惜,半天下来仍然无果,看着微信群里他发的消息,我有点抓狂,根…

1. 保证消息被消费 即使消息发送到了消息队列,消息也不会万无一失,还是会面临丢失的风险. 我们以 Kafka 为例,消息在Kafka 中是存储在本地磁盘上的, 为了减少消息存储对磁盘的随机 I/O,一般我们会将消息写入到操作系统的 Page Cache 中,然后在合适的时间将消息刷新到磁盘上. 例如,Kafka 可以配置当达到某一时间间隔,或者累积一定的消息数量的时候再刷盘,也就是所谓的异步刷盘. 不过,如果发生机器掉电或者机器异常重启,那么 Page Cache 中还没有来得及刷盘的消息就会…

关于 Kafka 消息丢失.重复消费和顺序消费的问题 消息丢失,消息重复消费,消息顺序消费等问题是我们使用 MQ 时不得不考虑的一个问题,下面我结合实际的业务来和你分享一下解决方案. 消息丢失问题 比如我们使用 Kakfa 时,以下场景都会发生消息丢失: producer -> broker (生产者生产消息) broker -> broker (集群环境,broker 同步给其他 broker) broker -> consumer (消费者消费消息) 解决方案也很简单,设置 acks…

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

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

最近在做 AWS cost saving 的事情,对于 Kafka 消息集群,计划通过压缩消息来减少消息存储所占空间,从而达到减少 cost 的目的.本文将结合源码从 Kafka 支持的消息压缩类型.何时需要压缩.如何开启压缩.何处进行解压缩以及压缩原理来总结 Kafka 整个消息压缩机制.文中所涉及源码部分均来自于 Kafka 当前最新的 3.3.0-SNAPSHOT 版本. Kafka支持的消息压缩类型 什么是 Kafka 的消息压缩 在谈消息压缩类型之前,我们先看下 Kafka 中关于消息…

线上kafka消息堆积,所有consumer全部掉线,到底怎么回事? 最近处理了一次线上故障,具体故障表现就是kafka某个topic消息堆积,这个topic的相关consumer全部掉线. 整体排查过程和事后的复盘都很有意思,并且结合本次故障,对kafka使用的最佳实践有了更深刻的理解. 好了,一起来回顾下这次线上故障吧,最佳实践总结放在最后,千万不要错过. 1.现象 线上kafka消息突然开始堆积 消费者应用反馈没有收到消息(没有处理消息的日志) kafka的consumer group上看…

最近碰到了消息时间戳的问题,于是花了一些功夫研究了一下,特此记录一下.   Kafka消息的时间戳 在消息中增加了一个时间戳字段和时间戳类型.目前支持的时间戳类型有两种: CreateTime 和 LogAppendTime 前者表示producer创建这条消息的时间:后者表示broker接收到这条消息的时间(严格来说,是leader broker将这条消息写入到log的时间)   为什么要加入时间戳? 引入时间戳主要解决3个问题: 日志保存(log retention)策略:Kafka目前会定…

使用场景 Spark Streaming实时消费kafka数据的时候,程序停止或者Kafka节点挂掉会导致数据丢失,Spark Streaming也没有设置CheckPoint(据说比较鸡肋,虽然可以保存Direct方式的offset,但是可能会导致频繁写HDFS占用IO),所以每次出现问题的时候,重启程序,而程序的消费方式是Direct,所以在程序down掉的这段时间Kafka上的数据是消费不到的,虽然可以设置offset为smallest,但是会导致重复消费,重新overwrite hive…

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

戳更多文章: 1-Flink入门 2-本地环境搭建&构建第一个Flink应用 3-DataSet API 4-DataSteam API 5-集群部署 6-分布式缓存 7-重启策略 8-Flink中的窗口 9-Flink中的Time Flink时间戳和水印 Broadcast广播变量 FlinkTable&SQL Flink实战项目实时热销排行 Flink写入RedisSink 17-Flink消费Kafka写入Mysql 本文介绍消费Kafka的消息实时写入Mysql. maven新增依…

1.概述 对于数据的转发,Kafka是一个不错的选择.Kafka能够装载数据到消息队列,然后等待其他业务场景去消费这些数据,Kafka的应用接口API非常的丰富,支持各种存储介质,例如HDFS.HBase等.如果不想使用Kafka API编写代码去消费Kafka Topic,也是有组件可以去集成消费的.下面笔者将为大家介绍如何使用Flume快速消费Kafka Topic数据,然后将消费后的数据转发到HDFS上. 2.内容 在实现这套方案之间,可以先来看看整个数据的流向,如下图所示: 业务数据实时…

消息的存储原理: 消息的文件存储机制: 前面我们知道了一个 topic 的多个 partition 在物理磁盘上的保存路径,那么我们再来分析日志的存储方式.通过 [root@localhost ~]# ls /tmp/kafka-logs/firstTopic-1/命令找到对应 partition 下的日志内容:       00000000000000000000.index 00000000000000000000.log        00000000000000000000.timein…

前言 在游戏项目中,需要对每天千万级的游戏评论信息进行词频统计,在生产者一端,我们将数据按照每天的拉取时间存入了Kafka当中,而在消费者一端,我们利用了spark streaming从kafka中不断拉取数据进行词频统计.本文首先对spark streaming嵌入kafka的方式进行归纳总结,之后简单阐述Spark streaming+kafka在舆情项目中的应用,最后将自己在Spark Streaming+kafka的实际优化中的一些经验进行归纳总结.(如有任何纰漏欢迎补充来踩,我会第一时…

kafka在大数据.分布式架构中都很流行.kafka可以进行流式计算,也可以做为日志系统,还可以用于消息队列. 本篇主要是消息队列相关的知识. 零.kafka作为消息队列的优点: 分布式的系统 高吞吐量.即使存储了许多TB的消息,它也保持稳定的性能. 数据保留在磁盘上,因此它是持久的. 一.pull模式 消息队列有push模式和pull模式.push模式是消息队列推送给消息消费者,pull模式是消息消费者从消息队列中拉取. 二.发布 - 订阅消息系统 kafka是一个分布式的发布 - 订阅(pu…

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

一些观念的修正 从 0.9 版本开始,Kafka 的标语已经从“一个高吞吐量,分布式的消息系统”改为"一个分布式流平台". Kafka不仅仅是一个队列,而且是一个存储,有超强的堆积能力. Kafka不仅用在吞吐量高的大数据场景,也可以用在有事务要求的业务系统上,但性能较低. Kafka不是Topic越多越好,由于其设计原理,在数量达到阈值后,其性能和Topic数量成反比. 引入了消息队列,就等于引入了异步,不管你是出于什么目的.这通常意味着业务流程的改变,甚至产品体验的变更. 消息系统…

一.基本概念 Kafka是一个分布式的.可分区的.可复制的消息系统.它提供了普通消息系统的功能,但具有自己独特的设计. 首先让我们看几个基本的消息系统术语: Kafka将消息以topic为单位进行归纳. 将向Kafka topic发布消息的程序成为producers. 将预订topics并消费消息的程序成为consumer. Kafka以集群的方式运行,可以由一个或多个服务组成,每个服务叫做一个broker. producers通过网络将消息发送到Kafka集群,集群向消费者提供消息,如下图所示…

在对消息进行存储和缓存时,Kafka依赖于文件系统.(Page Cache) 线性读取和写入是所有使用模式中最具可预计性的一种方式,因而操作系统采用预读(read-ahead)和后写(write-behind)技术对磁盘读写进行探测并优化后效果也不错.预读就是提前将一个比较大的磁盘块中内容读入内存,后写是将一些较小的逻辑写入操作合并起来组成比较大的物理写入操作. 使用文件系统并依赖于页面缓存(Page Cache)要优于自己在内存中维护一个缓存或者什么别的结构. 通过对所有空闲内存自动拥有访问权…

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

背景 国内某大型税务系统,业务应用分布式上云改造. 业务难题 如上图所示是模拟客户的业务网页构建的一个并发访问模型.用户在页面点击从而产生一个HTTP请求,这个请求发送到业务生产进程,就会启动一个投递线程(Deliver Thread)调用Kafka的SDK接口,并发送3条消息到DMS(分布式消息服务),每条消息大小3k,需要等待3条消息都被处理完成后才会返回请求响应⑧.当消息达到DMS后,业务消费进程调用Kafka的消费接口把消息取出来,然后将每条消息放到一个响应线程(Response Thr…

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

使用分布式receiver来获取数据使用 WAL 来实现 exactly-once 操作: conf.set("spark.streaming.receiver.writeAheadLog.enable","true") // 开启 WAL // 1.At most once - 每条数据最多被处理一次(0次或1次),这种语义下会出现数据丢失的问题: // 2.At least once - 每条数据最少被处理一次 (1次或更多),这个不会出现数据丢失,但是会出现数…

先从源码来深入理解一下 DirectKafkaInputDStream 的将 kafka 作为输入流时,如何确保 exactly-once 语义. val stream: InputDStream[(String, String, Long)] = KafkaUtils.createDirectStream [String, String, StringDecoder, StringDecoder, (String, String, Long)]( ssc, kafkaParams, fromO…

一.概述 上次写这篇文章文章的时候,Spark还是1.x,kafka还是0.8x版本,转眼间spark到了2.x,kafka也到了2.x,存储offset的方式也发生了改变,笔者根据上篇文章和网上文章,将offset存储到Redis,既保证了并发也保证了数据不丢失,经过测试,有效. 二.使用场景 Spark Streaming实时消费kafka数据的时候,程序停止或者Kafka节点挂掉会导致数据丢失,Spark Streaming也没有设置CheckPoint(据说比较鸡肋,虽然可以保存Dire…