小白学习Kafka(二):主题策略
分区
Kafka 的消息组织方 式实际上是三级结构:主题 - 分区 - 消息
问题一:为什么 Kafka 要做这样的设计?为什么使用分区的概念而不是直接使用多个主题呢?
- 分区的目的是:提供负载均衡,实现系统的高伸缩性【Scalability】
- 每条消息 只会 保存在某一个分区中。
- 不同的分区可以放在不同机器上;
- 数据的读写都是基于 分区 这个粒度;
生产者 分区策略
分区策略是决 定生产者将消息发送到哪个分区的算法
轮询策略
Round-robin 策略,即顺序分配,kafka默认分区策略。
随机策略
Randomness 策略, 随机的将消息放置到任意一个分区上。
按消息键保序策略
根据业务指定合适的key进行分区。
生产者 压缩
Producer 发送压缩消 息到 Broker 后,Broker 照单全收并原样保存起来。当 Consumer 程序请求这部分消息 时,Broker 依然原样发送出去,当消息到达 Consumer 端后,由 Consumer 自行解压缩 还原成之前的消息。
Producer 端压缩、Broker 端保持、Consumer 端解压缩。
问题一:Producer、Broker压缩算法不一致
- Producer压缩一遍
- Broker解压,再压缩一遍。
但如果配置一致,则broker保持就好了。
问题二:版本不同,Broker端发生消息格式转化
消息格式转换主要是为了兼容老版本的消费者程序
- Broker解压,再压缩一遍, 从而支持老版本
- 丧失Zero Copy的特性,
Zero Copy”就是“零拷贝
当数据在磁盘和网 络进行传输时避免昂贵的内核态数据拷贝,从而实现快速的数据传输
压缩算法
压缩算法的指标
- 压缩比,原先占 100 份空 间的东西经压缩之后变成了占 20 份空间,那么压缩比就是 5,显然压缩比越高越好
- 压缩 / 解压缩吞吐量,比如每秒能压缩或解压缩多少 MB 的数据。同样地,吞 吐量也是越高越好。
在 Kafka 2.1.0 版本之前,Kafka 支持 3 种压缩算法:GZIP、Snappy 和 LZ4。从 2.1.0 开 始,Kafka 正式支持 Zstandard 算法(简写为 zstd)。它是 Facebook 开源的一个压缩算 法,能够提供超高的压缩比(compression ratio)。
最佳实践
CPU允许的情况下,开启压缩zstd,进而也可以节省带宽。
避免消息丢失
如何配置 Kafka 无消息丢失?
对一个问题的回答,先要确认问题是什么,概念的边界
Kafka 的世界里什么 才算是消息丢失,或者说 Kafka 在什么情况下能保证消息不丢失。这点非常关键,因为很多时候我们容易混淆责任的边界,如果搞不清楚事情由谁负责,自然也就不知道由谁来出解决方案了。
Kafka 只对“已提交”的消息(committed message)做有限度的持久化 保证。
- 已提交:只有broker确认收到才算是已提交;
- 有限度:凡事有例外,如果broker全部出现问题等。
生产者
问题: 生产者发送了消息,但是Kafka没有收到
回答问题可以: 概念+原因,概念是为了做铺垫,让原因更直白
- Kafka Producer 是异步发送消息的,也就是说如果你调用的是 producer.send(msg) 这个 API,那么它通常会立即返回,但此时你不能认为消息发送已成功完成。。 “fire and forget”,翻译一下就是“发射后不管“;
- 造成丢失的原因不限于:网络抖动、格式不符合broker<消息过大>等;
- 采用 回调+重试的方式,producer.send(msg, callback)
消费者
问题:消费者程序丢失数据
- 问题定位:消费者要消费的数据不见了。
- 涉及的概念:Consumer 程序有 个“位移”的概念,表示的是这个 Consumer 当前消费到的 Topic 分区的位置。
位移可以类比读书的书签,正常来说,你这次读到100页,下次继续读完全没有问题,问题是:你本计划读到100页,就把书签放到100的位置,实际上读到90页就跑出去完了,下次直接从100页开始,其中就少读了10页。
解决的方法类似与生产者,维持先消费消息(阅读),再更新位移(书签)的顺序
最佳实践
Producer参数
- 使用 producer.send(msg, callback)。
- 设置 acks = all。表明所有副本 Broker 都要接收到消息,该消息才算是“已提交”。 这是最高等级的“已提交”定义。可能对某些业务有点浪费
- retries 为一个较大的值。重试次数;
Broker 端的参数
- unclean.leader.election.enable = false: 控制的是哪 些 Broker 有资格竞选分区的 Leader。如果一个 Broker 落后原先的 Leader 太多,那么 它一旦成为新的 Leader,必然会造成消息的丢失。故一般都要将该参数设置成 false, 即不允许这种情况的发生。
- replication.factor >= 3: 最好将 消息多保存几份,毕竟目前防止消息丢失的主要机制就是冗余。
- min.insync.replicas > 1: 控制的是消息至少要被写入到多少个副本才算是“已提交”。设置成大于 1 可以提升消息持久性。在实际环境中千万不要使用默认值 1。
确保 replication.factor > min.insync.replicas;
推荐设置成 replication.factor = min.insync.replicas + 1。
如果两者相等,那么只要有一个副本挂 机,整个分区就无法正常工作了。我们不仅要改善消息的持久性,防止数据丢失,还要 在不降低可用性的基础上完成
参考
极客时间—Kafka核心技术与实战
胡夕 - 博客园 –《Apache Kafka实战》