赞
踩
1.将kafka包 解压至/usr/local/下,新建一个logs文件夹
2.修改 /config/server.properties 中的logs参数,值为 上一步创建的logs位置
3.修改配置文件,当前是使用自己的zookeeper,修改./config/server.properties中的这四个地方
listeners = PLAINTEXT://localhost:9092
zookeeper.connect=127.0.0.1:2181
broker.id=0
port = 9092
4.进去bin启动kafka。命令:./kafka-server-start.sh -daemon ../config/server.properties
5.cd /logs/server.log 看日志
6.ps -ef|grep kafka 看进程
7.进入kafka 的bin下面:
7.1创建topic名字为test的: ./kafka-topics.sh --create --zookeeper 127.0.0.1:2181 --replication-factor 1 --partitions 1 --topic test
7.2往topic名字为test的队列发消息: ./kafka-console-producer.sh --broker-list localhost:9092 --topic test
7.3读取topic名字为test的队列消息: ./kafka-console-consumer.sh --bootstrap-server 127.0.0.1:9092 --topic test --from-beginning
kafka简单介绍:
Topic: 主题
Partition 分区: 存topic中的数据,分布式存储,支持高并发大流量的核心,限定每个文件最大1G。数据是顺序的、不可变的。分区中的消息都被分了一个序列号,称之为偏移量(offset),在每个分区中此偏移量都是唯一的
Replica - factor: Partition 分区的副本,一般一个Partition对应两个副本。副本区分leader和follower,follower同步leader数据。
Consumer: 消费者,同一个topic数据,只能消费一次。
Consumer Group - 消费者组: 每组都可以消费一次topic数据。
kafka对消息的存储和缓存依赖于文件系统,每次接收数据都会往磁盘上写,一般往磁盘上读写都是比较慢的,那么为什么kafka吞吐量很高呢(每秒几十万的吞吐量)? 主要是基于页缓存技术+磁盘顺序写+零拷贝技术+分区分桶技术才会比较快。
页缓存技术:Kafka 为了保证磁盘写入性能,首先Kafka是基于操作系统的页缓存来实现文件写入的。操作系统本身有一层缓存,叫做page cache,是在内存里的缓存,我们也可以称之为os cache,意思就是操作系统自己管理的缓存。你在写磁盘文件的时候,可以直接写入os cache 中,也就是仅仅写入内存中,接下来由操作系统自己决定什么时候把os cache 里的数据真的刷入到磁盘中。
磁盘顺序写:Kafka在写数据的时候是以磁盘顺序写的方式来落盘的,也就是说,仅仅将数据追加到文件的末尾(append),而不是在文件的随机位置来修改数据。对于普通的机械硬盘如果你要是随机写的话,确实性能极低,这里涉及到磁盘寻址的问题。但是如果只是追加文件末尾按照顺序的方式来写数据的话,那么这种磁盘顺序写的性能基本上可以跟写内存的性能本身是差不多的。
零拷贝技术:通常是指计算机在网络上发送文件时,不需要将文件内容拷贝到用户空间(User Space)而直接在内核空间(Kernel Space)中传输到网络的方式。根本没有把数据复制到我们的应用缓存中,实际上只复制一次到cpu. 直接让操作系统的cache中的数据发送到网卡后传出给下游的消费者,中间跳过了两次拷贝数据的步骤,Socket缓存中仅仅会拷贝一个描述符过去,不会拷贝数据到Socket缓存。这叫做零拷贝技术
分布式系统分区分桶的设计思想:Kafka的message消息实际上是分布式存储在一个一个小的segment中的,每次文件操作也是直接操作的segment。为了进一步的查询优化,Kafka又默认为分段后的数据文件建立了索引文件,就是文件系统上的.index文件。这种分区分段+索引的设计,不仅提升了数据读取的效率,同时也提高了数据操作的并行度
如何实现幂等性(不丢消息)?broker收到消息后会回复ack,如果此时出现问题,消息会再次消费,那怎么办呢?
属性 enable.idempotence设置为true。在Producer初始化时分配,作为每个Producer会话的唯一标识,Producer发送的每条消息都会带有此序列号,从0开始单调递增,
Broker会为每个消息维护序列号。对每条接收到的消息,都会检查它的序列号是否比Broker所维护的值严格+1,只有这样才是合法的,其他情况都会丢弃。
如果Producer重启(PID发生变化),或者写入是跨Topic、跨Partition的,单纯的幂等性就会失效,需要更高级别的事务性来解决了。需要专门的协调组件TransactionCoordinator做协调。组件会记录服务的pid。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。