大数据生态系统基础:Apache Kafka基础(一):介绍和安装
来源:互联网 发布:发型配帽子 知乎 编辑:程序博客网 时间:2024/05/22 14:09
http://blog.csdn.net/zhy_yz/article/details/5905637
一、 Apache kafka基础介绍
1、kafka 是什么?
首先一句话: Apache Kafka 是一个分布式的消息流平台。其模式就是我们在设计模式中常用的出版-订阅模式。
一个流平台有三个核心关键:
1)能够出版和订阅数据流记录。 这个和消息队列以及企业消息系统是一样的。
2)容错方式存储流记录
3对产生的流记录可以进行处理
哪 kafka 会做什么咧?
1)在系统或者应用间建立可靠的实时的流数据管道
2)建立实时流APP,可以对数据流进行转换或者处理
所以,Kafka 是运行在一个集群上的,能够分类存储流记录,这个流记录叫 topic,不是 storm 的元组。事实,这其实也是一个键值对,key-value,哈,还加上一个时间戳!
kafka 有四个核心 API 哦。如下图所示
1)生产者(或者出版者)API:一个 App 能出版一个流记录给一个或者更多 Kafka topic。
2) 消费者(后者订阅者)API: 一个 APP能订阅一个或者更多的主题/话题(topic),并且可以处理更多的流记录
3) 流 API: 一个 APP 可以作为一个流处理器,消费一个来自一个或者更多话题的输入流,并且产生一个输出流给一个或者更多的输出流,能够有效地将输入流转换为输出流。
4)连接器 (connector)API:能够建立和运行可复用的生产者或者消费者,他们能连接 Kafka 话题到一个存在的 APP 或者数据系统。比如,连接到一个关系型数据库,获取一张表格的变化。
2、主题和日志(topics and logs)
主题就是出版者记录的分类或者供给名。Kafka 中的话题一直有多个订阅者;一个话题能有0,1,或者订阅里面数据的许多消费者。
一个话题,kafka 集群维护一个这样的分区 log。
每个分区都是有序的、不变的记录序列,能够持续追加的一个结构化的日志 log。
分区里的记录每个都被分配了一个唯一的序列号,称之为 偏移量(offset)。
kafka集群在一个保存期里维护所有的已经出版的记录,不管他们有没有被消费。如果保存期设置为2天,2天内所有的记录都会被出版,客户都能订阅使用,但是2天后,就会被丢失,释放空间。kafka 集群的性能不会受数据长度和保存期的影响。
消费者可以根据偏移量去使用数据, 这个偏移量消费者可以随时自己设定。
分区的目的:一是允许日志能超过一定的大小,单个服务器都可以用;单个分区也适合集群服务器,当然,一个话题也可以有很多的分区。二是在某点上可以作为并行单位。
3、分布式
日志的分区在 kafak 集群上可以分布到各个服务器上,每个服务器处理数据和分区的共享请求。每个分区可以复制到可配置的服务器上,提高了容错性。
每个分区有一个服务器作为 leader 和 zero ,其它的服务器扮作 follower 。
leader处理读写分区的请求,follower 被动地复制 leader。 如果 leader 失效,一个 follower 将自动成为 leader。
每一个服务器可以为它的者一部分分区作为 leader,一部分分区作为 follower,所以,负载能够在集群中达到很好的平衡。
4、生产者
生产者为他们所选的话题发布数据。
生产者负责在话题里选择记录分配给那个分区。这可以以循环的方式进行,只是为了平衡负载,或者可以根据一些语义分区功能(根据记录中的一些键)来完成。
5、消费者
消费者给自己贴上一个消费者组的标签,每一个发布到一个主题的记录都被交付给每个订阅消费者组中的一个消费者实例。消费者实例可以在单独的进程中,也可以在单独的机器上。
如果所有的消费者实例都有相同的消费者组,那么这些记录将有效地在消费者实例上负载平衡。
如果所有的消费者实例都有不同的消费者组,那么每个记录将被广播到所有的消费者进程。
上图是两个服务组成的集群,拥有4个分区 P0-P3,A消费者组有2个消费者实例,B 组有4个。
二、安装
6月28日发布了最新的版本0.11.0.0。国内下载地址:
http://mirror.bit.edu.cn/apache/kafka/0.11.0.0/kafka_2.12-0.11.0.0.tgz
http://mirrors.tuna.tsinghua.edu.cn/apache/kafka/0.11.0.0/kafka_2.12-0.11.0.0.tgz
解压到 home 的根目录下面。 ~/kafka_2.12-0.11.0.0
1、修改.bash_profile 或者 etc/profile
增加路径寻找:
###setup kafka
export KAFKA_HOME=$HOME/kafka_2.12-0.11.0.0
export PATH=$KAFKA_HOME/bin:$PATH
然后,source ~/.bash_profile 生效即可。在每一台服务上都需要配置。
2、配置文件在 config 中
1)Server.properties
host.name=mymac
zookeeper.connect=mymac:2181,master:2181,slave1:2181,slave2:2181
log.dirs=/usr/local/var/log/kafka
关键是要配置和 zookeeper 的连接。
# The id of the broker. This must be set to a unique integer for each broker.设置唯一的值
broker.id=0
2) 其它参数的解释如下:
参数
说明(解释)
broker.id =0
每一个broker在集群中的唯一表示,要求是正数。当该服务器的IP地址发生改变时,broker.id没有变化,则不会影响consumers的消息情况
log.dirs=/data/kafka-logs
kafka数据的存放地址,多个地址的话用逗号分割,多个目录分布在不同磁盘上可以提高读写性能 /data/kafka-logs-1,/data/kafka-logs-2
port =9092
broker server服务端口
message.max.bytes =6525000
表示消息体的最大大小,单位是字节
num.network.threads =4
broker处理消息的最大线程数,一般情况下数量为cpu核数
num.io.threads =8
broker处理磁盘IO的线程数,数值为cpu核数2倍
background.threads =4
一些后台任务处理的线程数,例如过期消息文件的删除等,一般情况下不需要去做修改
queued.max.requests =500
等待IO线程处理的请求队列最大数,若是等待IO的请求超过这个数值,那么会停止接受外部消息,应该是一种自我保护机制。
host.name
broker的主机地址,若是设置了,那么会绑定到这个地址上,若是没有,会绑定到所有的接口上,并将其中之一发送到ZK,一般不设置
socket.send.buffer.bytes=100*1024
socket的发送缓冲区,socket的调优参数SO_SNDBUFF
socket.receive.buffer.bytes =100*1024
socket的接受缓冲区,socket的调优参数SO_RCVBUFF
socket.request.max.bytes =100*1024*1024
socket请求的最大数值,防止serverOOM,message.max.bytes必然要小于socket.request.max.bytes,会被topic创建时的指定参数覆盖
log.segment.bytes =1024*1024*1024
topic的分区是以一堆segment文件存储的,这个控制每个segment的大小,会被topic创建时的指定参数覆盖
log.roll.hours =24*7
这个参数会在日志segment没有达到log.segment.bytes设置的大小,也会强制新建一个segment会被 topic创建时的指定参数覆盖
log.cleanup.policy = delete
日志清理策略选择有:delete和compact主要针对过期数据的处理,或是日志文件达到限制的额度,会被 topic创建时的指定参数覆盖
log.retention.minutes=300
或
log.retention.hours=24
数据文件保留多长时间, 存储的最大时间超过这个时间会根据log.cleanup.policy设置数据清除策略
log.retention.bytes和log.retention.minutes或log.retention.hours任意一个达到要求,都会执行删除
有2删除数据文件方式:
按照文件大小删除:log.retention.bytes
按照2中不同时间粒度删除:分别为分钟,小时
log.retention.bytes=-1
topic每个分区的最大文件大小,一个topic的大小限制 = 分区数*log.retention.bytes。-1没有大小限log.retention.bytes和log.retention.minutes任意一个达到要求,都会执行删除,会被topic创建时的指定参数覆盖
log.retention.check.interval.ms=5minutes
文件大小检查的周期时间,是否处罚 log.cleanup.policy中设置的策略
log.cleaner.enable=false
是否开启日志清理
log.cleaner.threads = 2
日志清理运行的线程数
log.cleaner.io.max.bytes.per.second=None
日志清理时候处理的最大大小
log.cleaner.dedupe.buffer.size=500*1024*1024
日志清理去重时候的缓存空间,在空间允许的情况下,越大越好
log.cleaner.io.buffer.size=512*1024
日志清理时候用到的IO块大小一般不需要修改
log.cleaner.io.buffer.load.factor =0.9
日志清理中hash表的扩大因子一般不需要修改
log.cleaner.backoff.ms =15000
检查是否处罚日志清理的间隔
log.cleaner.min.cleanable.ratio=0.5
日志清理的频率控制,越大意味着更高效的清理,同时会存在一些空间上的浪费,会被topic创建时的指定参数覆盖
log.cleaner.delete.retention.ms =1day
对于压缩的日志保留的最长时间,也是客户端消费消息的最长时间,同log.retention.minutes的区别在于一个控制未压缩数据,一个控制压缩后的数据。会被topic创建时的指定参数覆盖
log.index.size.max.bytes =10*1024*1024
对于segment日志的索引文件大小限制,会被topic创建时的指定参数覆盖
log.index.interval.bytes =4096
当执行一个fetch操作后,需要一定的空间来扫描最近的offset大小,设置越大,代表扫描速度越快,但是也更好内存,一般情况下不需要搭理这个参数
log.flush.interval.messages=None
例如log.flush.interval.messages=1000
表示每当消息记录数达到1000时flush一次数据到磁盘
log文件”sync”到磁盘之前累积的消息条数,因为磁盘IO操作是一个慢操作,但又是一个”数据可靠性"的必要手段,所以此参数的设置,需要在"数据可靠性"与"性能"之间做必要的权衡.如果此值过大,将会导致每次"fsync"的时间较长(IO阻塞),如果此值过小,将会导致"fsync"的次数较多,这也意味着整体的client请求有一定的延迟.物理server故障,将会导致没有fsync的消息丢失.
log.flush.scheduler.interval.ms =3000
检查是否需要固化到硬盘的时间间隔
log.flush.interval.ms = None
例如:log.flush.interval.ms=1000
表示每间隔1000毫秒flush一次数据到磁盘
仅仅通过interval来控制消息的磁盘写入时机,是不足的.此参数用于控制"fsync"的时间间隔,如果消息量始终没有达到阀值,但是离上一次磁盘同步的时间间隔达到阀值,也将触发.
log.delete.delay.ms =60000
文件在索引中清除后保留的时间一般不需要去修改
log.flush.offset.checkpoint.interval.ms =60000
控制上次固化硬盘的时间点,以便于数据恢复一般不需要去修改
auto.create.topics.enable =true
是否允许自动创建topic,若是false,就需要通过命令创建topic
default.replication.factor =1
是否允许自动创建topic,若是false,就需要通过命令创建topic
num.partitions =1
每个topic的分区个数,若是在topic创建时候没有指定的话会被topic创建时的指定参数覆盖
以下是kafka中Leader,replicas配置参数
controller.socket.timeout.ms =30000
partition leader与replicas之间通讯时,socket的超时时间
controller.message.queue.size=10
partition leader与replicas数据同步时,消息的队列尺寸
replica.lag.time.max.ms =10000
replicas响应partition leader的最长等待时间,若是超过这个时间,就将replicas列入ISR(in-sync replicas),并认为它是死的,不会再加入管理中
replica.lag.max.messages =4000
如果follower落后与leader太多,将会认为此follower[或者说partition relicas]已经失效
##通常,在follower与leader通讯时,因为网络延迟或者链接断开,总会导致replicas中消息同步滞后
##如果消息之后太多,leader将认为此follower网络延迟较大或者消息吞吐能力有限,将会把此replicas迁移
##到其他follower中.
##在broker数量较少,或者网络不足的环境中,建议提高此值.
replica.socket.timeout.ms=30*1000
follower与leader之间的socket超时时间
replica.socket.receive.buffer.bytes=64*1024
leader复制时候的socket缓存大小
replica.fetch.max.bytes =1024*1024
replicas每次获取数据的最大大小
replica.fetch.wait.max.ms =500
replicas同leader之间通信的最大等待时间,失败了会重试
replica.fetch.min.bytes =1
fetch的最小数据尺寸,如果leader中尚未同步的数据不足此值,将会阻塞,直到满足条件
num.replica.fetchers=1
leader进行复制的线程数,增大这个数值会增加follower的IO
replica.high.watermark.checkpoint.interval.ms =5000
每个replica检查是否将最高水位进行固化的频率
controlled.shutdown.enable =false
是否允许控制器关闭broker ,若是设置为true,会关闭所有在这个broker上的leader,并转移到其他broker
controlled.shutdown.max.retries =3
控制器关闭的尝试次数
controlled.shutdown.retry.backoff.ms =5000
每次关闭尝试的时间间隔
leader.imbalance.per.broker.percentage =10
leader的不平衡比例,若是超过这个数值,会对分区进行重新的平衡
leader.imbalance.check.interval.seconds =300
检查leader是否不平衡的时间间隔
offset.metadata.max.bytes
客户端保留offset信息的最大空间大小
kafka中zookeeper参数配置
zookeeper.connect = localhost:2181
zookeeper集群的地址,可以是多个,多个之间用逗号分割hostname1:port1,hostname2:port2,hostname3:port3
zookeeper.session.timeout.ms=6000
ZooKeeper的最大超时时间,就是心跳的间隔,若是没有反映,那么认为已经死了,不易过大
zookeeper.connection.timeout.ms =6000
ZooKeeper的连接超时时间
zookeeper.sync.time.ms =2000
ZooKeeper集群中leader和follower之间的同步实际那
3、将$HOME/kafka_2.12-0.11.0.0远程拷贝到其它服务器上
scp -r $HOME/kafka_2.12-0.11.0.0 wangxinnian@master:$HOME/kafka_2.12-0.11.0.0
scp -r $HOME/kafka_2.12-0.11.0.0 wangxinnian@slave2:$HOME/kafka_2.12-0.11.0.0
分别修改各自 config 目录下 server.properites 里面的 broker.id 的值
对 master: broker.id=1
对slave1: broker.id=2
对 slave2: broker.id=3
对于在不同的物理服务器上,port 的值缺省即可,因为不在同一台服务器上,不会造成 port 冲突。
4、在每台服务上启动
start-kaka.sh
三、运行
1、创建 topic
kafka-topics
.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic
test
然后,查看创建的 topic
kafka-topics
.sh --list --zookeeper localhost:2181
test
2、发送其它的信息
启动 生产者:
kafka-console-producer.sh --broker-list mymac:9092 --topic test
注意:不适用 localhost:9092,因为不知道指定到那个主机。
>hello world
>This is a message
>This is ano
>This is another message
3、启动消费者
启动消费者,获取生产者的信息
kafka-console-consumer.sh --bootstrap-server slave2:9092 --topic test --from-beginning
hello world
This is a message
This is ano
This is another message
[2017-08-04 13:41:07,809] WARN Connection to node -1 could not be established.
- 大数据生态系统基础:Apache Kafka基础(一):介绍和安装
- 大数据生态系统基础:Apache Kafka基础(一):介绍和安装
- 大数据生态系统基础:Hadoop(一):介绍和安装
- 大数据生态系统基础:Apache Spark(一):介绍和编译、安装
- 大数据生态系统基础:Apache Kafka基础(二):最新kafka编程入门:Producer API
- 大数据生态系统基础:Apache Kafka基础(三):最新kafka编程入门:Consumer
- 大数据生态系统基础:Apache Kafka基础(四):最新kafka编程入门:Stream API
- Hadoop生态系统介绍(大数据基础系列一)
- 大数据生态系统基础: HIVE(一):HIVE 介绍及安装、配置
- 大数据生态系统基础: HBASE(一):HBASE 介绍及安装、配置
- 大数据生态系统基础:Apache Spark(二):运行环境和实例演示
- 大数据基础:Hadoop2.x生态系统(一)
- 大数据生态系统基础:Hadoop(二):Hadoop 3.0.0集群安装和验证
- 大数据生态系统基础:Apache Spark(三):Java 版本编程实例(WordCount)
- Apache Kafka笔记(一):基础架构
- 大数据生态系统基础:Hadoop(七):Hadoop MapReduce 工作原理和 YARN架构
- 大数据生态系统基础: HIVE(二):HIVE 架构和HiveQL基本操作
- 大数据生态系统基础:Hadoop(五):Hadoop 3.0.0 HDFS读写及编程基础
- Mysql
- PostgreSQL 慢查询SQL语句跟踪
- latex的基本使用
- grade优化加速打包总结
- 屏蔽 Chrome “请停用以开发者模式运行的扩展程序”
- 大数据生态系统基础:Apache Kafka基础(一):介绍和安装
- CentOS 7下安装Composer + Laravel
- 开发人员面试62到经典题
- 1.关于Mysql数据库操作的基本语句(不定时更新)
- [疑问]Scanner与正则表达式的问题[已解决!]
- Elasticsearch5.X进行聚合操作时提示Fielddata is disabled on text fields by default
- java编码问题小结
- 【云星数据---flink实战系列001】:flink简介
- 线性推逆元