Kafka的可靠性分析

阅读以下内容你将了解到:
1.Kafka的副本中的可靠性剖析
2.Kafka为什么不支持读写分离？(包括读写分离带来的问题、主读主写的优势)
3.日志同步机制（Kafka的同步策略、其他同步策略的实现）
4.Kafka的可靠性分析（总体而言Kafka是如何保证可靠性的）

1.Kafka的副本中的可靠性剖析

1.Kafka的分布式和多副本的机制，以及ISR集合的伸缩，HW的实现
2.Leader Epoch的介入（leader副本与follower的同步过程）
Kafka水位(high watermark)与leader epoch的讨论

2.Kafka为什么不支持读写分离？

先看看读写分离会带来的问题：
1.数据一致性问题，主节点到从节点肯定会有一个延时窗口，由此便产生了数据一致性问题。
2.延时问题。类比Redis来说，其主从通过过程需经历(网络→主节点内存→网络→从节点内存),而Kafka会更加耗时，需经历(网络→主节点内存→主节点磁盘→网络→从节点内存→从节点磁盘)。对于敏感的应用而言，主写从读的功能并不太适用。

Kafka是否真的有必要读写分离？
主写从读可以均摊一定的负载，但是对于写压力大而读压力小的情况却难以起效。
而Kfka中却可以达到很大的负载均衡，而这是通过在主写主读的架构上实现的。

image.png

主写主读的优点：
1.简化代码逻辑，减少出错可能。
2.将负载粒度细化均摊，与主写从读相比，负载效能更好，且对用户可控。
3.没有延时的影响。
4.在副本稳定的情况下，不会出现数据不一致的情况。
深入理解Kafka的作者这么写道：从某种意义上来说，主写从读是由于涉及上的缺陷而形成的权宜之计。

3.日志同步机制

这里不限于Kafka，而是泛泛而言，在分布式系统中，日志同步机制既需要保证数据一致性，还要保证数据的顺序性。最简洁的应该是从集群中选取leader来负责处理数据的写入顺序和同步。

日志同步机制的原则：如果告知客户端已经成功提交了某条消息，那么即时leader宕机，也要保证新选举出来的leader中能包含这条消息。
这里就出现一个需要权衡的地方，如果消息在提交前需要等待更多的follower确认，那么在宕机后就有更多的follower替代他，不过这种做法也会造成性能的下降-。
常见的权衡做法就是——“少数服从多数”，他可以用来负责提交决策和选举决策。（当然Kafka不是用的这种方法，但是你可以在ZooKeeper中看到他的身影）
“少数服从多数”的优势：系统的延迟取决于最快的几个节点
“少数服从多数”的劣势：为了保证leader选举的正常进行，他所能容忍的follower数就比较少，比如要容忍2个follower失败，就必须要5个副本，这种机制会在大量副本、大数据量的情况下造成性能的下降。这也是为什么常被用作共享集群配置（比如ZooKeeper）而很少用于主流数据存储中的原因。

简单看看Kafka中是怎么做的：
Kafka中动态维护着一个ISR集合，还有一个HW的概念，写入消息时只有等到所有ISR集合中的副本都确认收到了之后才能被认为已经提交（这里我们考虑的是akcs参数为-1的情况）。
采用这种ISR模型和(f+1)个副本数的情况下，我们最多可以容忍f个节点失败，而这种方式较于"少数服从多数的方式"所需的节点大幅减少。
举个栗子：
为了容忍1个节点失败，“少数服从多数”需要3个副本和1个follower的确认信息(还有一个是leader，下同)，ISR模型只需要2个副本和1个follower的确认信息。

4.Kafka的可靠性分析

1.越多的副本数越能够保证数据的可靠性，但是也会造成磁盘、网络带宽的浪费。
2.acks参数的配置，再来复习下，

-1表示生产者发送消息后，需要等待ISR集合所有副本都成功写入才能告知生产者已成功提交。
0表示不需要等待响应，只要发送就认为已经成功提交。
1表示只需要leader成功写入即可认为成功提交。

3.Kafka的重试机制，有些发送异常是可重试异常，比如NetworkException，这可能是网络波动引起的，一般通过重试即可解决。
4.这里考虑一下当ISR集合只有一个leader的情况，这种情况即时acks为-1也难以保证消息的可靠性。所以Kafka给我们提供另一个参数min.insync.replicas来指定ISR集合最小的副本数，如果不满足就会报错。
5.需要我们遵循一个原则：宁可重复消费也不应该让消息丢失。所以我们可以配置手动提交offset。
对于一直不能成功消费的消息，可以加入到死信队列做后续分析。
6.对于消费端，还提供了一个兜底的功能，即回溯消费，配合seek()函数使用，通过这个功能可以让我们能够有机会对漏掉的消息响应地进行补偿。