Kafka学习笔记-- 1 入门知识和使用场景_producerrecord 重用-CSDN博客

主流mq组件对比
	ActiveMQ	RabbitMQ	Kafka
吞吐量	1w	1w	10w
支持的协议	OpenMessage, AMQP, MQTT， STOMP	AMQP	仿AMQP
事务	支持	支持	支持
集群	支持（不良好）	支持（不良好）	支持
负载均衡	支持	支持	支持
动态扩展	不支持	不支持	支持
编写语言	Java	Erlang	Scala

这三个MQ组件中， ActiveMQ的功能最丰富，支持的协议最多。吞吐量上，一般情况下Kafka > RabbitMQ > ActiveMQ; 可靠性上，一般情况下RabbitMQ > ActiveMQ > Kafka。

动态扩展，是指可以向运行中的集群添加新的节点，而不影响已有节点的使用。之所以说ActiveMQ对集群的支持不良好，其中一个原因是 ActiveMQ的节点只能是主从模式，只有再master节点上才可以发布和消费消息，这样的话对并发量的提升相对较弱。

1.2 kafka主要特性

消息系统: 可以发布和订阅消息，类似于消息队列或企业级消息系统。

存储: 提供容错的方式来存储流数据。存储在kafka中的数据，都会落到磁盘上，只要不手动删除，将一直存在，不像其他消息中间件，当消息消费后，会对消息进行删除。

流处理: 可以在一个流的数据产生时，就对它进行处理，即流处理。这个特性是kafka的streams api来支持的，需要在客户端上编码，实质上是读取现有的流数据，将处理的结果推到结果的流上。但主流的还是采用fink, storm sreams, spark等批处理框架来进行流处理。 kafka更多的是充当一个流数据的存储角色。

总的来说， Kafka不仅仅是一个消息系统，还是一个数据存储。

1.3 AMQP协议

AMQP是由金融业的摩根大通公司主导制定的消息协议，是一个应用层的协议。

AMQP简单示例

在Kafka中，生产者push，消费者poll，都是客户端主动发起数据请求。kafka都是以多个broker集群的方式对外提供服务。

1.4 Kafka整体架构

1.5 核心概念

broker

一个Kafka示例，一般情况下， Kafka都是以集群的方式部署的。

topic

消息的一种分类，一个主题的消息可以视为一个数据流。主题中的消息不一定按照发布的顺序消费。

partition

一个主题可以分为多个partition，每一个partition都是顺序存储在磁盘的。每个partition的消息有自己的id, 对于消费者， partion有自己对应的commit offset。partition的意义：其一，如果通过将一个主题分隔成多个partition，部署到多个broker上来提升io的速度，甚至通过这种方式，获得和内存相近的吞吐量；其二， partition可以分布在多个broker上，可以避免一次性丢失所有数据的情况。

partition中的消息是会按照发布的顺序消费的。

record

每条记录都有key， value和timestamp三个数据。其中具有相同key的消息，可以保证落到同一个partition中。

replication

每一个partition可以有多个副本，副本分布在不同的broker上，通过这种冗余，可以保证数据的安全性，只要不是所有的副本都丢失，那么partition中的数据就是安全的。副本的数量（replication-factor)不能超过broker的数量，因为将同样的副本存在同一台机器上，对于数据安全性，没有作用。

replication有一下的特性：

同一个partition的多个replication不允许在同一个broker中；（在配置中， replication-factor不能超过broker的数量）
同一个parition的多个replication中，有一个leader， 0个或多个follower；
消息的读写只能发生在leader节点上， follower只是被动的复制；
当leader节点宕机时，集群会选举出新的leader节点；

注意：这里的leader和follower是replication级别的， Kafka的broker节点之间没有主次之分，它们是完全同等的。

1.6 kafaka 核心API

概述

producer，向topic发布消息的应用。
consumer，从broker中接收消息，进行处理的应用。
streams api，一个流处理的api，从一个或多个主题接收消息，进行处理后，将处理结果放到一个或多个主题中。
connector，可重用的producer或consumer。用于将已有系统，如数据库等的数据集成到kafka上。

这四种API，用来构建四种类型的Kafka客户端，如下：

producer

使用代码示例：

// 设置producer的配置
Properties settings = new Properties();
settings.put("batch.size", 16 * 1024); // 缓冲区大小, 默认16k
settings.put("linger.ms", 1000); // 发送前， 等待的时间， 默认为0
settings.put("acks", "all"); // 多少个broker 确认才认为成功。 0， 
settings.put("retries", 1 ); // 重试的次数

....

Producer<String, String> producer = new KafkaProducer(settings);
// 发送消息
ProducerRecord<String, String> record = new ProducerRecord<>("my-topic", "key", "value");
producer.send(record);

producer.close();

producer发送消息时，并不是直接发送到broker中的，而是先放在本地内存中的一个缓冲区，当缓冲区大小达到最大大小或缓冲区中的消息达到停留时间时，才进行发送。如下：

producer有三个重要的配置：

batch.size：缓冲区大小, 默认16k
linger.ms：发送前，等待的时间，默认为0
acks：多少个broker 确认才认为消息发布成功，可选值为0， 1， all。 0，是发送之后就认为是成功了，不去考虑这个消息是否交付到kafka中； 1，当leader节点确认成功，就认为已经成功的交付到kafka中了，这种情况下，如果leader节点宕机，而又没有来得即将消息同步到follower上，那么就会出现消息丢失； all，只有当所有的broker都ack之后，才认为一个消息发送成功。

一旦达到batch.size或linger.ms其中一个条件，缓冲区的消息就会被立刻发送。