周末两天闲着无聊看了下kafka源码和一些大佬的分析,下面是一些知识点或者案例的整理,希望能帮上最近面试的各位读者。
![4e69d41d8d435a4efb83d942056d3f8e.png](https://i-blog.csdnimg.cn/blog_migrate/a5429eac0cbae78ef063ae12b6ce7286.jpeg)
案例一、
partition 10个,consumer设置多少合适
看qps以及处理速度,一个patition最多被一个实例消费,如果qps很低,一台机器就足够,为了容错最少两台机器消费。如果单个patitionqps很高,消费容易出现lag,可以先扩容partition,把机器数量加到和partition一样。
![ef6eadb00c31f031511efaba89a9c339.png](https://i-blog.csdnimg.cn/blog_migrate/7ea43e37735c73aab3a394d8b5530ad1.jpeg)
案例二、
如何实现exactly once?
主要是通过增加额外的状态保证
1.peoducer增加producerid,没有producer发送时需要保证消息重试的消息不会重复生产offset,所以在peoducer中有一个自增id和消息绑定,在server端收到消息如果有乱序就返回客户端失败,这样可以保证发送端的消息不会重复。
2.发送时采用两阶段发送,prepare时写入transaction state 一条消息,然后发送消息,提交事务时写入transaction state precommit,在向每个patition的leader节点发送事务commit的消息,最后写入transaction state commit消息。
consumer 在消费时,如果消费到没有commit的消息会把消息放在内存里,直到遇到上面patition 内的事务终结消息,这样可能导致oom提交 transaction state 先precommit再commit,是为了避免在发送给leader是,其中一个leader故障,导致消息回滚。消息一旦进入precommit状态,理论上最后一定会commit。
![98cf8d7e1a9cbcb910924f2662ee9a27.png](https://i-blog.csdnimg.cn/blog_migrate/69ee4f920cd478eddb69b0d87f0c0c74.jpeg)
案例三、
消息积压怎么解决,消息失效怎么解决
这是一个容量评估的问题,消息积压consumer group中的机器数量是否超过partition,如果超过partition,扩容partition。如果机器比较少先扩容机器。抗过这一波优化代码,加快单个partition的消费速度,这个就各显神通了。
![36623cbf12a1a3bb838366807fabd8d7.png](https://i-blog.csdnimg.cn/blog_migrate/0760c33e1220f1297c8eea1cabb6b7b9.jpeg)
案例四、
kafka怎么保证单partition有序的
kafka的日志是顺序存储,offset小的消息一定先落盘,大的后落盘,这样保证存储有序。消费fetch数据时,server端按照offset查找index找到数据的偏移,按照偏移顺序遍历日志返回给consumer,从而保证顺序行。kafka producer 发送消息到broker然后持久化的过程中单纯的发送行为不能保证顺序行。
通常来说的顺序行是产生的带发送的数据是有序的,按照顺序发送数据,这样消费端消费到的数据也会是有序的,比如按照binlog同步数据的场景。
不是专业做kafka的,如果上述中有错误或者考虑不充分的欢迎评论区讨论哈。