kafka数据可靠传输

把书读薄(Kafka权威指南 第六章)

kafka对消息可靠性做出的保证

1. 保证分区消息的顺序。同一个生产者给同一个分区写消息一定是有序的
2. 得去的所有的同步副本写入了消息时，才会被认为已经提交
3. 只要有一个副本是活跃的消息就不会丢失
4. 消费者只能提取已经提交的消息

broker对消息可靠性的处理

1. 复制系数。即一个消息应该有多少个副本【一般3个】，这些副本在机架上如何分布，保证不会应为1个broker挂掉或者一个机架路由有问题而导致不可用。
2. 不完全首领选举。允许不同步的副本作为首领。坏处是对于同一个偏移量，不同步的副本作为首领之后，获取的是新数据，而原来的副本存储的是旧数据。【出现场景可能是，1：假设3个副本，2个副本挂了，首领副本正常运行，这时候首领副本也挂了，随后启动了新的副本，数据不同步；2：3个副本中，首领副本正常，但是由于网络延迟跟随副本复制存在一定的延迟，如果首领副本挂了，其它副本都是不同步的】
3. 最少同步副本。当分区同步副本数少于最少同步副本的时候，就停止接受生产者的消息，抛出异常。以避免不完全选举所产生的数据写入与读出预期不一致的情况

生产者对消息可靠性的处理

生产者对消息可靠性可以从两个方面引入。首先是假设acks=1，但是一共有3个副本，假如首领副本这时候恰巧崩溃，而其他的副本会被认为是同步的，对生产者而言，这里丢失了一个消息；其次是假设acks=all,即3个副本都是同步的才确认，如果恰好首领副本崩溃，在选举期间来的消息，生产者只会收到首领不可用的响应，需要生产者自己去处理消息。因而需要考虑两个方面：1是acks的设置，不过需要处理吞吐量和消息丢失的关系【ack越多丢失概率越小，但是吞吐量少，得等待收到所有的】；2是生产者的重试机制，对于可重试的采用kafka内部的重试机制，不可重试的错误考虑保存到其它地方，后续进入，另外重试带来的风险是消息重复

消费者对消息可靠性的处理

消费者的最大毛病在于万一提交了消息偏移量，但是却没有处理完，导致这段消息将永远不会被处理。所以最关键的地方在于如何处理消息偏移量。包括自动偏移提交和手动偏移提交的策略【处理完后提交，提交的频次，再均衡，仅一次的语义—----结果写入键唯一系统，可以覆盖掉重复的信息】