03_kafkaMQ高可用架构及常见生产问题及其解决方案

数据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