Kafka是什么？有哪些应用场景？

Kafka 是一个分布式流式处理平台。

流式平台具有三个关键功能：

  1. 消息队列：发布和订阅消息流，这个功能类似于消息队列，这也是 Kafka 也被归类为消息队列的原因。
  2. 容错的持久方式存储记录消息流：Kafka 会把消息持久化到磁盘，有效避免了消息丢失的风险。
  3. 流式处理平台： 在消息发布的时候进行处理，Kafka 提供了一个完整的流式处理类库。

Kafka 主要有两大应用场景：

  1. 消息队列：建立实时流数据管道，以可靠地在系统或应用程序之间获取数据。
  2. 数据处理： 构建实时的流数据处理程序来转换或处理数据流。

kafka的核心概念

什么是Producer、Consumer、Broker、Topic、Partition？

Producer（生产者） : 产生消息的一方。

Consumer（消费者） : 消费消息的一方。

Broker（代理） : 可以看作是一个独立的 Kafka 实例。多个 Kafka Broker 组成一个 Kafka Cluster。

同时，你一定也注意到每个 Broker 中又包含了 Topic 以及 Partition 这两个重要的概念：

Topic（主题） : Producer 将消息发送到特定的主题，Consumer 通过订阅特定的 Topic(主题) 来消费消息。

Partition（分区） : Partition 属于 Topic 的一部分。一个 Topic 可以有多个 Partition ，并且同一 Topic 下的Partition 可以分布在不同的 Broker 上，这也就表明一个 Topic 可以横跨多个 Broker 。这正如我上面所画的图一样。

Kafka的多副本机制？

还有一点我觉得比较重要的是 Kafka 为分区（Partition）引入了多副本（Replica）机制。分区（Partition）中的多个副本之间会有一个叫做 leader 的家伙，其他副本称为 follower。我们发送的消息会被发送到 leader 副本，然后 follower 副本才能从 leader 副本中拉取消息进行同步。

生产者和消费者只与 leader 副本交互。你可以理解为其他副本只是 leader 副本的拷贝，它们的存在只是为了保证消息存储的安全性。当 leader 副本发生故障时会从 follower 中选举出一个 leader，但是 follower 中如果有和 leader 同步程度达不到要求的参加不了 leader 的竞选。

Kafka的多分区（Partition）以及多副本（Replica）机制有哪些好处？

  • Kafka 通过给特定 Topic 指定多个 Partition，而各个 Partition 可以分布在不同的 Broker 上，这样便能提供比较好的并发能力（负载均衡）。
  • Partition 可以指定对应的 Replica 数，这也极大地提高了消息存储的安全性，提高了容灾能力，不过也相应的增加了所需要的存储空间。

Kafka相比其他消息队列的优势

Kafka

号称大数据的杀手锏，谈到大数据领域内的消息传输，则绕不开Kafka，这款为大数据而生的消息中间件，以其百万级TPS的吞吐量名声大噪，迅速成为大数据领域的宠儿，在数据采集、传输、存储的过程中发挥着举足轻重的作用。

Apache Kafka它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log)，之后成为Apache项目的一部分。目前已经被LinkedIn，Uber, Twitter, Netflix等大公司所采纳。

优点

  • 性能卓越，单机写入TPS约在百万条/秒，最大的优点，就是吞吐量高。
  • 时效性：ms级
  • 可用性：非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
  • 消费者采用Pull方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;
  • 有优秀的第三方Kafka Web管理界面Kafka-Manager；
  • 在日志领域比较成熟，被多家公司和多个开源项目使用；
  • 功能支持：功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用

缺点：

  • Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长
  • 使用短轮询方式，实时性取决于轮询间隔时间；
  • 消费失败不支持重试；
  • 支持消息顺序，但是一台代理宕机后，就会产生消息乱序；
  • 社区更新较慢；

RabbitMQ

RabbitMQ 2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

RabbitMQ优点：

  • 由于erlang语言的特性，mq 性能较好，高并发；
  • 吞吐量到万级，MQ功能比较完备
  • 健壮、稳定、易用、跨平台、支持多种语言、文档齐全；
  • 开源提供的管理界面非常棒，用起来很好用
  • 社区活跃度高；

RabbitMQ缺点：

  • erlang开发，很难去看懂源码，基本职能依赖于开源社区的快速维护和修复bug，不利于做二次开发和维护。
  • RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。
  • 需要学习比较复杂的接口和协议，学习和维护成本较高。

RocketMQ

RocketMQ出自 阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进。RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

RocketMQ优点：

  • 单机吞吐量：十万级
  • 可用性：非常高，分布式架构
  • 消息可靠性：经过参数优化配置，消息可以做到0丢失
  • 功能支持：MQ功能较为完善，还是分布式的，扩展性好
  • 支持10亿级别的消息堆积，不会因为堆积导致性能下降
  • 源码是java，我们可以自己阅读源码，定制自己公司的MQ，可以掌控

RocketMQ缺点：

  • 支持的客户端语言不多，目前是java及c++，其中c++不成熟；
  • 社区活跃度一般
  • 没有在 mq 核心中去实现JMS等接口，有些系统要迁移需要修改大量代码

kafka消息队列的两种模式

点对点模式（一对一）

1）模式特点

消息生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。消息被消费以后，queue中不再存储该条消息，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者消费。

2）数据拉取方式：消费者主动拉取。

3）模式缺点：消息不能被重复消费。

发布订阅模式（一对多）

1）模式特点

消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。

2）数据拉取方式：消费者主动拉取、消费者被动接受（类似微信公众号）

3）模式缺点：当数据拉取方式为消费者被动接受时，消费者的消费速度可能跟不上生产者的生产速度。

Kafka的高可用机制

如何保证宕机时数据不丢失？

如果要想理解这个acks参数的含义，首先就得搞明白kafka的高可用架构原理。

比如下面的图里就是表明了对于每一个Topic，我们都可以设置他包含几个Partition，每个Partition负责存储这个Topic一部分的数据。

然后Kafka的Broker集群中，每台机器上都存储了一些Partition，也就存放了Topic的一部分数据，这样就实现了Topic的数据分布式存储在一个Broker集群上。

多副本冗余的高可用机制

在kafka集群中，每个Partition都有多个副本，其中一个副本叫做leader，其他的副本叫做follower，如下图。

如上图所示，假设一个Topic拆分为了3个Partition，分别是Partition0，Partiton1，Partition2，此时每个Partition都有2个副本。

比如Partition0有一个副本是Leader，另外一个副本是Follower，Leader和Follower两个副本是分布在不同机器上的。

这样的多副本冗余机制，可以保证任何一台机器挂掉，都不会导致数据彻底丢失，因为起码还是有副本在别的机器上的。

多副本之间数据如何同步？

接着我们就来看看多个副本之间数据是如何同步的？其实任何一个Partition，只有Leader是对外提供读写服务的。

也就是说，如果有一个客户端往一个Partition写入数据，此时一般就是写入这个Partition的Leader副本。

然后Leader副本接收到数据之后，Follower副本会不停的给他发送请求尝试去拉取最新的数据，拉取到自己本地后，写入磁盘中。如下图所示：

ISR到底指的是什么东西？

既然大家已经知道了Partiton的多副本同步数据的机制了，那么就可以来看看ISR是什么了。

ISR全称是“In-Sync Replicas”，也就是保持同步的副本，他的含义就是，跟Leader始终保持同步的Follower有哪些。

大家可以想一下 ，如果说某个Follower所在的Broker因为JVM FullGC之类的问题，导致自己卡顿了，无法及时从Leader拉取同步数据，那么是不是会导致Follower的数据比Leader要落后很多？

所以这个时候，就意味着Follower已经跟Leader不再处于同步的关系了。但是只要Follower一直及时从Leader同步数据，就可以保证他们是处于同步的关系的。

所以每个Partition都有一个ISR，这个ISR里一定会有Leader自己，因为Leader肯定数据是最新的，然后就是那些跟Leader保持同步的Follower，也会在ISR里。

acks参数的含义

首先这个acks参数，是在KafkaProducer，也就是生产者客户端里设置的。也就是说，你往kafka写数据的时候，就可以来设置这个acks参数。然后这个参数实际上有三种常见的值可以设置，分别是：0、1 和 all。

acks参数设置为0

这种方式意思就是我的KafkaProducer在客户端，只要把消息发送出去，不管那条数据有没有在哪怕Partition Leader上落到磁盘，我就不管他了，直接就认为这个消息发送成功了。

如果你采用这种设置的话，那么你必须注意的一点是，可能你发送出去的消息还在半路。结果呢，Partition Leader所在Broker就直接挂了，然后结果你的客户端还认为消息发送成功了，此时就会导致这条消息就丢失了。

acks参数设置为1

这种方式意思就是说只要Partition Leader接收到消息而且写入本地磁盘了，就认为成功了，不管他其他的Follower有没有同步过去这条消息了。这种设置是kafka默认的设置，也就是说，你要是不管acks这个参数，只要Partition Leader写成功就算成功。

但是这里有一个问题，万一Partition Leader刚刚接收到消息，Follower还没来得及同步过去，结果Leader所在的broker宕机了，此时也会导致这条消息丢失，因为人家客户端已经认为发送成功了。

acks参数设置为all

这种方式意思就是说，Partition Leader接收到消息之后，还必须要求ISR列表里跟Leader保持同步的那些Follower都要把消息同步过去，才能认为这条消息是写入成功了。

如果说Partition Leader刚接收到了消息，但是结果Follower没有收到消息，此时Leader宕机了，那么客户端会感知到这个消息没发送成功，他会重试再次发送消息过去。

此时可能Partition 2的Follower变成Leader了，此时ISR列表里只有最新的这个Follower转变成的Leader了，那么只要这个新的Leader接收消息就算成功了。

Kafka如何保证消息有序

  1. 1 个 Topic 只对应一个 Partition。
  2. （推荐）发送消息的时候指定 key/Partition。

Kafka 中发送 1 条消息的时候，可以指定 topic, partition, key, data（数据） 4 个参数。如果你发送消息的时候指定了 Partition 的话，所有消息都会被发送到指定的 Partition。并且，同一个 key 的消息可以保证只发送到同一个 partition，这个我们可以采用表/对象的 id 来作为 key 。

Kafka如何确保消息不丢失

生产者丢失消息的情况

生产者(Producer) 调用send方法发送消息之后，消息可能因为网络问题并没有发送过去。

通过回调函数异步获取send方法的调用结果来检查消息是否发送成功。如果消息发送失败的话，我们检查失败的原因之后重新发送即可，这里可以使用Producer的retries（重试次数）设置一个合理的值，一般是3。此外，也要考虑重试的时间间隔。

消费者丢失消息的情况

。。。

Kafka丢失消息

答案就是Kafka高可用机制中的acks含义

Kafka消息是采用Pull模式，还是Push模式？

在这方面，Kafka遵循了一种大部分消息系统共同的传统的设计：producer将消息推送到broker，consumer从broker拉取消息。

Pull模式的另外一个好处是consumer可以自主决定是否批量的从broker拉取数据。Push模式必须在不知道下游consumer消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免consumer崩溃而采用较低的推送速率，将可能导致一次只推送较少的消息而造成浪费。Pull模式下，consumer就可以根据自己的消费能力去决定这些策略。

Pull有个缺点是，如果broker没有可供消费的消息，将导致consumer不断在循环中轮询，直到新消息到t达。为了避免这点，Kafka有个参数可以让consumer阻塞知道新消息到达（当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发）

如何保证消息不重复消费

Kafka 出现消息重复消费的原因：

  • 服务端侧已经消费的数据没有成功提交 消费位移offset（根本原因）。
  • Kafka 侧 由于服务端处理业务时间长或者网络链接等等原因让 Kafka 认为服务假死，触发了分区 rebalance。

解决方案：

  • 消费消息服务做幂等校验，比如 Redis 的 set、MySQL 的主键等天然的幂等功能。这种方法最有效。

  • 将 **enable.auto.commit** 参数设置为 false，关闭自动提交，开发者在代码中手动提交 offset。那么这里会有个问题：什么时候提交 offset 合适？

  • 处理完消息再提交：依旧有消息重复消费的风险，和自动提交一样

  • 拉取到消息即提交：会有消息丢失的风险。允许消息延时的场景，一般会采用这种方式。然后，通过定时任务在业务不繁忙（比如凌晨）的时候做数据兜底。

消息积压怎么处理

这种是由只能操作临时扩容，以更快的速度去消费数据。

  1. 增加多个消费者，加速消费；
  2. 新建topic引流，将消息引导别的程序。