kafka(一)

分布式流处理平台Kafka

• 高吞吐，低延时，O(1)的时间复杂度，用于实时事件响应的场景。
• 分布式，副本备份，有容错的集群。
• 扩展性强支持队列和发布订阅模式

Kafka的架构

Producer即生产者将消息发往kafka实例(kafka Broker)的一个topic，如果topic配置了副本则kafka会将信息同步到Follower中，Leader负责与producer和consumer交互，而follower只负责从leader同步数据。一个topic的某一个分区能被多个分组消费，但是每个分组内只能有一个成员消费它。相当于每个组是一个逻辑上的消费者。

Kafka的生产过程

写入方式

producer采用推模式发布到broker，每条消息都被追加到某个分区中，是顺序的。

topic的分区结构

可以看到写入时，消息被分配到某个分区中，每个Partition中的消息都是有序的，生产的消息不断追加到Partition log上,其中的每一个消息都被赋予了一个唯一的offset值。

分区原因:

• 横向扩展能力

• 提高并发

分区的原则

• 指定了patition，则直接使用。
• 未指定patition但指定key,通过对key的value进行hash选择一个patition。
• patition和key都未指定，使用轮询选择出一个patition。

使用命令发布消息

kafa集群环境:broker0 9092; broker1 9093;broker2 9094

发布一个消息到topic中,此topic有三个副本，只有一个分区，且leader为broker1。

> bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-replicated-topic
...
my test message 1
my test message 2
^C

可以看到发布到my-replicated-topic的消息没指定分区，所以用到的上面第三种方式，轮询一个patition作为使用，然后该topic只有一个分区，该分区的leader为borker1。上面是对localhost:9092进行发布，即broker0，无需指定为broker1的9093。原理:对着任意一个broker发送，都会向zooKeeper找到patition的leader所在的broker，最终是向leader发送请求。流程如下:

Broker保存数据

存储方式

每个patition对应一个文件夹，文件夹内记录了该patition的信息。

存储策略

无论是否消费，消息还是存储着，根据下面两个参数进行删除。

• 基于时间: log.retention.hours=168
• 基于大小: log.retention.bytes=1073741824

消费数据

消费者组

消费者是以consumer group消费组方式进行工作的，由一个或多个消费者组成一个组，共同消费一个topic。每个分区在同一时间只能由group中的一个消费者读取，但是多个group可以同时消费这个patition。如果某消费者宕机，那么该消费者所在组的其它消费者会自动负载读取之前失败的消费者读取的分区。

消费方式

消费者采用pull方式从broker拉数据，可以更好地适应自身的处理速度去消费。唯一不足的是，kafka没数据会造成空循环，解决这个问题通过在pull API中设置一个时间参数，拉不到就阻塞进行缓解。

使用命令行消费数据

> bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic my-replicated-topic
...
my test message 1
my test message 2
^C

同样，无需指定主题分区所在broker。–from-beginning即从offset开始消费。使用高级消费者API无需管理分区的broker及offset。

使用api无需关心往哪个broker，哪个patition发送或消费，kafka自带一些策略(range和roundrobin)，使得消费者能均匀地持有patition。同一个主题，他们的意义应该是相同的，任何一个消费者拿到消息都是做相同处理。如果需要指定分区，也是可以的。