Kafka简介
- 概述
- 特性
- 应用场景
- 基础架构
- Kafka的几点理解
概述
Kafka起源于LinkedIn，后来于2011年成为开源Apache项目，然后于2012年成为First-class Apache项目。Kafka是用Scala和Java编写的。 Kafka 是一种高吞吐量的分布式发布订阅消息系统和一个强大的队列，可以处理大量的数据，能够将消息从一个端点传递到另一个端点。 Kafka适合离线和在线消息的消费。 Kafka消息保留在磁盘上，并在群集内复制以防止数据丢失。 Kafka构建在ZooKeeper同步服务之上。 它与Apache Storm和Spark可以很好的集成，用于实时流式数据分析。
特性
- 高吞吐量、低延迟：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息，它的延迟最低只有几毫秒
- 持久性：通过
O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。 - 可靠性：支持数据备份防止丢失
- 容错性：支持通过Kafka服务器和消费机集群来分区消息，允许集群中的节点失败（若分区副本数量为n，则允许n-1个节点失败）
- 高并发：支持Hadoop并行数据加载，单机可支持数千个客户端同时读写
O(1)：是最低的时空复杂度，耗时/耗空间与输入数据大小无关，无论输入数据增大多少倍，耗时/耗空间都不变
应用场景
- 日志收集：一个公司可以用Kafka收集各种服务的log，通过Kafka以统一接口开放给各种消费端，例如hadoop、Hbase、Solr等
- 消息系统：解耦生产者和消费者、缓存消息等
- 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索记录、点击等活动，这些活动信息被各个服务器发布到Kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘
- 运营指标：Kafka也经常用来记录运营监控数据
- 流式处理：流式处理是有一个能够提供多种应用程序的领域
- 流量消峰：Kafka 多用于互联网领域某一时刻请求特别多的情况下，可以把请求写入Kafka 中，避免直接请求后端程序导致服务崩溃
基础架构
Zookeeper: 管理producer，broker，consumer的动态加入与离开
broker: Kafka集群运行在一个或多个服务器上，每个服务器节点称为一个broker，一个broker可以容纳多个topic
topic: 每条发布到Kafka集群的消息都有一个类别，这个类别称为topic，类似于关系型数据库中的表（物理上不同topic的消息分开存储，逻辑上一个topic的消息既可以在同一个broker上也可以在不同的broker节点上，用户只需指定消息的topic即可生产或消费数据而不必关心数据存于何处），生产者和消费者面向的都是一个topic，一个topic可以拥有一个或多个消费者订阅
partition: 分区，每个topic被物理划分为一个或多个分区，每个分区都是有序且顺序不可变的记录集，并且不断地追加到结构化的conmmit log文件，每个分区在物理上对应一个文件夹，该文件夹里面存储了这个分区的所有消息和索引文件。在创建topic时可指定partition数量，生产者将消息发送到topic时，消息会根据分区策略追加到分区文件的末尾，属于顺序写磁盘，因此效率非常高（顺序写磁盘效率比随机写内存高，这是Kafka高吞吐率的一个重要保证）
分区策略：分区策略就是决定生产者将消息发送到哪个分区的算法。Kafka为我们提供了默认的分区策略，同时它也可以支持自定义分区策略。Kafka允许为每条消息设置一个key，一旦消息被定义了key，那么就可以保证同一个key的所有消息都进入到相同的分区，这种策略属于自定义的一种，被称为“按消息key保存策略”，或key-ordering策略
同一个主题的多个分区可以部署在多个机器上，以此来实现Kafka的伸缩性。同一partition中的数据是有序的，但topic下的多个partition之间在消费数据时不能保证有序性，在需要严格保证消息顺序消费的场景下，可以将partition数设置为1，但这种做法降低了吞吐，一般来说，只需要保证每个分区的有序性，再对消息设置key来保证相同key的消息落入同一分区，就可以满足绝大多数的应用
offset: partition中的每条消息都被标记了一个序号，这个序号表示消息在partition中的偏移量，即消费在log中的位置，每一条消息在partition都有唯一的offset，消息者通过指定offset来指定要消费的消息
偏移量由consumer所控制，通常消费者在消费完一条消息后会递增offset，准备去消费下一条消息，但实际上，由于这个位置由消费者控制，所以消费者可以采用任何顺序来消费记录
例如，一个消费者可以重置到一个旧的偏移量，从而重新处理过去的数据；也可以跳过最近的记录，从“现在”开始消费
Replica: 副本，为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作，kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower
leader: 每个partition有多个副本，其中有且仅有一个作为leader，leader会负责所有的客户端读写操作（生产者发送数据的对象，以及消费者消费数据的对象都是leader）
follower: follower不对外提供服务，只与leader保持数据同步，如果leader失效，则选举一个follower来充当新的leader。当follower与leader挂掉、卡住或者同步太慢，leader会把这个follower从ISR列表中删除，重新创建一个follower
producer: 消息生产者，生产者发送消息到指定的topic下，消息再根据分配规则append到某个partition的末尾，可以使用循环的方式来简单的实现负载均衡，也可以根据某些语义分区函数（例如：记录中的key）来完成
consumer: 消费者，消费者从topic中消费数据
consumer group: 消费者组，由多个consumer组成，每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内的消费者消费，消费者组之间互不影响。
Rebalance: 消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段
Kafka的几点理解
- 一个典型的Kafka集群中包含若干producer，若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干consumer group，以及一个Zookeeper集群。Kafka通过Zookeeper协调管理Kafka集群，选举分区leader，以及在consumer group发生变化时进行负载平衡
- 如上图，Consumer Group A中的C2挂掉，C1会接收P1和P2，达到重新平衡，同样的，当有新的消费者加入consumer group，也会触发重平衡操作
- Kafka的topic被划分为一个或多个分区，多个分区可以分布在一个或多个broker节点上，同时为了故障容错，每个分区都会复制多个副本，分别位于不同的broker节点，这些分区副本中（不管是leader还是follower都成为分区副本），一个分区副本会作为leader，其余的分区副本作为follower。其中leader负责所有的客户端读写操作，follower不对外提供服务，仅仅从leader上同步数据，当leader出现故障时，其中一个follower会顶替成为leader，继续对外提供服务
- Partition在服务器上的表现形式就是一个个文件夹，每个partition的文件夹下面会有多组segment文件，每组segment文件又包含
.index文件.log文件.timeindex文件，log文件实际是存储message的地方，而index和timeindex文件为索引文件，用于检索消息 - 对于传统的MQ而言，已经被消费的消息会从队列中删除（点对点模式），但在Kafka中被消费的消息也不会立马删除，在Kafka的server.properties配置文件中定义了数据的保存时间，当文件到设定的保存时间时才会删除
# 数据的保存时间（单位：小时,默认为7天）
log.retention.hours=168因为Kafka读取消息的时间复杂度为O(1)，与文件大小无关，所以删除过期文件与提高Kafka性能并没有关系，选择怎样的删除策略应该考虑磁盘以及具体的需求
