（一）kafka官方文档学习

kafka官方0.10版文档学习

官方文档

1：入门基础

1.1：基础知识

1.1.1：kafka的作用

1：建立实时流数据管道，以可靠地在系统或应用程序之间获取数据
2：构建实时流应用程序，以转换或响应数据流

1.1.2：基本概念

1:Kafka在一个或多个服务器上作为集群运行。
2:Kafka集群将记录流存储在称为主题的类别中。
3:每个记录由一个键，一个值和一个时间戳组成。

1.1.3:四大核心api

produce：API允许应用程序发布流记录到一个或多个卡夫卡的话题。
consumer：API允许应用程序订阅一个或多个主题，并处理所产生的对他们记录的数据流。
stream：API允许应用程序充当流处理器，从一个或多个主题消耗的输入流，并产生一个输出流至一个或多个输出的主题，有效地将所述输入数据流，以输出流。
connect：该连接器API允许构建和运行可重复使用的生产者或消费者连接卡夫卡主题，以现有的应用程序或数据系统。例如，关系数据库的连接器可能会捕获对

1.1.4：主题topic

主题是将记录发布到的类别或订阅源名称。每个主题Tipic都是由多个分区组成的，并且分区是有序的，对于每个主题，Kafka集群都会维护一个分区日志。

1：主题的保留期限

Kafka群集使用可配置的保留期限来保留所有已发布的记录（无论是否已被使用）。例如，如果将保留策略设置为两天，则在发布记录后的两天内，该记录可供使用，之后将被丢弃以释放空间。Kafka的性能相对于数据大小实际上是恒定的，因此长时间存储数据不是问题

实际上，基于每个消费者保留的唯一元数据是该消费者在日志中的偏移量或位置。此偏移量由使用者控制：如图

2：分区的主从

每个分区都有一个充当“领导者”的服务器和零个或多个充当“跟随者”的服务器。领导者处理对分区的所有读写请求，而跟随者则被动地复制领导者。

1.1.5：生产者：produce

生产者将数据发布到他们选择的主题。生产者负责选择将哪个记录分配给主题中的哪个分区,通过轮询可以达到负载均衡

1.1.6：消费者：consumer

消费者使用消费者组名称标记自己，并且发布到主题的每条记录都会传递到每个订阅消费者组中的一个消费者实例，如图消费者组A,消费者组B

1.2:部署使用

忽略，自行查找

2：API使用

produce：API允许应用程序发布流记录到一个或多个卡夫卡的话题。
consumer：API允许应用程序订阅一个或多个主题，并处理所产生的对他们记录的数据流。
stream：API允许应用程序充当流处理器，从一个或多个主题消耗的输入流，并产生一个输出流至一个或多个输出的主题，有效地将所述输入数据流，以输出流。
connect：该连接器API允许构建和运行可重复使用的生产者或消费者连接卡夫卡主题，以现有的应用程序或数据系统。例如，关系数据库的连接器可能会捕获

1:maven依赖
kafka-clients的jar包是官方提供的kafka操作服务端的客户端代码

 
	     org.apache.kafka  
	     kafka-clients  
	     0.10.0.0  

2.1：生产者

包括两个低级生产者-同步和异步

同步：kafka.producer.SyncProducer
异步：kafka.producer.async.AsyncProducer

2.1.1 生产的分区策略

默认的分区策略是hash(key)%numPartitions。如果键为null，则选择一个随机代理分区。还可以使用partitioner.class config参数插入自定义分区策略（实现接口Partitioner）。

2.1.2：批处理的大小

可以通过一些配置参数来控制。当事件进入队列时，它们将被缓冲在队列中，直到到达queue.time或为止batch.size

3：参数配置

新版本的配置说明

3.1：生产者配置

3.2：消费者配置

注意新旧版的参数，也就是0.9之前和之后

4：kafka的设计

4.1：kafka的3种消费语义

值得注意的是，这可分为两个问题：发布消息的持久性保证和使用消息时的保证性，也就是说生产者语义和消费者语义保证

4.1.1：生产者语义 :acks

对于生产者而言其实是消息发送成功的确认保证，对acks的配置以及ISR副本同步机制

最多一次：只需要异步不断的发送即可，效率也比较高,只发送不管成功与否，消息可能会丢失，但永远不会重新发送。
至少一次：只需要同步确认即可（确认方式分为（acks配置）只需要 leader 确认以及所有副本都确认，第二种更加具有容错性），生产者可以重试，直到接收到成功提。
恰好一次 ：人们真正想要的是，每条消息只传递一次，也只有一次,目前在 producer 端还不能保证精确一次，在未来有可能实现，实现方式如下：在同步确认的基础上为每一条消息加一个主键，如果发现主键曾经接受过，则丢弃

4.1.2：消费者语义

最终其实是消息的消费和偏移量的提交之间的均衡选择。

最多一次：先提交偏移量后消费
至少一次：先消费后提交偏移量
恰好一次：保存了offset后提交一次，消息处理成功之后再提交一次。还有一个方法，将处理后的结果和offset同时保存在HDFS中，这样就能保证消息和offser同时被处理了。

4.2：偏移量迁移：zk和kafka

offsets.storage：偏移量的保存位置，zookeeper还是kafka,0.10版本后建议kafka

较早版本中的Kafka使用者默认将其偏移量存储在ZooKeeper中。
通过执行以下步骤，可以迁移这些使用者以将偏移量提交到Kafka中：
zk到kafka:
在用户配置中设置offsets.storage=kafka和dual.commit.enabled=true。
对您的消费者进行滚动反弹，然后确认您的消费者健康。
dual.commit.enabled=false在使用者配置中设置。
对您的消费者进行滚动反弹，然后确认您的消费者健康。

Kafka迁移回ZooKeeper:
offsets.storage=zookeeper。

4.3：zookeeper目录设计

4.3.1：代理节点(服务器)注册

临时节点

/brokers/ids/[0...N]

代理节点通过在/ brokers / ids下创建一个逻辑代理id为znode来注册自己

4.3.2：topic主题注册

（临时节点）

/brokers/topics/[topic]/partitions/[0...N]/state-> {“ controller_epoch”：...，“ leader”：...，“ version”：...，“ leader_epoch “：...，” isr“：[...]}

4.3.3：消费者注册

（临时节点）

/consumers/[group_id]/ids/[consumer_id] --> {"version":...,"subscription":{...:...},"pattern":...,"timestamp":...}

4.3.3：消费者偏移量注册

（持久节点）

/ consumers / [group_id] / offsets / [topic] / [partition_id]-> offset_counter_value

4.3.4：分区所有者注册：owners

（临时节点）

/ consumers / [group_id] / owners / [topic] / [partition_id]-> Consumer_node_id

5：kafka的集群shell操作

kafka的shell操作

6：集群运行

可使用集群管理工具mirrormaker进行数据迁移等。

6.1：消费者群组管理

6.1.1：检查消费者位置

1：先查看消费者群组名称

bin/kafka-consumer-groups.sh --zookeeper localhost:2181 --list

2：再使用查看出来的消费者群组检查消费位置

0.10版本以前
bin/kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --zookeeper localhost:2181 --group test
0.10版本以后：
kafka.admin.ConsumerGroupCommand（或bin / kafka-consumer-groups.sh脚本）来管理使用者组
bin/kafka-consumer-groups.sh --zookeeper localhost:2181 --describe --group test-consumer-group

6.2：kafka集群间的数据镜像

这种镜像的常见用例是在另一个数据中心中提供副本
这是一个示例，显示了如何从两个输入集群中镜像单个主题（名为my-topic）：

> bin/kafka-mirror-maker.sh
       --consumer.config consumer-1.properties --consumer.config consumer-2.properties
       --producer.config producer.properties --whitelist my-topic

我们使用–whitelist选项指定主题列表。此选项允许使用Java风格的正则表达式的任何正则表达式，如：–whitelist “*”

6.3：集群扩容

6.3.1：添加服务器

将服务器添加到Kafka集群很容易，只需为其分配唯一的代理ID，然后在新服务器上启动Kafka。但是，不会为这些新服务器自动分配任何数据分区，因此，除非将分区移至它们，否则在创建新主题之前它们将不会做任何工作。因此，通常在将计算机添加到群集时，您将需要将一些现有数据迁移到这些计算机

6.3.2：数据迁移（重分区）

服务器间的分区数据迁移，保证负载均衡。
1：使用
分区重新分配工具可用于将某些主题从当前代理集移到新添加的代理。
以下示例将主题foo1，foo2的所有分区移动到新的集群服务器5,6。在此步骤结束时，主题foo1和foo2的所有分区仅存在于服务器5,6上
该工具将主题的输入列表作为json文件接受
2：准备迁移主题的json文件

vi topics-to-move.json
{"topics": [{"topic": "foo1"},
            {"topic": "foo2"}],
 "version":1
}

3:使用分区重新分配工具生成候选分配
新的分配配置应保存在json文件（例如，expand-cluster-reassignment.json，只要是json文件即可，命名没有规定）
执行重分配：5/6为kafka配置的id

> 该命令会打印tipic partition的原始分布情况，以及重生的分布情况。见下图。
> bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --topics-to-move-json-file topics-to-move.json --broker-list "5,6" --generate

执行结果

当前分区副本分配

{"version":1,
 "partitions":[{"topic":"foo1","partition":2,"replicas":[1,2]},
               {"topic":"foo1","partition":0,"replicas":[3,4]},
               {"topic":"foo2","partition":2,"replicas":[1,2]},
               {"topic":"foo2","partition":0,"replicas":[3,4]},
               {"topic":"foo1","partition":1,"replicas":[2,3]},
               {"topic":"foo2","partition":1,"replicas":[2,3]}]
}

Proposed partition reassignment configuration(建议的分区重新分配配置)
新的分配配置应保存在json文件（例如，expand-cluster-reassignment.json，只要是json文件即可，命名没有规定）
复制以下内容保存到json文件中

{"version":1,
 "partitions":[{"topic":"foo1","partition":2,"replicas":[5,6]},
               {"topic":"foo1","partition":0,"replicas":[5,6]},
               {"topic":"foo2","partition":2,"replicas":[5,6]},
               {"topic":"foo2","partition":0,"replicas":[5,6]},
               {"topic":"foo1","partition":1,"replicas":[5,6]},
               {"topic":"foo2","partition":1,"replicas":[5,6]}]
}

4：根据新的json文件执行重分布
此处的json即为3步骤中保存的json文件

bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file expand-cluster-reassignment.json --execute

5：检查重分布的执行状态
会显示各分区的重分布执行状态。

bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file expand-cluster-reassignment.json --verify

6.4：增加topic的副本数

此步骤看需求是否需要
只需在自定义重新分配json文件中指定额外的副本，然后将其与–execute选项一起使用即可增加指定分区的复制因子。

示例:
将主题foo的分区0的复制因子从1增加到3。在增加复制因子之前，该分区的唯一副本存在于代理5上。作为增加复制因子的一部分，我们将放在服务器6和7。
1：第一步是在json文件中手动制作自定义重新分配计划：

vi increase-replication-factor.json
{"version":1,
 "partitions":[{"topic":"foo","partition":0,"replicas":[5,6,7]}]}

2：执行：execute

 bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file increase-replication-factor.json --execute

3：查看执行状态：verify

bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file increase-replication-factor.json --verify

4：查看现在topic的详细状态
bin / kafka-topics.sh --zookeeper localhost：2181 --topic foo --describe

7：kafka的服务器配置

7.1：服务器配置

一个实例的服务器配置示例

＃复制配置
num.replica.fetchers = 4
copy.fetch.max.bytes = 1048576
copy.fetch.wait.max.ms = 500
复制副本.high.watermark.checkpoint.interval.ms = 5000
copy.socket.timeout.ms = 30000
copy.socket.receive.buffer.bytes = 65536
copy.lag.time.max.ms = 10000

controller.socket.timeout.ms = 30000
controller.message.queue.size = 10

＃日志配置
num.partitions = 8
message.max.bytes = 1000000
auto.create.topics.enable = true
log.index.interval.bytes = 4096
log.index.size.max.bytes = 10485760
log.retention.hours = 168
log.flush.interval.ms = 10000
log.flush.interval.messages = 20000
log.flush.scheduler.interval.ms = 2000
log.roll.hours = 168
log.retention.check.interval.ms = 300000
log.segment.bytes = 1073741824

＃ZK配置
zookeeper.connection.timeout.ms = 6000
zookeeper.sync.time.ms = 2000

＃套接字服务器配置
num.io.threads = 8
num.network.threads = 8
socket.request.max.bytes = 104857600
socket.receive.buffer.bytes = 1048576
socket.send.buffer.bytes = 1048576
queued.max.requests = 16
fetch.purgatory.purge.interval.requests = 100
producer.purgatory.purge.interval.requests = 100

7.2：服务器硬件

内存：缓存大小*30s
硬盘：通常，磁盘吞吐量是性能瓶颈，并且磁盘越多越好

内存使用率查看：cat / proc / meminfo

7.3:zookeeper

当前稳定分支为3.4，该分支的最新版本为3.4.6，这是ZkClient 0.7使用的分支。ZkClient是Kafka用于与ZooKeeper交互的客户端层。