有幸公司已有搭建好的kafka服务器，这里和大家边学边看
springboot2
kafka基础：摘录的别人介绍
Replication & Leader election（涉及到zookeeper核心问题，不是很明白）
Kafka通过Zookeeper管理集群配置，选举leader，以及在consumer group发生变化时进行rebalance。producer使用push模式将消息发布到broker，consumer使用pull模式从broker订阅并消费消息。
重要1点，kafka发送消息通道不会被马上清除，可以使用kafkaTool2直观看到数据
- Broker
Kafka集群包含一个或多个服务器，这种服务器被称为broker - Topic
每条发布到Kafka集群的消息都有一个类别，这个类别被称为topic。（物理上不同topic的消息分开存储，逻辑上一个topic的消息虽然保存于一个或多个broker上但用户只需指定消息的topic即可生产或消费数据而不必关心数据存于何处） - Partition
parition是物理上的概念，每个topic包含一个或多个partition，创建topic时可指定parition数量。每个partition对应于一个文件夹，该文件夹下存储该partition的数据和索引文件 - Producer
负责发布消息到Kafka broker - Consumer
消费消息。每个consumer属于一个特定的consuer group（可为每个consumer指定group name，若不指定group name则属于默认的group）。使用consumer high level API时，同一topic的一条消息只能被同一个consumer group内的一个consumer消费，但多个consumer group可同时消费这一消息。
Consumer group（消息组）
这个我刚遇到的坑，所以比较了解：分组可确保同组的一个topic只能被一个同组组员所消费（分布式常用到）,一个topic可以被不同分组的的consumer分别消费
Consumer Rebalance
分布式中可能有多个kafka服务器，实际上一个消费者只能消费一个服务器的topic,要保证所有kafka里相同的topic都能被消费,所以需要增加控制策略
- Herd effect
任何broker或者consumer的增减都会触发所有的consumer的rebalance - Split Brain
每个consumer分别单独通过Zookeeper判断哪些partition down了，那么不同consumer从Zookeeper“看”到的view就可能不一样，这就会造成错误的reblance尝试。而且有可能所有的consumer都认为rebalance已经完成了，但实际上可能并非如此。
消息Deliver guarantee
这消息的几种方式
At most once消息可能会丢，但绝不会重复传输At least one消息绝不会丢，但可能会重复传输Exactly once每条消息肯定会被传输一次且仅传输一次，很多时候这是用户所想要的。