Kafka进阶问题

Kafka核心概念？
1.Broker
一台Kafka服务器就是一个broker。一个集群由多个broker组成。
2.Topic
Topic就是数据主题，Kafka建议根据业务系统将不同的数据放在不同的Topic中！Kafka中的Topics总是多订阅者模式，一个topic可以拥有一个或者多个消费者来订阅它的数据。一个大的Topic可以分布式存储在多个Kafka broker中。Topic可以类比数据库中的库。
3.Partition
每个topic可以有多个分区，通过分区的设计，topic可以不断进行扩展。即一个topic的每个分区分布式存储在多个broker。
此外通过分区还可以让一个topic被多个consumer消费。以此达到并行处理！分区可以类比为数据库据的中表。
Kafka只保证一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。
4.offset
数据会按照时间顺序被不断追加到分区的一个结构化的commit log中。每个分区中存储的记录都是有序的，且顺序不可变。
这个顺序是通过一个称之为offset的id来唯一标识。一次也可以认为offset是有序且不可变的。
在每一个消费者端，会唯一保存的元数据是offset（偏移量），即消费在log中的位置/偏移量 由消费者所控制。通常在读取记录后，消费者会以线性的方式增加偏移量，但是实际上，由于这个位置由消费者控制，所以消费者可以采取任何顺序来消费记录。例如，一个消费者可以重置到一个旧的偏移量，从而重新处理过去的数据；也可以跳过最近的记录，从“现在”开始消费。
这些细节都说明Kafka消费者是非常廉价的——消费者的增加和减少，对集群或者其他消费者没有多大的影响。比如，你可以使用命令执行工具，对一些topic内容执行tail操作，并不会影响已存在的消费者消费数据。
Topic拓扑机构
数据流

持久化
Kafka集群保留所有发布的记录——无论他们是否已被消费——并通过一个可配置的参数——保留期限来控制。举个例子，如果保留策略设置为2天，一条记录发布后俩天内，可以随时被消费，两天过后这条记录会被清楚并释放磁盘空间。
Kafka的性能和数据大小无关，所以长时间存储没有什么问题。
副本机制
日志的分区partition（分布）在Kafka集群的服务器上。每个服务器在处理数据和请求时，共享这些分区。每个分区都会在已配置的服务器上进行备份，确保容错性。
每个分区都有一台server作为“leader”，零台或者多台server作为follwers。leader server处理一切对partition（分区）的读写请求，而followers只需被动的同步leader上数据。当leader宕机了，followers中的一台服务器会自动成为新的leader。通过这种机制。既可以保证数据多个副本，也可以实现了一个高可用的机制。
基于安全考虑，每个分区的leader和follower一般会错在不同的broker.
Producer
消息生产者，就是向Kafka broker发消息的客户端。生产者负责将记录分配到topic中的指定partition中。
Consumer Group
每个消费者都会使用一个消费组名称来进行标识。同一个组中的不同消费者为例，可以分配在多个线程或者多个机器上。
如果所有的消费者实例在同一消费组中，消费记录会负载均衡到每一个消费者实例。即每个消费者都可以同时读取一个topic一个分区。
如果所有的消费者实例在不同的消费组中，每条消息记录会广播到所有的消费者进程。
如果需要实现广播，只要每个consumer有一个独立的组就可以了。要实现单播只要所有的consumer在同一个组。
一个topic可以有多个consumer group。topic的消息会复制（不是真的复制，是概念上的）到所有的CG，但每个partition只会把消息发给该CG中的一个consumer。
Kafka的基础架构