一 定义

一个队列，拥有先进先出的特性，采用异步通信机制。

1 应用解耦

2 异步处理

3 数据限流

4 消息通信

主题：通过主题来区分不同业务类型的消息记录。

分区：每一个主题中可以有一个或者多个分区。每个分区内部的消息记录是有序的，每个消息都有一个连续的偏移量序号。一个分区中对应一个代理节点，一个代理节点可以管理多个分区。

副本：每个主题在创建时会要求指定他的副本数，默认是1，通过副本机制来保证Kafka分布式集群数据的高可用性。

记录： 被实际写入到kafka集群并且被消费者应用程序读取的数据，被称为记录，每条记录包含一个键，值和时间戳。

1 高吞吐量

2 高可用队列

3 低延时

4 分布式机制

kafka适用于以下场景：

1 日志收集

2 消息系统

3 用户轨迹

4 记录运营监控数据

5 实现流处理

6 事件源

二 比较

业界主流的消息队列：Apache ActiveMQ, Kafka， RabbitMQ，RocketMQ

2.1 ActiveMQ : http//activemq.apache.org/

* Apache出品，历史悠久，支持多种语言的客户端和协议，支持多种语言

* 基于JMS Provider的实现

* 缺点：吞吐量不高，多队列的时候性能下降，存在消息丢失的情况,比较少大规模使用

2.2 Kafka: http://kafka.apache.org/

* 是由Apache软件基金会开发的一个开源流处理平台，由Scala和java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理大规模的网站中的所有动作流数据，副本集机制，实现数据冗余，保障数据尽量不丢失；支持多个生产者和消费者。

* 类似MQ，功能较为简单，主要支持常规的MQ功能。

* 它提供了类似JMS的特性，但是在设计实现上完全不同，它并不是JMS规范的实现

* 缺点：运维难度大，文档比较少，需要掌握Scala

2.3 RocketMQ: http://rocketmq.apache.org/

* 阿里开源的一款消息中间件，纯java开发，具有高吞吐量，高可用性，适合大规模分布式系统应用的特点，性能强劲（零拷贝技术），支持海量堆积，支持指定次数和时间间隔的失败消息重发，支持consumer端tag过滤，延迟消息等，在阿里内部进行大规模使用，适用于电商，金融等领域。

* 基于JMS Provider的实现

* 缺点：更新比较快，纯java支持

2.4 RabbitMQ: http://www.rabbitmq.com/

* 是一个开源的AMQP实现，服务端用Erlang语言编写，支持多种客户端，用于在分布式系统中存储转发消息，在易用性，扩展性，高可用性等方面表现不错。

缺点：使用Erlang开发，阅读和修改源码难度大。

三 概念

3.1 Broker

* Kafka的服务端程序，可以认为一个mq节点就是一个broker

* broker存储topic的数据

3.2 Producer生产者

* 创建消息Message,然后发布到MQ中

* 该角色将消息发布到Kafka的topic中

3.3 Consumer消费者

* 消息队列里面的消息

3.4 ConsumerGroup消费者组

* 同个topic,广播发送给不同的group,一个group中只有一个consumer可以消费此消息

3.5 Topic 

* 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic,主题的意思。

3.6 Partition分区  

* kafka数据存储的基本单元，topic中的数据分割为一个或多个partition,每个topic至少有一个partition,是有序的。

* 一个Topic的多个partitions,被分布在kafka集群中的多个server上

* 消费者数量 《= 小于或者等于Partition数量  

3.7 Replication 副本

* 同个Partition会有多个副本replication，多个副本的数据是一样的，当其他broker挂掉之后，系统可以主动用副本提供服务

* 默认每个topic的副本都是1，也可以在创建topic的时候指定

* 如果当前kafka集群只有3个broker节点，则replication-factor最大就是3了，如果创建副本是4，则会报错

3.8 ReolicationLeader, ReplicationFollower

* Partition有多个副本，但只有一个replicationLeader负责该Partition和生产者消费者交互。

* ReplicationFollower只是做一个备份，从replicationLeader进行同步

3.9 ReplicationManager

* 负责Broker所有分区副本信息，Replication副本状态切换。

3.10 offset

* 每个consumer实例需要为它消费的partition维护一个记录自己消费到哪里的偏移offset

* kafka把offset保存在消费端的消费者组里

3.11 特点总结

* 多订阅者

一个topic可以有一个或者多个订阅者

每个订阅者都要有一个partition，所以订阅者数量要少于等于partition数量

* 高吞吐量，低延迟：每秒可以处理几十万条消息

* 高并发：几千个客户端同时读写

* 容错性：多副本，多分区，允许集群中节点失败，如果副本数据量为n,则可以n-1个节点失败

* 扩展性强：支持热扩展

3.12 基于消费者组可以实现：

基于队列的模型：所有消费者都在同一消费者组里，每条消息只会被一个消费者处理。

基于发布订阅模型：消费者属于不同的消费者组，加入每个消费者都有自己的消费者组，这样kafka消息就能广播到所有消费者实例上。

四 原理概念

4.1 Partition

* topic 物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列

* 是以文件夹的形式存储在具体Broker本机上

4.2 LEO (LogEndOffset)

* 表示每个partition的log最后一条Message的位置

4.3 HW (HighWatermark）

* 表示partition各个replicas数据间同步且一致的offset位置，即表示all replicas已经commit的位置

* HW之前的数据才是commit后的，对消费者可见

4.4 offset

* 每个partition都由一系列有序的，不可变的消息组成，这些消息被连续追加到partition中

* partition中的每个消息都有一个连续的序列号叫做offset，用于partition唯一标识一条消息

* 可以认为offect是partition中Message的id

4.5 segment

* segment file由两部分组成，分别为index file和data file( log fille)

* 两个文件是一一对应的，后缀.index和 .log分别表示索引文件和数据文件

* 命名规则：partition的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset+1

4.6 kafka高效文件存储设计特点

Kafka把topic中一个partition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。

* 通过索引信息可以快速定位message

* producter生产数据，要写入到log文件中，写的过程中一直追加到文件末尾，为顺序写，官网数据表明，同样的磁盘，顺序写能到600M/S，而随机写只有100K/S。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92123 人正在系统学习中

来源：葛旭朋