目录
Kafka简介
-
Kafka是一个分布式，支持分区，多副本的分布式消息系统（MQ）。它提供了普通消息系统的功能，但具有自己独特的设计特性。
-
kafka使用ZooKeeper用于管理、协调代理。
-
Kafka只有一种模式——发布/订阅。
-
目前是大数据生产中最常用的MQ,也是社区最活跃的MQ。
Kafka的优缺点
优点：
- 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition， consumer group 对partition进行consume操作。
- 可扩展：Kafka集群支持热扩展，可以在集群启动后把新服务器加入到集群。
- 容错性：允许节点失败，Kafka每个Partition数据会复制到几台服务器，当某个Broker失效时， Zookeeper将通知生产者和消费者使用其他的Broker。
- 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失。
- 高并发：支持数千个客户端同时读写
缺点：
- 重复消息：Kafka保证每条消息至少送达一次，虽然几率很小，但一条消息可能被送达多次。
- 消息乱序：Kafka某一个固定的Partition内部的消息是保证有序的，如果一个Topic有多个Partition，partition之间的消息送达不保证有序。
- 复杂性：Kafka需要Zookeeper的支持，Topic一般需要人工创建，部署和维护比一般MQ成本更高。
Kafka应用场景
- 日志记录：Kafka 的基本概念来源于提交日志，比如我们可以把数据库的更新发送到 Kafka 上，用来记录数据库的更新时间，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。
- 传递消息：Kafka 另外一个基本用途是传递消息，应用程序向用户发送通知就是通过传递消息来实现的，这些应用组件可以生成消息，而不需要关心消息的格式，也不需要关心消息是如何发送的。
- 活动跟踪：Kafka 可以用来跟踪用户行为，比如我们经常回去淘宝购物，你打开淘宝的那一刻，你的登陆信息，登陆次数都会作为消息传输到 Kafka ，当你浏览购物的时候，你的浏览信息，你的搜索指数，你的购物爱好都会作为一个个消息传递给 Kafka ，这样就可以生成报告，可以做智能推荐，购买喜好等。
- 度量指标：kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
- 实现流处理：流式处理是有一个能够提供多种应用程序的领域。比如spark streaming和storm。
- 限流削峰：Kafka 多用于互联网领域某一时刻请求特别多的情况下，可以把请求写入Kafka 中，避免直接请求后端程序导致服务崩溃。
Kafka架构
名词解释
话题（Topic）：是特定类型的消息流。消息是字节的有效负载（Payload），话题是消息的分类名或种子（Feed）名。
生产者（Producer）：是能够发布消息到话题的任何对象。
服务代理（Broker）：已发布的消息保存在一组服务器中，它们被称为代理（Broker）或Kafka集群。
消费者（Consumer）：可以订阅一个或多个话题，并从Broker拉数据，从而消费这些已发布的消息。
分区（Partition）：Parition是物理上的概念，每个Topic包含一个或多个Partition。
消息（message）： Kafka中最基本的传递对象。
分段（segment）：partition物理上由多个segment组成，每个Segment存着message信息。
偏移量（Offset）：偏移量，理解为消息partition中的索引即可。
消费者组（Consumer Group）：消费者组，一个Consumer Group包含多个consumer。
Kafka 拓扑结构
如上图所示，一个典型的 Kafka 集群中包含若干 Producer（可以是 web 前端产生的 Page View，或者是服务器日志，系统 CPU、Memory 等），若干 broker（Kafka 支持水平扩展，一般 broker 数量越多，集群吞吐率越高），若干 Consumer Group，以及一个 Zookeeper 集群。Kafka 通过 Zookeeper 管理集群配置，选举 leader，以及在 Consumer Group 发生变化时进行 rebalance。Producer 使用 push 模式将消息发布到 broker，Consumer 使用 pull 模式从 broker 订阅并消费消息。
Topic和Partition
在Kafka中的每一条消息都有一个topic。一般来说在我们应用中产生不同类型的数据，都可以设置不同的主题。一个主题一般会有多个消息的订阅者，当生产者发布消息到某个主题时，订阅了这个主题的消费者都可以接收到生产者写入的新消息。
kafka为每个主题维护了分布式的分区(partition)日志文件，每个partition在kafka存储层面是append log。任何发布到此partition的消息都会被追加到log文件的尾部，在分区中的每条消息都会按照时间顺序分配到一个单调递增的顺序编号，也就是我们的offset,offset是一个long型的数字，我们通过这个offset可以确定一条在该partition下的唯一消息。在partition下面是保证了有序性，但是在topic下面没有保证有序性。
在上图中，一个topic被分成了3个分区（即partition0~2），用户发布message时，可以指定message所处topic的partition，如果没有指定，则随机分布到该topic的partition。发布的消息（其实是逻辑日志）将在partition尾部插入。
补充：
Kafka与Zookeeper的关系：
- zookeeper中存储的信息有broker，consumer等重要znode信息。
- 每个kafka节点会在zookeeper中注册该机器的配置信息。
- 注册完的kafka节点的topic信息会存在topics目录下面。
发送：kafka的发送程序（代码）会指定broker服务地址，那么消息的发送会直接发送到broker提供的地址中。如果地址是列表（指定了多个broker地址），那么则随机选择一个可用的发送。接收到消息的kafka机器会向zookeeper查询拥有该topic下partition决定权（leader）的机器，然后由该leader选择机器存储数据，最终存储数据。
接收：kafka的接收会指定zookeeper地址，那么接收到消费任务的zookeeper将任务报告给该topic下partition的leader，由该leader指定follower完成数据的获取并返回。
Kafka和其他主流分布式消息系统的对比：
| RabbitMQ | RocketMQ | Kafka | |
|---|---|---|---|
| 设计初衷 | 保证消息投递 | 充分考虑消息堆积因素，考虑分布式，最求吞吐量，考虑事务 | 充分考虑消息堆积因素，考虑分布式，最求吞吐量，不考虑事务 |
| 路由特征 | 通过exchange、binding等可以实现丰富的路由 | 基于topic路由 | 基于topic路由 |
| 集群特征 | 集群透明 | 生产者需要明确消息发送的partition，利用这点实现partitionn内的消息顺序 | 生产者需要明确消息发送的partition，利用这点实现partitionn内的消息顺序 |
| 高可用性 | 基于mirror queue实现主从备份 | 通过人工方式完成master/slave切换 | 通过replica支持queue的master/slave自动切换 |
| 队列数目 | <1000 | >10000 | >10000 |
| 事务 | 不支持 | 支持 | 不支持 |