数据1
消费者
数据库
一台机器
5、topic1的partition3所在的机器死掉了、那partiion3的leader就没了，此时是不能读写数据的。
thread
3、返回写入成功
生产者
快速处理积压的消息
数据1，offset=152
数据1，offset=153
broker3partition1
........
写入数据3
数据3，offset=154
此时高可用架构出来了，假设一台机器宕机了，上面的leader就没了，但此时别的机器 上还有follower，kafka会自动感知leader死了，会将其他follower选举一个为leader
broker2partition1
数据2
说明：因消费者故障导致几百万数据积压在MQ中，现消费者已经恢复正常，现在的问题是如何快速将几百万数据处理掉
解决方案：新建一个topic，新建30个partition和30个消费者，将之前的消费者消费处理逻辑改成发送到新的topic中，这个就以10倍的速度处理积压的消息。处理完积压的消息后将架构恢复正常
内存队列1
说明：zk里记录了，消费者当前消费到了offset=N的记录
说明：写入一个partition中的数据一定是有顺序的。生产者在写的时候可以指定一个key比如说指定某个定单id为key这个订单相关的数据一定会分发到同一个partition中消费者从一个partition取出的数据一定是有顺序的一个Partition只能被一个消费者消费
说明：假如消费者重启了，消费者会向kafka说，Hi哥们你接着把我消费位置之后的数据传递过来。 假设消费一条数据是往数据库里插入一条数据，如果重复消费后会导致同一条数据插入2次，从而导致你的数据错误。
follower -> leader
数据丢失的场景
数据3
kafka重复消费问题
数据2，offset=153
broker进程
kafka
说明：假设创建了一个topic1，指定其partition是3个。 broker进程就是，kafka在机器上启动的一个自己的进程。 每台机器+机器上的broker进程，可以视为kafka集群中的一个节点。
broker3topic1partition1副本3follower
问题2：生产者发送消息给kafka ，消息发到leader，消费还未同步到follower，broker1 宕机，然后重新选举leader。此时其他的follower刚好数据1未同步。然后选举某个follower成leader之后，数据1就丢失了。
说明：每条消息都有一个offset，代表了这个消息的顺序的序号
问题2解决方案：一般是要求起码设置如下4个参数：给topic设置replication.factor参数：这个值必须大于1，要求每个partition必须有至少2个副本在kafka服务端设置min.insync.replicas参数：这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系，没掉队，这样才能确保leader挂了还有一个follower吧在producer端设置acks=all：这个是要求每条数据，必须是写入所有replica之后，才能认为是写成功了在producer端设置retries=MAX（很大很大很大的一个值，无限次重试的意思）：这个是要求一旦写入失败，就无限重试，卡在这里了这样配置之后，至少在kafka broker端就可以保证在leader所在broker发生故障，进行leader切换时，数据不会丢失
topic1partition3副本2
follower
broker1partition1
1、写入数据1
选举为leader
数据1，offset=154
kafka的高可用架构
zookeeper
说明：消费者从kafka去消费时是按offset顺序去消费的。消费者会去提交offset，就是告诉kafka我已经提交到这条数据了。消费者不是消费完一条数据就提交offset的而是定时定期一次性提交。
写入数据2
topic1partition3副本1
问题1：消费者消费到了这个消息，然后消费者自动提交了offset，让kafka以为消费者已经消费好了这个消息，其实消费者正准备处理这个消息，还没处理，就挂了，此时这条消息就丢咯。
问题：假如消费者将要提交，但还未提交offset数据时，消费者进程被重启了，那么此时已经消费过的数据的offset并没有提交，kafka也就不知道你已经消费了那些未提交offset的数据。消费者重启后，kafka会重新发送最大提交offset之后的数据，而未提交offset的会重新发送。
消息顺序不对场景
7、生产者感知到leader，开始写数据
topic1partition2副本2
保证消息顺序方案
消费者只能从Leader消费数据，不能从foller读数据
broker30partition1
8、消费者从leader消息数据
broker2topic1partition1副本2follower
4、消息者从leader消息数据1
MQ积压几百万消息场景
拓画布者
说明：按照数据进入kafka的顺序，kafka会给每条消息分配一个offset代表了这个是数据的序号
6、同时kafka会感知到partition3的leader死了，把folloer选举成leader
broker1topic1 partition1副本1leader
topic1partition1副本1
topic1partition1副本2
问题1解决方案：因为kafka会自动提交offset，所以只要关闭自动提交offset，在处理完之后自己手动提交offset，就可以保证数据不会丢。但是此时确实还是会重复消费，比如你刚处理完，还没提交offset，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。
topic1partition2副本1
生产者往topic1写了3条数据
2、写入数据1时，leader会将数据1同步到follower
