本文是新系列“研磨”系列的开篇，该系列主要立足源码分析、核心技术点分析、常见问题整理等方面。一篇文章围绕一个中间件，立足于讲清、讲透、讲明白。

系列的第一部分主题为–“研磨Kafka”，本篇中，我们先从宏观的视角窥探Kafka的核心角色，并对后文中要讲到的主题做一个宏观的概述。

Kafka的设计原理及结构概述

首先对Kafka重要的角色进行总结。

要点	解释
Kafka概述	Kafka是一款分布式消息中间件，但它不符合JMS规范。
消费特点	Kafka消费消息成功，不会马上删除消息。消息存储一段时间后，会被批量删除。
Broker	Broker是Kafka的服务端，主要作用为接收消息并对消息进行持久化存储。 Broker可以有多个，每一个Broker节点可存储多个Topic。但是Broker本身并不会存储消费的Offset（即消费者消费消息的位置），Offset数据由Consumer（消费者）保存，保存位置为Zookeeper。
Topic	Topic为消息主题，它是生产者与消费者之间进行消息传递的依据。单个Topic下包括多个Partition，它的所有元数据存储在zookeeper中。
Partition	Partition即分区，Kafka为提高性能及扩展性，将一个Topic分为多个分区，及Partition，每个Partition均可独立存放在一个Broker上，这保证了Kafka的可用性及稳定性。
Producer	Producer为消息生产者，它一般是集成了Kafka客户端的业务应用。 Producer负责发送消息到Broker。Producer直连Broker，具有往Topic下发布消息的能力。 它会与Topic下的所有PartitionLeader保持Socket长连接。Producer具有同步、异步两种消息发送能力，且Producer支持消息的批量发送，即将多条消息缓存在客户端，在达到指定的时间延迟或者消息数量后，批量地提交给Broker。
Consumer	Consumer为消息消费者，它一般是集成了Kafka客户端的业务应用。消费者向Broker订阅Topic，并从Topic中接收消息。 每一个消费者均属于某一个消费者组，且同消费者组中的消费者订阅同一个Topic，同一个Topic下的不同消费者分别订阅该Topic下不同Partition的数据。一个消费者可以订阅多个Partition，但同一个Partition只能被一个消费者订阅，该策略的目的是一定程度上避免消息被重复消费。 可以通过增加Partition的方式对消费能力进行横向扩展。 当出现某个消费者down机，消费过程会进行 Rebalance。

研磨Kafka主题

该系列后续会涉及到的要点，在此处进行整理

要点
如何提升Kafka的吞吐量及低延时
Kafka的消息持久化方式
Kafka如何实现负载均衡及故障转移
如何理解Kafka的“伸缩性”特点
概览主题（Topic）与分区（Partition）
解释什么是消息位移offset
解释下Kafka的副本机制如何实现
Kafka如何利用“ISR机制”保证消息不丢失?
kafka是否存在消息丢失的情况?

Kafka使用场景

Kafka主要应用的场景如下

场景	说明
消息传递	Kafka的高吞吐、高可靠特性使得它很适合作为消息总线或者消息代理的替代品，常用来实现超大规模消息引擎集群。
用户行为分析	Kafka在大数据领域常常与大数据组件相结合，协助进行用户行为数据的搜集。
运维数据收集	在运维领域，Kafka常被用作异步数据上报，监控数据收集等场景。
日志收集	这是Kafka使用的经典场景，通过Kafka对分散在不同机器上的机器进行收集，并集中存储在分布式存储中，Kafka的高吞吐、低延时的特性让它能够成为主流的日志收集解决方案。
流式处理	Kafka社区推出的Kafka Streams标志着它正式进入流式处理的大家庭。