几个概念

* partion: 从逻辑上来看是一个无限长的数组，可以一直往后顺序添加，物理层面可以看作一个个的文件夹，一个patition对应着一个文件夹，一台物理机器可以分配多个partition，多个partition可以分布在不同的机器上，实现了水平扩容。而partition之间会相互作为备份，备份很机智很有意思，待会好好看看。

* topic: 逻辑概念。用于消息分类。

* server: kafka服务。分布式的server，组成了kafka的集群

核心api

Producer: 一串流式数据可以发送到一个或者多个topic。

Consumer: 一个应用程序可以订阅一个或者多个topic

Steams: 厉害了，可以接受一个或者多个topic作为输入，处理完成以后再输出到一个或者多个topic里，也就是对数据做了一个中间处理。

The Connector API: 使用其他来源的数据或将数据从Kafka导出到其他系统。针对这些系统， 可以使用Kafka Connect来导入或导出数据，而不是写自定义的集成代码。

group 消费者与paritition

如果所有的消费者实例在同一消费组中，消息记录会负载平衡到每一个消费者实例.

如果所有的消费者实例在不同的消费组中，每条消息记录会广播到所有的消费者进程

部分实例在相同的消费组，部分实例在不同的消费组.同一消费组的实例共同消费topic内的消息。不同组之间能够消费的总数据相同，并且消费相互不受影响。

Q: 当group新增加了一个消费者的时候，之前被消费过的数据是不会再次被消费么?

A: group新增消费者的时候，设置offset的话，就继续从offset以后开始消费，没有设置只会消费新增以后的收到的消息。同时新增消费者，zookeeper会重新进行分区分配，会立即平衡分区给新加入的消费者。

server vs group vs consumer

(⌯˃̶᷄ꇴ˂̶᷄⌯)

备份机制（同步机制）

同步是为了容错，当机器宕机时，能够从备份的数据中恢复可能丢失的数据。

据我了解，kafka基于leader/follower模式完成同步。每个分区都会有零到N个备份，分区是基本的备份单位，只有主分区进行数据的读写，在收到数据后，当所有的in sync状态的备份被写入 数据提交成功。当leader 宕机，从in sync状态的follower中选取一个作为新的leader。当in sync状态的follower 与zookeeper心跳缺失，或者没有及时同步leader的数据，则会从in sync的组中剔除。状态记录在zookeeper端

connector 小试

kafka ⍉ ➜ bin/connect-standalone.sh config/connect-standalone.properties config/connect-file-source.properties config/connect-file-sink.properties

启动connector 和 source（数据导入节点）、sink（数据导出节点）

这里是直接将一个文本的内容通过kafka转移到另外的文本里。

具体步骤是：

1. 写个source配置

```

name=local-file-source

connector.class=FileStreamSource

tasks.max=1

file=test.txt

topic=connect-test

```

2.写个topic 的处理逻辑

3.再写个sink的配置，和source基本相同。就不贴了。

es connector     hbase connector