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

可靠性保证

保证：是指确保系统在不同环境下能够发生一致的行为
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个副本，并且禁用了不完全首领选举

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

发送确认

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

配置生产者重试参数

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

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

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

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

额外的错误处理

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

可靠的使用消费者

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

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

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

消费者可靠配置(4个)

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

注意事项

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