Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。
主要应用场景是：日志收集系统和消息系统。
Kafka主要设计目标如下：
1、Kafka如何防止数据丢失
1）消费端弄丢数据
消费者在消费完消息之后需要执行消费位移的提交，该消费位移表示下一条需要拉取的消息的位置。Kafka默认位移提交方式是自动提交，但它不是在你每消费一次数据之后就提交一次位移，而是每隔5秒将拉取到的每个分区中的最大的消费位移进行提交。自动位移提交在正常情况下不会发生消息丢失或重复消费的现象，唯一可能的情况，你拉取到消息后，消费者那边刚好进行了位移提交，Kafka那边以为你已经消费了这条消息，其实你刚开始准备对这条消息进行业务处理，但你还没处理完，然后因为某些原因，自己挂掉了，当你服务恢复后再去消费，那就是消费下一条消息了，那么这条未处理的消息就相当于丢失了。所以，很多时候并不是说拉取到消息就算消费完成，而是将消息写入数据库或缓存中，或者是更加复杂的业务处理，在这些情况下，所有的业务处理完成才能认为消息被成功消费。Kafka也提供了对位移提交进行手动提交的方式，开启手动提交的前提是消费者客户端参数enable.auto.commit配置为false，
props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG,false);
消费者端手动提交方式提供了两种，commitSync()同步提交方式和commitAsync()异步提交方式。commitSync()同步提交方式在调用时Consumer程序会处于阻塞状态，直到远端的broker返回提交结果，这个状态才会结束，这样会对消费者的性能有一定的影响。commitAsync()异步提交方式在执行后会立刻返回，不会被阻塞，但是它也有相应的问题产生，如果异步提交失败后，它虽然也有重试，但是重试提交的位移值可能早已经“过期”或者不是最新的值了，因此异步提交的重试其实没有意义。这里我们可以把同步提交和异步提交相结合，以达到最理想的效果。
try {
while (true) {
ConsumerRecords<String, String> records = consumer.poll(1000);
for (ConsumerRecord<String, String> record : records) {
// 处理消息 record
}
consumer.commitAsync();
}
} catch (Exception e){
// 处理异常
} finally {
try {
consumer.commitSync();
} finally {
consumer.close();
}
}
2)Kafka端弄丢数据
如下图，副本A为leader副本，副本B为follower副本，它们的HW和LEO都为4。
image
此时，A中写入一条消息，它的LEO更新为5，B从A中同步了这条数据，自己的LEO也更新为5
image
之后B再向A发起请求以拉取数据，该FetchRequest请求中带上了B中的LEO信息，A在收到该请求后根据B的LEO值更新了自己的HW为5，A中虽然没有更多的消息，但还是在延时一段时间之后返回FetchRresponse，其中也包含了HW信息，最后B根据返回的HW信息更新自己的HW为5。
image
可以看到整个过程中两者之间的HW同步有一个间隙，B在同步A中的消息之后需要再一轮的FetchRequest/FetchResponse才能更新自身的HW为5。如果在更新HW之前，B宕机了，那么B在重启之后会根据之前HW位置进行日志截断，这样便会将4这条消息截断，然后再向A发送请求拉取消息。此时若A再宕机，那么B就会被选举为新的leader。B恢复之后会成为follower，由于follower副本的HW不能比leader副本的HW高，所以还会做一次日志截断，以此将HW调整为4。这样一来4这条数据就丢失了（就算A不能恢复，这条数据也同样丢失了）。
image
对于这种情况，一般要求起码设置如下4个参数：
1）给这个topic设置replication.factor参数：这个值必须大于1，要求每个partition必须有至少2个副本
2）在kafka服务端设置min.insync.replicas参数：这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系，没掉队，这样才能确保leader挂了还有一个follower
3）在producer端设置acks=all或-1：这个是要求每条数据，必须是写入所有replica之后，才能认为是写成功了
4）在producer端设置retries为很大的一个值：这个是要求一旦写入失败，就无限重试，它默认为0，即在发生异常之后不进行任何重试。
当然，设置了acks等于all或-1之后，会影响一定的性能。Kafka从0.11.0.0 开始引入了leader epoch的概念，在需要截断数据的时候使用leader epoch作为参考依据而不是原本的HW。leader epoch代表leader的纪元信息，初始值为0，每当leader变更一次，leader epoch的值就会加1，相当于为leader增设了一个版本号。引入leader epoch很好的解决了前面所说的数据丢失问题，也就不需要去设置acks=all了。
3）生产者端不会丢失数据
如果你配置了上面场景的参数，就是当数据写入leader副本和所有follower副本成功后才返回响应给生产者，如果写入不成功，生产者会不断重试。
2、Kafka 怎么防止重复消费
消费者的自动位移提交方式会带来重复消费的问题。假设刚刚提交完一次消费位移，然后拉取一批消息进行消费，在下一次自动位移提交之前，消费者崩了，那么等消费者恢复再来消费消息的时候又得从上一次位移提交的地方重新开始，这样便发生了重复消费的现象。
其实这里可以类似上面消费端丢失数据的情况，很多时候并不是说拉取到消息就算消费完成，而是将消息写入数据库或缓存中，或者是更加复杂的业务处理，重复消费也同样如此，重复消费不可怕，可怕的是你没考虑到重复消费之后，怎么保证幂等性，通俗点说，就一个数据，或者一个请求，给你重复来多次，你得确保对应的数据是不会改变的，不能出错。这里防止重复消费，你可以像上面一样把自动提交改为手动提交，或者是保证消息消费的幂等性。
保证消费消息幂等性
1）如果你是要插入postgresql中，可以对其设置唯一键，插入重复的数据只会插入报错，不会有重复数据产生
2）如果你是要写入redis中，每次都是set操作，可以保证幂等性
如何保证消息消费是幂等性的，需要结合具体的业务来看。