KafKa
kafka简介
kafka起源
Kafka是由LinkedIn开发并开源的分布式消息系统,2012年捐赠给Apache基金会,采用Scala语言,运行在JVM中,最新版本2.0.1下载地址
kafka设计目标
Kafka是一种分布式的,基于发布/订阅的消息系统
设计目标:
- 以时间复杂度O(1)的方式提供消息持久化能力,对TB级别的数据也能保证常数时间复杂度的访问性能;
- 高吞吐率。在低配机器上也能保证每秒10万条以上消息的传输;
- 支持kafka server间的消息分区,分布式消费,同时保证每个Partition内消息的顺序传输;
- 支持离线数据和实时数据处理
- scale out,支持在线水平扩展,无需停机即可扩展机器
使用消息系统的好处
解耦,冗余,扩展性,灵活性&峰值处理能力,可恢复性,顺序保证,缓冲,异步通信
对比常用消息中间件
ActiveMQ | RabbitMQ | Kafka | |
---|---|---|---|
produce容错,是否丢失数据 | 有ack模型,也有事务模型,保证至少不会丢失数据。ack模型可能会有重复消息,事务模型保证完全一致 | 批量形式下可能会丢失数据;非批量形式下:1.使用同步模式可能会有重复数据,2.使用异步模式可能会丢失数据 | |
consumer容错,是否丢失数据 | 有ack模型,数据不会丢失,但可能会有重复数据 | 批量形式下可能会丢数据。非批量形式下,可能会重复处理数据(ZK写offset是异步的) | |
架构模型 | 基于JMS协议 | 基于AMQP模型,比较成熟,但更新超慢。RabbitMQ的broker由Exchange,Binding,queue组成,其中exchange和binding组成了消息的路由键;客户端Producer通过连接channel和server进行通信,Consumer从queue获取消息进行消费(长连接,queue有消息就会推送到consumer端,consumer循环从输入流读取数据);RabbitMQ以broker为中心;有消息确认机制 | producer,broker,consumer,以consumer为中心,消息的消费信息保存在客户端consumer上,consumer根据消费点从broker上批量pull数据;无消息确认机制 |
吞吐量 | RabbitMQ在吞吐量方面稍逊于Kafka,两者出发点不一样,RabbitMQ支持消息的可靠传递,支持事务,不支持批量操作;基于存储的可靠性的要求存储可以采用内存或者硬盘 | Kafka具有高吞吐量,内部采用消息的批量处理,zero-copy机制,数据的存储和获取是本地磁盘顺序批量操作,具有O(1)的复杂度,消息处理的效率很高 | |
可用性 | RabbitMQ支持miror的queue,主queue失效,miror queue接管 | Kafka的broker支持主备模式 | |
集群负载均衡 | RabbitMQ的负载均衡需要单独的loadbalancer进行支持 | Kafka采用zookeeper对集群中broker,consumer进行管理,可以注册topic到zookeeper上;通过zookeeper的协调机制,producer保存对应topic的broker信息,可以随机或者轮询发送到broker上,并且producer可以基于语义指定分片,消息发送到broker的某分片上 |
Kafka架构
Kafka术语
- Topic
用于划分Message的逻辑概念,一个Topic可以分布在多个Broker上。 - Partition
是Kafka中横向扩展和一切并行化的基础,是物理上的概念,每个Topic都至少被切分为1个Partition - Offset
消息在Partition中的编号,编号顺序不跨Partition - Consumer
用于从Broker中取出/消费Message - Consumer Group
每个Consumer属于一个特定的Consumer Group(可以为每个Consumer指定group name则属于默认的group) - Producer
用户往Broker中发送/上产消息Message - Replication
Kafka支持以Partition为单位对Message进行冗余备份,每个Partition都可以配置至少1个Replication(当仅1个Replication时即仅该Partition本身) - Leader
每个Replication集合中的Partition都会选出一个唯一的Leader,所有的读写请求都由Leader处理。其他Replicas从Leader处把数据更新同步到本地,过程类似大家熟悉的MySQL中的Binlog同步 - Broker
Kafka集群包含一个或多个服务器,这种服务器被称为broker。Kafka中使用Broker来接受Producer和Consumer的请求,并把Message持久化到本地磁盘。每个Cluster当中会选举出一个Broker来担任Controller,负责处理Partition的Leader选举,协调Partition迁移等工作 - ISR(In-Sync Replica)
是Replicas的一个子集,表示目前Alive且与Leader能够“Catch-up”的Replicas集合。由于读写都是首先落到Leader上,所以一般来说通过同步机制从Leader上拉取数据的Replica都会和Leader有一些延迟(包括了延迟时间和延迟条数两个维度),任意一个超过阈值都会把该Replica踢出ISR。每个Partition都有它自己独立的ISR
kafka单机下载安装
下载
kafka 下载地址:
http://mirrors.hust.edu.cn/apache/kafka/2.0.1/kafka_2.12-2.0.1.tgz
# wget工具下载
wget http://mirrors.hust.edu.cn/apache/kafka/2.0.1/kafka_2.12-2.0.1.tgz
解压
tar zxf kafka_2.12-2.0.1.tgz -C /aikq/kafka
修改配置文件config/server.properties
配置文件解析,参考地址
cd /aikq/kafka/kafka_2.12-2.0.1
# 修改配置文件config/server.properties
vim config/server.properties
# 后台启动kafka
./kafka-server-start.sh ../config/server.properties &
# 新建xshell连接-1,生成者
bin/kafka-console-producer.sh --broker-list ip(服务器ip):9092 --topic test
# 新建xshell连接-2,消费者
bin/kafka-console-consumer.sh --bootstrap-server ip:9092 --topic test --from-beginning
bin/kafka-console-consumer.sh --zookeeper ip:2181 --topic test --from-beginning(老版本消费命令)
# 生成者产生消息,消费者可以消费消息
kafka配置文件详细解释
############################# Server Basics #############################
# The id of the broker. This must be set to a unique integer for each broker.
broker.id=0
############################# Socket Server Settings #############################
# The address the socket server listens on. It will get the value returned from
# java.net.InetAddress.getCanonicalHostName() if not configured.
# FORMAT:
# listeners = listener_name://host_name:port
# EXAMPLE:
# listeners = PLAINTEXT://your.host.name:9092
listeners=PLAINTEXT://192.168.0.24:9092
# Hostname and port the broker will advertise to producers and consumers. If not set,
# it uses the value for "listeners" if configured. Otherwise, it will use the value
# returned from java.net.InetAddress.getCanonicalHostName().
advertised.listeners=PLAINTEXT://192.168.0.24:9092
# Maps listener names to security protocols, the default is for them to be the same. See the config documentation for more details
#listener.security.protocol.map=PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
# The number of threads that the server uses for receiving requests from the network and sending responses to the network
num.network.threads=3
# The number of threads that the server uses for processing requests, which may include disk I/O
num.io.threads=8
# The send buffer (SO_SNDBUF) used by the socket server
socket.send.buffer.bytes=102400
# The receive buffer (SO_RCVBUF) used by the socket server
socket.receive.buffer.bytes=102400
# The maximum size of a request that the socket server will accept (protection against OOM)
socket.request.max.bytes=104857600
############################# Log Basics #############################
# A comma separated list of directories under which to store log files
log.dirs=/opt/data/kafka/kafka-logs
# The default number of log partitions per topic. More partitions allow greater
# parallelism for consumption, but this will also result in more files across
# the brokers.
num.partitions=1
# The number of threads per data directory to be used for log recovery at startup and flushing at shutdown.
# This value is recommended to be increased for installations with data dirs located in RAID array.
num.recovery.threads.per.data.dir=1
############################# Internal Topic Settings #############################
# The replication factor for the group metadata internal topics "__consumer_offsets" and "__transaction_state"
# For anything other than development testing, a value greater than 1 is recommended for to ensure availability such as 3.
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1
############################# Log Flush Policy #############################
# Messages are immediately written to the filesystem but by default we only fsync() to sync
# the OS cache lazily. The following configurations control the flush of data to disk.
# There are a few important trade-offs here:
# 1. Durability: Unflushed data may be lost if you are not using replication.
# 2. Latency: Very large flush intervals may lead to latency spikes when the flush does occur as there will be a lot of data to flush.
# 3. Throughput: The flush is generally the most expensive operation, and a small flush interval may lead to excessive seeks.
# The settings below allow one to configure the flush policy to flush data after a period of time or
# every N messages (or both). This can be done globally and overridden on a per-topic basis.
# The number of messages to accept before forcing a flush of data to disk
#log.flush.interval.messages=10000
# The maximum amount of time a message can sit in a log before we force a flush
#log.flush.interval.ms=1000
############################# Log Retention Policy #############################
# The following configurations control the disposal of log segments. The policy can
# be set to delete segments after a period of time, or after a given size has accumulated.
# A segment will be deleted whenever *either* of these criteria are met. Deletion always happens
# from the end of the log.
# The minimum age of a log file to be eligible for deletion due to age
log.retention.hours=168
# A size-based retention policy for logs. Segments are pruned from the log unless the remaining
# segments drop below log.retention.bytes. Functions independently of log.retention.hours.
#log.retention.bytes=1073741824
# The maximum size of a log segment file. When this size is reached a new log segment will be created.
log.segment.bytes=1073741824
# The interval at which log segments are checked to see if they can be deleted according
# to the retention policies
log.retention.check.interval.ms=300000
############################# Zookeeper #############################
# Zookeeper connection string (see zookeeper docs for details).
# This is a comma separated host:port pairs, each corresponding to a zk
# server. e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002".
# You can also append an optional chroot string to the urls to specify the
# root directory for all kafka znodes.
zookeeper.connect=localhost:3181
# Timeout in ms for connecting to zookeeper
zookeeper.connection.timeout.ms=6000
############################# Group Coordinator Settings #############################
# The following configuration specifies the time, in milliseconds, that the GroupCoordinator will delay the initial consumer rebalance.
# The rebalance will be further delayed by the value of group.initial.rebalance.delay.ms as new members join the group, up to a maximum of max.poll.interval.ms.
# The default value for this is 3 seconds.
# We override this to 0 here as it makes for a better out-of-the-box experience for development and testing.
# However, in production environments the default value of 3 seconds is more suitable as this will help to avoid unnecessary, and potentially expensive, rebalances during application startup.
group.initial.rebalance.delay.ms=0
kafka伪集群模式
broker-0:
vim config/server-0.properties
broker.id=0
listeners=PLAINTEXT://:9092
port=9092
#host.name=192.168.1.177
num.network.threads=4
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=/tmp/kafka-logs
num.partitions=5
num.recovery.threads.per.data.dir=1
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
log.cleaner.enable=false
zookeeper.connect=localhost:2181
zookeeper.connection.timeout.ms=6000
queued.max.requests =500
log.cleanup.policy = delete
broker-1:
vim config/server-1.properties
broker.id=1
listeners=PLAINTEXT://:9093
port=9093
#host.name=192.168.1.177
num.network.threads=4
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=/tmp/kafka-logs
num.partitions=5
num.recovery.threads.per.data.dir=1
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
log.cleaner.enable=false
zookeeper.connect=localhost:2181
zookeeper.connection.timeout.ms=6000
queued.max.requests =500
log.cleanup.policy = delete
broker-2:
vim config/server-2.properties
broker.id=2
listeners=PLAINTEXT://:9094
port=9094
#host.name=192.168.1.177
num.network.threads=4
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=/tmp/kafka-logs
num.partitions=5
num.recovery.threads.per.data.dir=1
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
log.cleaner.enable=false
zookeeper.connect=localhost:2181
zookeeper.connection.timeout.ms=6000
queued.max.requests =500
log.cleanup.policy = delete
分别启动这个三个broker
bin/kafka-server-start.sh config/server-0.properties & #启动broker-0
bin/kafka-server-start.sh config/server-1.properties & #启动broker-1
bin/kafka-server-start.sh config/server-2.properties & #启动broker-2
生产者-消费者集群模式
bin/kafka-console-producer.sh --topic topic_1 --broker-list 192.168.1.177:9092,192.168.1.177:9093,192.168.1.177:9094
kafka集群模式
kafka-manager 可视化管理
-
下载源码
gitUrl:https://github.com/yahoo/kafka-manager -
编译
# linux 环境
./sbt clean dist
# win 环境
sbt clean dist
- 安装
# 解压
unzip *.zip
# cd conf 目录下,编辑配置文件 application.conf
kafka-manager.zkhosts="localhost:2181"
# cd bin 目录下,启动
./kafka-manager -Dconfig.file=../conf/application.conf -Dhttp.port=9000
-Dconfig.file
配置文件地址
-java-home
指定java环境
-Dhttp.port
指定端口