![](https://img-blog.csdnimg.cn/20201014180756916.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
kafka
zyj_369
曾经的我 一身迷彩 手握钢枪 现在的我 对新科技充满着无限好奇 喜欢专研大数据技术 希望可以和志同道合的人一起加油 一起圆梦
展开
-
Kafka 实现高效读写数据
一、顺序写磁盘 Kafka 的 producer 生产数据,要写入到 log 文件中,写的过程是一直追加到文件末端,为顺序写。官网有数据表明,同样的磁盘,顺序写能到 600M/s,而随机写只有 100K/s。这与磁盘的机械机构有关,顺序写之所以快,是因为其省去了大量磁头寻址的时间。 二、零复制(零拷贝)技术 ...原创 2020-10-27 09:56:04 · 276 阅读 · 0 评论 -
flume中 kafka sink flume自定义Interceptor实现消息分主题收集
自定义 flume 拦截器类,并打包上传到 /flume/lib 下 import org.apache.flume.Context; import org.apache.flume.Event; import org.apache.flume.interceptor.Interceptor; import java.util.ArrayList; import java.util.List; import java.util.Map; /* 自定义flume 拦截器 */ public class Ka原创 2020-10-27 09:07:43 · 311 阅读 · 0 评论 -
flume kafka sink kafka对接flume简单实现详解
1、flume的配置文件 kafka-sink.properties # Name the components on this agent # source:起一个别名 # properties文件它是java的配置文件,=左边就是键,=右边是值;键的开头都是以a1(就是flume的名字--agent的名字就是a1);a1随便起 a1.sources = r1 # sink:起一个别名 a1.sinks = k1 # channels;:起一个别名 a1.channels = c1 # Describe原创 2020-10-26 21:33:39 · 1998 阅读 · 0 评论 -
Kafka producer 自定义拦截器(interceptor)
一、拦截器原理 Producer 拦截器(interceptor)是在 Kafka 0.10 版本被引入的,主要用于实现 clients 端的定制化控制逻辑。 对于 producer 而言,interceptor 使得用户在消息发送前以及 producer 回调逻辑前有机会对消息做一些定制化需求,比如修改消息等。同时,producer 允许用户指定多个 interceptor按序作用于同一条消息从而形成一个拦截链(interceptor chain)。 Intercetpor 的实现接口是 org.apa原创 2020-10-26 17:21:48 · 606 阅读 · 8 评论 -
kafka consumer消费者API
一、准备工作 在IDE上创建maven项目,pom文件添加依赖 <!-- https://mvnrepository.com/artifact/org.apache.kafka/kafka-clients --> <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-clients</artifactId> <version原创 2020-10-26 15:03:48 · 321 阅读 · 0 评论 -
kafka producer 生产者API操作
一、准备工作 在IDE上创建maven项目,pom文件添加依赖 <!-- https://mvnrepository.com/artifact/org.apache.kafka/kafka-clients --> <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-clients</artifactId> <version原创 2020-10-25 20:53:00 · 178 阅读 · 0 评论 -
Kafka consumer 消费者原理详解
一、消费方式 kafka采用发布订阅模式:一对多。发布订阅模式又分两种: push(推)模式很难适应消费速率不同的消费者,因为消息发送速率是由 broker 决定的。它的目标是尽可能以最快速度传递消息,但是这样很容易造成 consumer 来不及处理消息,典型的表现就是拒绝服务以及网络拥塞。而 pull 模式则可以根据 consumer 的消费能力以适当的速率消费消息。 kafka consumer 采用 pull(拉)模式从 broker 中读取数据。pull 模式不足之处是,如果 kafka 没原创 2020-10-25 12:29:42 · 1228 阅读 · 0 评论 -
Kakfa Broker Leader的选举机制讲解
Kakfa Broker Leader的选举 Kakfa Broker集群受Zookeeper管理。 所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点,因为只有一个Kafka Broker会注册成功,其他的都会失败,所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller,其他的Kafka broker叫Kafka Broker follower。(这个过程叫Controller在ZooKeeper注册Wa原创 2020-10-24 15:55:42 · 1867 阅读 · 6 评论 -
kafka producer生产者设计原理讲解
一、分区策略 分区的原因 方便在集群中扩展,每个 Partition 可以通过调整以适应它所在的机器,而一个 topic又可以有多个 Partition 组成,因此整个集群就可以适应任意大小的数据了; 可以提高并发,因为可以以 Partition 为单位读写了。 分区的原则 我们需要将 producer 发送的数据封装成一个 ProducerRecord 对象。 (1)指明 partition 的情况下,直接将指明的值直接作为 partiton 值; (2)没有指明 partition 值但有原创 2020-10-24 15:08:39 · 426 阅读 · 0 评论 -
kafka 集群部署搭建
一、简单介绍 Kafka 是一个分布式的基于发布/订阅模式的消息队列(Message Queue),主要应用于 大数据实时处理领域。 二、集群规划 主机 centos7-1 centos7-2 centos7-3 centos7-4 kafka √ √ √ √ zookeeper √ √ √ √ 三、集群部署 解压安装包 修改配置文件 vim conf/server.properties #broker 的全局唯一编号,不能重复 broker.id=0 #删除 topi原创 2020-10-23 22:24:29 · 138 阅读 · 0 评论 -
消息队列的两种模式及优缺点
一、使用消息队列的好处 解耦:允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。 可恢复性:系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。 缓冲:有助于控制和优化数据流经过系统的速度,解决生产消息和消费消息的处理速度不一致 的情况。 灵活性 &峰值处理能力:在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随原创 2020-10-23 21:49:02 · 974 阅读 · 0 评论 -
Kafka 基础架构、工作流程、存储机制介绍
Producer :消息生产者,向 kafka broker 发消息的客户端; Consumer :消息消费者,向 kafka broker 取消息的客户端; Consumer Group :消费者组,由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据,一个分区只能由一个组内消费者消费;消费者组之间互不影响。所有的消费者都属于某个消费者组,即消费者组是逻辑上的一个订阅者。 Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 b..原创 2020-10-23 21:16:43 · 283 阅读 · 0 评论 -
Kafka 常用命令行操作汇总
启动服务 bin/kafka-server-start.sh config/server.properties 阻塞进程 bin/kafka-server-start.sh -daemon config/server.properties 守护进程 停止服务 bin/kafka-server-stop.sh config/server.properties 新建Topic bin/kafka-topics.sh --zookeeper centos7-1:2181 --create --topic my原创 2020-10-20 20:25:00 · 340 阅读 · 0 评论