Kafka权威指南...

可靠的数据传输

1.1可靠性保证

类似与关系型数据库的ACID（原子性、一致性、隔离性、持久性）的原则，kafka对于数据的保证机制主要有下面几个方面：

1. kafka可以保证分区消息的顺序
2. 只有当消息被写入分区的所有同步副本时（不一定写入磁盘），他才会被认为是“已提交的”
3. 只要还有一个副本是活跃的，那么已经提交的消息就不会丢失
4. 消费者只能读取已经提交的消息

1.2复制

kafka的复制机制和分区的多副本架构是kefka可靠性保证的核心。
Kafka的主题被分为多个分区，分区是基本的数据块。分区存储在单个磁盘上，Kafka可以 保证分区里的事件是有序的，分区可以在线(可用)，也可以离线(不可用)。每个分区可以有多个副本，其中一个副本是首领。所有的事件都直接发送给首领副本，或者直接从首领副本读取事件。其他副本只需要与首领保持同步，并及时复制最新的事件。当首领副本不可用时，其中一个同步副本将成为新首领。
对于跟随者副本来说，他需要满足以下条件才能被认为是同步的：

1. 与zookeeper之间有个活跃的会话，也即是说，他在过去的6s（可配置）内向zookeeper发送心跳
2. 在过去的10s内（可配置）从首领哪里获取过消息
3. 再过去的10s内从首领哪里获取过最新的消息，光从首领哪里获取消息是不够的，还必须是无延迟的。

若果一个副本不在同步了，我们就不在关系他是否已经收到消息。但是更少的同步副本以为这更低的有效复制系数。

1.3broker配置

broker有三个配置参数会影响kafka消息存储的可能性。
在主题级别控制可靠性，意味着Kafka集群可以同时拥有可靠的主题和非可靠的主题。例如，在银行里，管理员可能把整个集群设置为可靠的，但把其中的一个主题设置为非可靠的，用于保存来自客户的投诉，因为这些消息是允许丢失的。

1.3.1复制系数

如果复制系数为N，那么N-1个broker失效的情况下，仍然能够从主题读取数据或者向主题写入数据。所以更高的复制系数会带来更高的可用性、可靠性和更少的故障，也会占据更对的磁盘空间。
若因broker重启导致的主题不可用是可以接受的，那么复制系数设置为1就可以了。复制系数为2，意味着可以容忍1个broker发生失效，
官方给出的建议是，要求可用性的场景下，将复制系数设置为3。
副本的分步也很重要，默认情况下，kafka会确保分区的每个副本被放在不同的broker上，并且为了保证安全，建议将broker分布在多个不同的机架上。

1.3.2不完全的首领选举

unclean.leader.election只能在broker级别进行配置，默认值为true。表示默认允许不同步的副本成为首领（不完全选举）
如果把unclean.leader.election设为true，那么我们将面临丢失消息的风险。如果把这个参数设为false, 就要等待原先的首领重新上线，从而降低了可用性。我们经常看到一些对数据质量和数据一致性要求较高的系统会禁用这种不完全的首领选举(把这个参数设为 false)。银行系统是这方面最好的例子，大部分银行系统宁愿选择在几分钟甚至几个小时内不处理信用卡支付事务，也不会冒险处理错误的消息。不过在对可用性要求较高的系统里，比如实时点击流分析系统，一般会启用不完全的首领选举。

1.3.3最少同步副本

min.insync.replicas在主题级别跟broker级别之上。若此值设置为2，表示至少要存在两个同步副本才能向分区写入数据。
如果3个副本都是同步的，或者其中一个副本变为不可用，都不会有什么问题。如果有两个副本变为不可用，那么broker就会停止接受生产者的请求。尝试发送数据的生产 者会收到异常。消费者仍然可以继续读取已有的数据。实际上，如果使用这样的配置，那么当只剩下一个同步副本时，它就变成只读了。为了从只读状态中恢复，必须让两个不可用分区中的一个重新变为可用的(比如重启 broker)，并等待它变为同步的。

1.4在可靠的系统里使用生产者

需注意以下两点：

1. 根据可靠性需求配置恰当的 acks值。
2. 在参数配置和代码里正确处理错误。

1.4.1发送确认

生产者可以选择以下3种不同的确认模式。

1. acks=0意味着如果生产者能够通过网络把消息发送出去，那么就认为消息已成功写入Kafka
2. acks=1意味若首领在收到消息并把它写入到分区数据文件（不一定同步到磁盘上）时会返回确认或错误响应。在这个模式下，如果发生正常的首领选举，生产者会在选举时收到一个异常，如果生产者能恰当地处理这个错误，它会重试发送悄息，最终消息会安全到达新的首领那里。不过在这个模式下仍然有可能丢失数据，比如消息已经成功写入首领，但在消息被复制到跟随者副本之前首领发生崩溃。
3. acks=all意味着首领在返回确认或错误响应之前，会等待所有同步副本都收到消息。如果和，om.insync.replicas参数结合起来，就可以决定在返回确认前至少有多少个副本能够收到悄息。这样生产者会一直重试直到消息被成功提交。不过这也是最慢的做法，生产者在继续发送其他消息之前需要等待所有副本都收到当前的消息。可以通过使用异步模式和更大的批次来加快速度，但这样做通常会降低吞吐量。

1.4.2配置生产者的重试参数

生产者需要处理的错误包括两部分：一部分是生产者可以自动处理的错误，还有一部分是需要开发者手动处理的错误。
如果 broker返回的错误可以通过重试来解决，那么生产者会自动处理这些错误。生产者向 broker发送消息时， broker可以返回一个成功晌应码或者一个错误响应码。错民晌应码可以分为两种，一种是在重试之后可以解决的，还有一种是无法通过重试解决的。

1.4.3额外的错误处理

使用生产者内置的重试机制可以在不造成消息丢失的情况下轻松地处理大部分错误，不过
对于开发人员来说，仍然需要处理其他类型的错误，包括:

1. 不可重试的 broker错误，例如消息大小错误、认证错误等
2. 在消息发送之前发生的错误，例如序列化错误
3. 在生产者达到重试次数上限时或者在消息占用的内存达到上限时发生的错误。

1.5在可靠的系统里使用消费者

只有那些被提交到 Kafka 的数据，也就是那些已经被写入所有同步副本的数据，对消费者是可用的，这意味着消费者得到的消息已经具备了一致性。消费者唯一要做的是跟踪哪些消息是已经读取过的，哪些是还没有读取过的。这是在读取消息时不丢失悄息的关键。

1.5.1消费者的可靠性配置

1. group.id。如果两个消费者具有相同的group.id，井且订阅了同一个主题，那么每个消费者会分到主题分区的一个子集，也就是说它们只能读 到所有消息的一个子集（不过群组会读取主题所有的消息）。如果你希望消费者可以看到主题的所有消息，那么需要为它们设置唯一的group.id
2. auto.offset.reset。这个参数指定了在没有偏移量可提交时（比如消费者第1次启动时）或者请求的偏移量在 broker上不存在时。这个参数有两种配置。 一种是earliest，如果选择了这种配置，消费者会 从分区的开始位置读取数据，不管偏移量是否有效，这样会导致消费者读取大量的重复数 据，但可以 保证最少的数据丢失。 一种是 latest，如果选择了这种配置，消费者会从分区的末尾开始读取数据，这样可以减少重复处理消息，但很有可能会错过一些消息。
3. enable.auto.commit。你可以让悄费者基于任务调度自动提交偏移量 ，也可以在代码里手动提交偏移量。自动提交的一个最大好处是，在 实现消费者逻辑时可以少考虑一些问题。如果你在消费者轮询操作里处理所有的数据，那 么自动提交可以保证只提交已经处理过的偏移量。自动提交的主要缺点是，无法控制重复处理消息，而且如果把消息交给另外一个后台线程去处理，自动提交机制可能会在消息还没有处理完毕就提交偏移量。
4. auto.commit.interval.ms。如果选择了自动提交偏移盘，可以通过该参数配置提交的频度， 默认值是每5秒钟提交一次。一般来说，频繁提交会增加额外的开销，但也会降低重复处理消息的概率。

1.5.2显式提交偏移量

如果选择了自动提交偏移量，就不需要关心显式提交的问题。要么是为了减少重复处理消息 ，要么是因为把消息处理逻辑放在了轮询之外。

1. 总是在处理完事件后再提交偏移量
2. 提交频度是性能和重复消息数量之间的权衡
3. 确保对提交的偏移量心里有数
4. 再均衡
5. 消费者可能需要重试
6. 消费者可能需要维护状态
7. 长时间处理
8. 仅一次传递