kafka的使用

参考文章

[参考文章](https://www.cnblogs.com/yangms/p/14445307.html)
[参考文章](https://www.cnblogs.com/juniorMa/articles/13936154.html)

关键字

Topics（主题）:每条发布到Kafka集群的消息都有一个类别，这个类别被称为topic。（物理上不同topic的消息分开存储，逻辑上一个topic的消息虽然保存于一个或多个broker上但用户只需指定消息的topic即可生产或消费数据而不必关心数据存于何处）
Partition（分区）:parition是物理上的概念，每个topic包含一个或多个partition，创建topic时可指定parition数量。每个partition对应于一个文件夹，该文件夹下存储该partition的数据和索引文件
Partition offset（分区偏移）:每个分区消息具有称为 offset 的唯一序列标识。
Replicas of partition（分区备份）:副本只是一个分区的备份。 副本从不读取或写入数据。 它们用于防止数据丢失。
Broker:Kafka集群包含一个或多个服务器，这种服务器被称为broker
Brokers（经纪人）:代理是负责维护发布数据的简单系统。 每个代理中的每个主题可以具有零个或多个分区。 假设，如果在一个主题和N个代理中有N个分区，每个代理将有一个分区。假设在一个主题中有N个分区并且多于N个代理(n + m)，则第一个N代理将具有一个分区，并且下一个M代理将不具有用于该特定主题的任何分区。假设在一个主题中有N个分区并且小于N个代理(n-m)，每个代理将在它们之间具有一个或多个分区共享。 由于代理之间的负载分布不相等，不推荐使用此方案。
Kafka Cluster（Kafka集群）:Kafka有多个代理被称为Kafka集群。 可以扩展Kafka集群，无需停机。 这些集群用于管理消息数据的持久性和复制。
Producers（生产者）:生产者是发送给一个或多个Kafka主题的消息的发布者。 生产者向Kafka经纪人发送数据。 每当生产者将消息发布给代理时，代理只需将消息附加到最后一个段文件。 实际上，该消息将被附加到分区。 生产者还可以向他们选择的分区发送消息。
Consumers（消费者）:消费消息。每个consumer属于一个特定的consumer group（可为每个consumer指定group name，若不指定group name则属于默认的group）。使用consumer high level API时，同一topic的一条消息只能被同一个consumer group内的一个consumer消费，但多个consumer group可同时消费这一消息。
Consumer Group(消费者组):是逻辑上的概念，是Kafka实现单播和广播两种消息模型的手段。同一个topic的数据，会广播给不同的group；同一个group中的worker，只有一个worker能拿到这个数据。换句话说，对于同一个topic，每个group都可以拿到同样的所有数据，但是数据进入group后只能被其中的一个worker消费。group内的worker可以使用多线程或多进程来实现，也可以将进程分散在多台机器上，worker的数量通常不超过partition的数量，且二者最好保持整数倍关系，因为Kafka在设计时假定了一个partition只能被一个worker消费（同一group内）。简单的理解就是，实现了队列的方式。同一个groupid 的 consumer 属于一个队列方式，消费了就完事了
Leader（领导者）: Leader 是负责给定分区的所有读取和写入的节点。 每个分区都有一个服务器充当Leader.
Follower（追随者）:跟随领导者指令的节点被称为Follower。 如果领导失败，一个追随者将自动成为新的领导者。 跟随者作为正常消费者，拉取消息并更新其自己的数据存储。

Kafka的特性:

可靠性：Kafka是分布式，分区，复制和容错的。
可扩展性：Kafka消息传递系统轻松缩放，无需停机。
耐用性/持久性：Kafka使用分布式提交日志，这意味着消息会尽可能快地保留在磁盘上，因此它是持久的。
性能：Kafka对于发布和订阅消息都具有高吞吐量。 即使存储了许多TB的消息，它也保持稳定的性能。
高并发：支持数千个客户端同时读写

使用场景:

指标:Kafka通常用于操作监控数据。 这涉及聚合来自分布式应用程序的统计信息，以产生操作数据的集中馈送。
运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
日志聚合解决方案:Kafka可用于跨组织从多个服务收集日志，并使它们以标准格式提供给多个服务器。
消息系统：解耦和生产者和消费者、缓存消息等。
流处理:流行的框架(如Storm和Spark Streaming)从主题中读取数据，对其进行处理，并将处理后的数据写入新主题，供用户和应用程序使用。 Kafka的强耐久性在流处理的上下文中也非常有用。

鉴权

https://wiki.ksord.com/pages/viewpage.action?pageId=101318760
kafka-configs.sh --zookeeper localhost:52181 --alter --add-config 'SCRAM-SHA-256=[password=feature],SCRAM-SHA-512=[password=feature]' --entity-type users --entity-name c.feature
其他机器可访问需要配置成内网ip 不可配置为localhost

配置参数

max.poll.interval.ms  指定consumer两次poll的最大时间间隔（默认5分钟）

重复消费

重复消费

producer参数

1. acks
	1. acks=0 生产者在成功写入消息之前不会等待任何来自服务器的响应  at-most-once（可能少读）
	2. acks=1 集群的leader分区副本接收到了消息 返回ack 可能重复读
	3. acks=all 所有参与复制的节点(ISR列表的副本)全部收到消息时，生产者才会接收到来自服务器的响应 可能重复读
	4. 幂等解决重复读问题
2. retries
生产者可以重发消息的次数，如果达到这个次数，生产者会放弃重试并返回错误 (Broker: Not enough in-sync replicas)
3. batch.size
可以使用配置使用linger.ms和batch.size  linger.ms是准备好发送批次之前的延迟时间，默认值为0。这意味着即使批次中只有1条消息，批次也会立即发送
4. linger.ms
生产者在发送批次之前等待更多消息加入批次的时间
5. buffer.memory
生产者内存缓冲区的大小 默认buffer.memory值为32MB
如果应用程序发送消息的速度超过发送到服务器的速度，会导致生产者空间不足。这个时候，send()方法调用要么被阻塞，要么抛出异常，取决于如何设置
6. max.block.ms 
该参数指定了在调用send()方法或使用partitionsFor()方法获取元数据时生产者的阻塞时间(抛出异常前的等待时间)
7. compression.type
这往往是向Kafka 发送消息的瓶颈所在
默认情况下，消息发送时不会被压缩。该参数可以设置为snappy 、gzip 或lz4 ，它指定了消息被发送给broker 之前使用哪一种压缩算也进行压缩
8. max.request.size
生产者客户端能发送消息的最大值，默认值为1048576B，1MB

log4j2 接 kafka

参考文章

消息堆积

1. poll每次最大量500条
2. 一个group多个consumer
3. 程序异常处理
4. 调整consumer的消费能力
5. 消息堆积实际案例