携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第27天，点击查看活动详情
服务端
Broker，接收和处理客户端发过来的请求。
副本
kafka实现高可用手段。
领导者副本（Leader Replica）：对客户端提供服务。
追随者副本（Follower Replica）：被动的追随领导者副本，不能与外界进行交互。
消息分区
伸缩性（Scalability）,可将一个主题的消息分割成多份保存在不同的Broker中。
分区策略
轮询策略
假设有三个分区，那么第一条消息被发送到分区0，第二条被发送到分区1，第三条被发送到分区2，第四条消息又会分区0。默认的分配策略。
随机策略
随意地将消息放置到任意一个分区上。
Key-ordering策略
目的是为了相同的key进入同一个分区，可以使消费是有序的，key可以是订单号、客户代码等。
消息日志
只能追加（Append-only）消息的物理文件，顺序写。在Kafka底层，一个日志又进一步细分成多个日志段，消息被追加到当前最新的日志段中，当写满一个日志段后，Kafka会自动切分出一个新的日志段，并将老的日志段封存起来。定时任务会定期检查老的日志是否能够被删除，进行回收。
位移主题
新版本Consumer的位移管理机制将Consumer的位移数据作为一条普通的Kafka消息，提交到__consumer_offsets中。
位移主题的Key中应该保存3部分内容：<Group ID,主题名，分区号>。Value中除了保证位移还保存位移提交的一些元数据，诸如时间戳和用户自定义的数据等，可以帮助Kafka执行各种各样后续的操作，比如删除过期位移消息等。
在Kafka集群中的第一个Consumer程序启动时，Kafka会自动创建位移主题。分区个数通过Broker端参数 offsets.topic.num.partitions 设置，默认50。通过offsets.topic.replication.factor设置副本数。
其他格式
- 用于保存Consumer Group信息的消息。用于注册Consumer Group。
- 用于删除Group过期位移甚至是删除Group消息。一旦某个Consumer Group下所有Consumer实例都停止了，而且它们的位移数据已被删除时，Kafka会向位移主题的对应分区写入tombstone消息，表明要彻底删除这个Group的消息。
删除策略
只是记录消费者主题分区消费进度，所以如果出现重复的key前面的消息都是可以删掉的，Kafka使用的Compact策略来删除位移主题中的过期消息，避免该主题无限期膨胀，如下图。
Kafka提供了专门的后台线程定期巡检待Compact的主题，看看是否存在满足提交的可删数据。这个后台线程叫Log Cleaner，很多实际生产环境中都出现过位移主题无限膨胀占用过多磁盘空间的问题，如果你的环境中也有这个问题，我建议你去检查一下 Log Cleaner 线程的状态，通常都是这个线程挂掉了导致的。
协调者-Coordinator
专门为Consumer Group服务，负责Group执行Rebalance以及提供位移管理和组成员管理等。
Consumer端员应用程序在提交位移时，其实是向Coordinator所在的Broker提交位移。同样地，当Consumer应用启动时，也是向Coordinator所在的Broker发送各种请求，然后由Coordinator负责执行消费者的注册、成员管理记录等元数据管理操作。
所有Broker都有各自的Coordinator组件。Consumer通过partitionId=Math.abs(groupId.hashCode() % offsetsTopicPartitionCount)。确定由哪个分区来保存该Group数据，然后找出该分区Leader副本所在的Broker，该Broker即为对应的Coordinator。如果Consumer Group出现问题，可以直接定位到对应Broker进行查看日志定位问题。
