kafka基本概念快速入门_随笔

kafka基本概念快速入门

今天项目中用到了kafka做用户行为的数据埋点，重新熟悉了一下kafka

1. 消息中间件对比

2. kafka是一个高性能跨语言分布式发布/订阅消息队列系统 2.1.1 kafka基本结构

producer：发布消息的对象称之为主题生产者（Kafka topic producer）
topic：Kafka将消息分门别类，每一类的消息称之为一个主题（Topic）
consumer：订阅消息并处理发布的消息的对象称之为主题消费者（consumers）
broker：已发布的消息保存在一组服务器中，称之为Kafka集群。集群中的每一个服务器都是一个代理（Broker）。消费者可以订阅一个或多个主题（topic），并从Broker拉数据，从而消费这些已发布的消息。

2.1.2 kafka高可用设计

集群

备份机制

Kafka 中消息的备份又叫做副本（Replica）
Kafka 定义了两类副本：
- 领导者副本（Leader Replica）
- 追随者副本（Follower Replica）（分为isr和普通)
  - ISR的follower是同步保存领导者数据
  - 普通的follower是异步
leader失效后选举原则
- 第一：选举时优先从ISR中选为这个列表中follower的数据是与leader同步的
- 第二：如果ISR列表中的follower都不行了，就只能从其他follower中选取
- 极端情况，就是所有副本都失效了，这时有两种方案
  - 第一：等待ISR中的一个活过来，选为Leader，数据可靠，但活过来的时间不确定
  - 第二：选择第一个活过来的Replication，不一定是ISR中的，选为leader，以最快速度恢复可用性，但数据不一定完整

3. 生产者 3.1 发送消息类型

3.2 ack消息确认机制

3.3 retries重试机制

重试次数prop.put(ProducerConfig.RETRIES_CONFIG,10);
生产者从服务器收到的错误有可能是临时性错误，在这种情况下，retries参数的值决定了生产者可以重发消息的次数，如果达到这个次数，生产者会放弃重试返回错误，默认情况下，生产者会在每次重试之间等待100ms

3.4 消息压缩

默认情况下，消息发送时不会被压缩。 prop.put(ProducerConfig.COMPRESSION_TYPE_CONFIG,"lz4");
压缩算法
- snappy：占用较少的 CPU，却能提供较好的性能和相当可观的压缩比，如果看重性能和网络带宽，建议采用
- lz4：占用较少的 CPU，压缩和解压缩速度较快，压缩比也很客观
- gzip：占用较多的 CPU，但会提供更高的压缩比，网络带宽有限，可以使用这种算法

4. 消费者 4.1 消费组

消费者组（Consumer Group）：指的就是由一个或多个消费者组成的群体
一个发布在Topic上消息被分发给此消费者组中的一个消费者
- 所有的消费者都在一个组中，那么这就变成了queue模型
- 所有的消费者都在不同的组中，那么就完全变成了发布-订阅模型

4.2 消息有序性

topic分区中消息只能由消费者组中的唯一一个消费者处理，所以消息肯定是按照先后顺序进行处理的。但是它也仅仅是保证Topic的一个分区顺序处理，不能保证跨分区的消息先后处理顺序。所以，如果你想要顺序的处理Topic的所有消息，那就只提供一个分区。

4.3 提交偏移量

如果有消费者发生崩溃，或者有新的消费者加入消费者群组的时候，会触发 Kafka 的再均衡。这使得 Kafka 完成再均衡之后，每个消费者可能被会分到新分区中。为了能够继续之前的工作，消费者就需要读取每一个分区的最后一次提交的偏移量，然后从偏移量指定的地方继续处理。
- 如果提交的偏移量小于客户端处理的最后一个消息的偏移量，那么处于两个偏移量之间的消息就会被重复处理。
- 如果提交的偏移量大于客户端处理的最后一个消息的偏移量，那么处于两个偏移量之间的消息将会丢失。
自动提交
- 当 enable.auto.commit 属性被设为 true，那么每过 5s，消费者会自动把从 poll()方法接收到的最大偏移量提交上去。
- 容易出现提交的偏移量小于客户端处理的最后一个消息的偏移量这种情况的问题
手动提交
- 大部分开发者通过控制偏移量提交时间来消除丢失消息的可能性，并在发生再均衡时减少重复消息的数量。
一般采用同步和异步混合提交
- 能解决异步提交失败不会进行重试的缺点

欢迎分享，转载请注明来源：内存溢出

kafka基本概念快速入门