【中间件】Kafka 学习 01

KafKa

博客教程-1

博客教程-2

kafka简介

kafka起源

Kafka是由LinkedIn开发并开源的分布式消息系统，2012年捐赠给Apache基金会，采用Scala语言，运行在JVM中，最新版本2.0.1下载地址

kafka设计目标

Kafka是一种分布式的，基于发布/订阅的消息系统

设计目标：

• 以时间复杂度O(1)的方式提供消息持久化能力，对TB级别的数据也能保证常数时间复杂度的访问性能；
• 高吞吐率。在低配机器上也能保证每秒10万条以上消息的传输；
• 支持kafka server间的消息分区，分布式消费，同时保证每个Partition内消息的顺序传输；
• 支持离线数据和实时数据处理
• scale out，支持在线水平扩展，无需停机即可扩展机器

使用消息系统的好处

解耦，冗余，扩展性，灵活性&峰值处理能力，可恢复性，顺序保证，缓冲，异步通信

对比常用消息中间件

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 指定端口