Kafka的特点和存储机制

一、Kafka简介与架构

1. kafka定义
Kafka是一个基于发布订阅模式的分布式消息队列，它具有以下特点：

支持消息的发布和订阅，类似于 RabbtMQ、ActiveMQ 等消息队列；
支持数据离线和实时处理；
能保证消息的可靠性投递；
支持消息的持久化存储，并通过多副本分布式的存储方案来保证消息的容错，时间效率O(1)；
高吞吐率，单 Broker 可以轻松处理数千个分区以及每秒百万级的消息量。
支持在线水平扩展
2. 消息队列的优点
**解耦：**两边数据处理过程独立，可任意修改，只要遵从相同的接口约束
**可恢复性：**系统的一部分组件失效时，不会影响到整个系统。即使一个处理消息的进程挂掉，加入队列中的消息仍可在系统恢复后处理
**缓冲：**控制优化数据流经过系统的速度，解决生产消费速度不一致的问题
**削峰平谷：**访问量剧增的情况可以避免系统因超负荷的请求而崩溃
**异步通信：**提供了异步处理机制
3. Kafka与其他消息队列的对比
RabbitMQ

RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。

Redis
Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

4. 消息队列的两种模式
4.1 点对点模式
消费者主动拉取数据，消息收到后清除

4.2 发布/订阅模式
生产者将消息发布到topic中，同时有多个消费者订阅该消息

5. Kafka的基本架构
5.1 消息、批次
Kafka中的基本数据单元称为消息（Message）在磁盘中保存为log， 为减少网络开销，提高效率，多个消息会被放入同一批次 (Batch) 中后再写入

5.2 主题、分区、副本
Kafka中的消息根据主题（Topic）来分类，为了使Kafka的吞吐率可以线性提高，每个主题又分为不同的分区（Partition），每个分区可以有多个副本（Replica）。每个分区中消息的内容不同，不同分区可以部署在不同的服务器上，每个分区也可以有多份副本，分为Leader和Follower，每个副本必须放在不同的服务器中，保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失 。但由于消息保存在不同的分区中，也就无法实现整个主题中消息的有序，只在分区内保证有序性。

5.3 生产者、消费者、消费者组
生产者（Producer）既是向Kafka集群发送消息的客户端；
消费者（Consumer）既是向Kafka集群拉取消息的客户端；
消费者组（Consumer Group）有多个消费者组成，消费者组中每个消费者负责消费不同的分区，不可重复消费。

5.4 Broker、集群
每一台独立的Kafka服务器均被称为Broker，有不同的BrokerId。
集群（Cluster）由Broker组成，每个集群都有一个Controller负责将分区分配给Broker和监控Broker。

二、Kafka数据存储机制

1. Kafka文件存储机制
Kafka中的消息是以topic进行分类的，topic是逻辑上的概念，而partition是物理上的概念。每个partition对应一个log文件，存储的就是producer生产的数据。Producer生产的每条数据都会追加到文件的末端（顺序写磁盘，所以效率很高），每条数据都有自己的offset，消费者组的每个消费者都会实时记录自己消费到哪个offset。

为防止log文件过大导致数据定位效率低下，Kafka采用了分段和索引机制，将每个partition分为多个segment，每个segment对应两个文件——“.index” “.log”，分别保存索引和数据。索引文件中保存数据文件中message的offset。

2. Kafka副本机制
为了保证高可用，Kafka的每个分区都是多副本的。其中，一个副本是leader replica，其他副本是follower replica。当一个首领副本不可用时，其中一个跟随者副本将成为新首领。

2.1 ISR（in-sync Replica）机制
每个分区都维护一个isr列表，用于维护所有同步的可用的副本，对应跟随者副本来说，他必须满足以下条件才能被认为是同步副本：

定时向Zookeeper发送心跳；
在规定的时间内从leader处低延迟的获取过消息。
如果长时间follower未向leader同步数据，则该follower将被踢出isr，改时间阈值由replica.time.max.ms设定。

2.2 不完全的首领选举
对于副本机制，在broker级别有一个可选的配置参数unclean.leader.election.enable，默认禁止，这是针对leader挂掉且isr中没有其他可用副本时，是否允许某个不完全同步的副本成为首领副本。

2.3 最少同步副本
在broker或topic级别，可以配置min.insync.replicas，代表当isr队列中可用副本的最小值，如果isr副本数量小于该值时，就认为整个分区处于不可用状态。

2.4 数据保留规则
保留数据是 Kafka 的一个基本特性， 但是 Kafka 不会一直保留数据，也不会等到所有消费者都读取了消息之后才删除消息。相反， Kafka 为每个主题配置了数据保留期限，规定数据被删除之前可以保留多长时间，或者清理数据之前可以保留的数据量大小。分别对应以下四个参数：

log.retention.bytes ：删除数据前允许的最大数据量；默认值-1，代表没有限制；
log.retention.ms：保存数据文件的毫秒数，如果未设置，则使用 log.retention.minutes 中的值，默认为 null；
log.retention.minutes：保留数据文件的分钟数，如果未设置，则使用 log.retention.hours 中的值，默认为 null；
log.retention.hours：保留数据文件的小时数，默认值为 168，也就是一周。