dockerhub 上kafka 相关镜像有 wurstmeister/kafka 和 bitnami/kafka 这两个用的人比较多,大概看了下 bitnami/kafka 更新比较频繁就选这个了。 监控的话 hlebalbau/kafka-manager 这个比较好用，其他的都太久没更新了。 不过 kafka-manager 除了监控外还可以进行操作，其实不太好，监控一般就只是纯监控比较好，所以有 prometheus+grafana 监控体系的直接用 kafka_exporter 会舒服很多。
standalone consumer
ConsumerGroup 一组只对一个消息消费一次
Coordinator 是一个服务，每个Broker在启动的时候都会启动一个该服务
Coordinator的作用是用来存储Group的相关Meta信息，并将对应Partition的Offset信息记录到Kafka内置Topic__consumer_offsets中
Kafka在0.9之前是基于Zookeeper来存储Partition的Offset信息 consumers/{group}/offsets/{topic}/{partition}
因为ZK并不适用于频繁的写操作，所以在0.9之后通过内置Topic的方式来记录对应Partition的Offset。
一组 ConsumerGroupClaim 的这一轮的生命周期称作一个 session
每个 partition 与 consumer 的分配关系称作一个 "claim"
重平衡，消费者组内的成员增减，导致组内的成员需要重新调整他需要负责的消费的分区，具体流程如下：
- 1）一个新的 Consumer 想要加入 ConsumerGroup，发起 JoinGroup 请求；
- 2）Kafka 将 ConsumerGroup 设置为 PreparingRebalancing 状态，递增 ConsumerGroup 的 generation 值，通过心跳的响应通知现所有成员退出，等待它们重新加入
- 3）选举其中一位成员成为 ConsumerGroup 的 leader；
- 4）为所有的成员发送 Join 成功的元信息；
- 5）Follower 向 Coordinator 发送同步请求申请同步 Partition 分配关系；
- 6）Leader 按 Balance 策略生成 Partition 的分配关系，向 Coordinator 发送 SyncGroup 请求发送分配关系；
- 7）Coordinator 返回所有成员各自的 Partition 分配关系
broker 集群中的单个实例，通常和 server 划等价，一个服务器即一个broker
topic 消息主题,和其他MQ一致
partition 分区, 存储消息的单元 每个 partition 对应磁盘上的一个文件 消息写入就是简单的文件追加 文件可以在集群内复制备份以防丢失 即使消息被消费，kafka 也不会立即删除该消息 可以通过配置使得过一段时间后自动删除以释放磁盘空间 offset 消息在 partition 中的标识称为 offset，含义等价于 ID
replicated 副本。可以配置 partitions 需要备份的个数 每个 partition 将会被备份到多台机器上，以提高可用性 备份的数量可以通过配置文件指定
这种冗余备份的方式在分布式系统中是很常见的 既然有副本，就涉及到对同一个文件的多个备份如何进行管理和调度 kafka 采取的方案是：
- 每个 partition 选举一个 broker 作为“leader”
- 由 leader 负责所有对该分区的读写
- 其他 server 作为 follower 只需要简单的与 leader 同步，保持跟进即可
- 如果原来的 leader 失效，会重新选举由其他的 follower 来成为新的 leader
metadata 元数据
集群中的每一个broker都保存着相同的完整的整个集群的metadata metadata信息里包括了每个topic的所有partition的信息: leader, leader_epoch, controller_epoch, isr, replicas等 Kafka客户端从任一broker都可以获取到需要的metadata信息