文章目录

可靠性保证
- Kafka做出的四个保证
- kafka可靠性保证的核心
- - kafka的复制机制
  - 不恰当的垃圾回收配置(**)
- broker配置
- - 复制系数1
  - 不完全的首领选举2
  - 最少同步副本3
- 可靠的使用生产者
- - 发送确认
  - 配置生产者重试参数
  - 额外的错误处理
- 可靠的使用消费者
- - 消费者可靠配置(4个)
  - 注意事项

可靠性保证

保证：是指确保系统在不同环境下能够发生一致的行为
ACID(原子性，一致性，隔离性，持久性)是关系型数据库普遍支持的标准可靠性保证

只有先了解了系统的保证机制，并基于这些保证机制开发安全可靠的应用程序。

Kafka做出的四个保证

a) 保证分区消息的顺序。生产者向同一个分区顺序生产消息，偏移量保证是顺序的，消费者消费也保证是顺序的
b) 当消息被写入分区所有同步副本时，它才被认为是"已提交的"，生产者可选择接受不同类型的确认
c) 消费者只能读取已提交的消息
d) 只要有一个副本是活跃的，那么消息就不会丢失
但仅仅依靠这些无法保证系统系统是完全可靠的，构建一个可靠的系统是需要做出一些权衡的。
系统的可靠性，一致性和可用性，吞吐量，延迟时间之间的权衡。

kafka可靠性保证的核心

kafka的复制机制和分区的多副本架构 是kafka可靠性保证的核心。

kafka的复制机制

kafka是通过主题来组织数据的，主题被分为多个分区进行存储，分区是最基本的数据块。分区存储在单个磁盘上，可以保证分区的消息有序性，每个分区可以有多个副本，其中一个副本是首领，其他是跟随着，生产者和消费者直接和首领进行交互，跟随着负责复制首领的数据保持数据同步，当首领不可用时，控制器选举新分区成为新首领。

不恰当的垃圾回收配置(**)

造成几秒钟的停顿，从而让broker与zk之间断开连接，最终导致一个或多个副本在同步和非同步状态之间进行频繁切换，滞后的同步副本会导致生产者和消费者变慢，因为客户端会等待所有副本接受到消息才可以进行消费。

broker配置

broker有3个配置影响kafka消息存储的可靠性。可在主题级别控制可靠性。

复制系数1

default.replication.factor //broker级别配置自动创建的主题
replication.factor //主题级别
更高的复制系数带来更高的可靠性，但会占用N倍的磁盘空间
如果broker重启导致的主题不可用是可接受的，就将复制系数设置为1。
如果可容忍一个broker失效，则将复制系数设置为2。

不完全的首领选举2

unclean.leader.election=true //在broker级别配置
完全的首领选举：只有同步的副本才能成为首领
首领不可用，其他副本都是不同步的怎么办？？？

不完全的首领选举可能会导致丢失数据or出现数据不一致的问题。否则必须接受较低的可用性，因为我们必须等待原首领恢复到可用状态

最少同步副本3

min.insync.replicas
虽然一个主题配置了3个副本，但还是会出现只有一个副本的情况。
消息只有被写入所有同步副本才被认为是可提交的，当只包含一个副本时，在这个副本不可用时，数据就会丢失。

可靠的使用生产者

例如：broker配置了3个副本，并且禁用了不完全首领选举

生产者将acks设为1，生产者发送消息给首领，首领成功写入然后响应，但跟随者副本没有接受到消息，最后首领奔溃了
另外两个副本被认为是同步的成为新首领，因为消息没有写入该副本，对于生产者来说它丢失了一个消息。
生产者将acks设为all，生产者发送消息给首领，首领奔溃返回首领不可用。此时客户端没有正确处理该错误，也没有进行重试，那么消息就可能丢失。
所以生产者可靠性要做两件事
a) 根据可靠性需求配置acks值
b) 代码里正确处理错误

发送确认

acks=0意味着生产者发送出去就认为消息已经成功写入kafka。运行速度快，但会丢失消息
acks=1意味着首领接受到消息并写入到分区文件后返回客户端确认or响应错误。若发生首领选举，会收到相应异常，若客户端重试发送消息，最终消息会安全到达新首领里。但是在消息成功写入首领后，跟随着复制消息前首领奔溃时，仍然会丢失数据
acks=all意味着意味着首领返回确认or响应错误之前，会阻塞等待所有副本都接受到消息。通常和min.insync.replicas参数结合起来使用。可通过使用异步模式，或者发送更大批次的消息来加快速度。

配置生产者重试参数

retries=次数
生产者需要处理的错误：1. 可重试错误 2. 手动处理的错误

重试可以保证每个消息"至少被保存一次"，但重试也会带来消息重复问题
例如
生产者由于网络问题没有收到broker确认而进行重试，但实际写入成功，重试后又写入成功。

解决重试带来的重复消费问题：

在消息中加唯一标识符，检测重复消息
进行“幂等处理”，保证即使出现重复，也不会影响最终“保存一次”的语义

额外的错误处理

根据不同的业务逻辑，进行不同的错误处理

可靠的使用消费者

只有被提交到kafka的数据，消费者才能消费到，保证了消费者具备一致性的特点。
消费者只需跟踪哪些消息已经读取过，哪些没有读取过，从而保证消息不丢失。

消费者提交了偏移量却未能处理完消息，造成消费者消息丢失的问题，所以我们必须重视偏移量提交的时间点和方式

已提交消息：写入所有分区副本的消息
已移交偏移量：消费者发送给kafka的偏移量，用于确认消费者已经消费消息的位置

消费者可靠配置(4个)

group.id 希望消费者读到所有消息，为消费者设置相同的goup.id
auto.offset.reset 在消费者没有偏移量可提交时or消费者提交的偏移量不存在时，消费者的动作earliest/latest
enable.auto.commit 自动/手动提交偏移量开关。自动提交无法控制重复消费，例如消费者在提交偏移量之前奔溃
自动提交可能导致消息丢失，例如异步消费时，在没有处理完消息时就提交偏移量
auto.commit.interval.ms 自动提价的时间间隔

注意事项

总是在处理完时间后再去提交偏移量在轮询间无需维护状态时才会使用自动提交
确保对提交的偏移量心中有数提交的偏移量有可能是读取到的最新偏移量，而不是处理的最新偏移量
通过写入缓冲区or写入独立主题，进行消费者重试在轮询中处理那些需要延后的消息
通过框架来解决消费者需要维护状态的问题
若消息被长时间处理，必须不断轮询保持心跳，避免再均衡。通过多线程并行处理
近义词语义实现若写入消息系统不支持事务，使用唯一键，幂等性写入
若写入消息系统支持事务，将提交偏移量和消息放在同一个事务中

《kafka权威指南》之可靠的数据传输相关推荐

kafka权威指南_Kafka-分区、片段、偏移量
[分区.片段.偏移量] 1. 每个分区是由多个Segment组成,当Kafka要写数据到一个partition时,它会写入到状态为active的segment中.如果该segment被写满,则一个新的 ...
送5本《Kafka权威指南》第二版
文末送书科学家们每一次发生分歧都是因为掌握的数据不够充分.所以,我们可以先就获取哪一类数据达成一致,只要获取了数据,问题也就迎刃而解了.要么我是对的,要么你是对的,要么我们都是错的,然后继续. -- ...
如何使用Kafka可靠地发送消息-《Kafka权威指南（第二版）》阅读笔记
可靠性是系统而不是某个独立组件的一个属性,所以,在讨论Kafka的可靠性保证时,需要从系统的整体出发.说到可靠性,那些与Kafka集成的系统与Kafka本身一样重要.正因为可靠性是系统层面的概念,所以 ...
《Kafka权威指南》记录
生产者生产流程 32页生产者创建 Kafka生产者需要三个必须参数:broker地址清单,key和value的序列化方式 (如StringSerializer) 生产者发送 ACKS acks 参 ...
【Kafka】《Kafka权威指南》入门
发布与订阅消息系统在正式讨论Apache Kafka (以下简称Kafka)之前,先来了解发布与订阅消息系统的概念, 并认识这个系统的重要性.数据(消息)的发送者(发布者)不会直接把消息发送给接收 ...
《Kafka权威指南（第二版）》内容摘要
下图包含前7章主要内容,主要是业务应用程序开发人员使用Kafka时需要掌握的知识点
《Kafka权威指南》读书笔记3 Kafka生产者
日常业务开发很重要.很常用的一章提纲:如何使用Kafka生产者:如何创建KafkaProducer.ProducerRecords:如何将记录发给Kafka:如何处理从Kafka返回的错误:一些配置 ...
《kafka权威指南》学习记录1
本博客只作为自己学习的一个记录. 一.kafka生产者 1.kafka生产者组件 main线程 send线程 producerrecord对象序列化器分区器. Producerrecord对象格式 ...
《Kafka权威指南》——问题1——onParitionsAssigned
四.Kafka消费者--从Kafka读取数据 4.8 从特定偏移量处开始处理数据 4.7节中说到,在调用subcribe()方法时传进去一个ConsumerRebalanceListener实例,可以 ...

《kafka权威指南》之可靠的数据传输