因业务需要而对消息中间件的频繁使用后,每次总会问自己一个问题:kafka为什么快?然后再去背一背八卦找找答案。直到近日终于能站在一个新奇的角度理解kafka,且积累的各种细节串通了起来,实属惊喜。
回到最开始的问题:kafka为什么快?或者换个问法,为何使用kafka?再换个问法,如果你是产品经理,你会如何使用kafka?是不是一头雾水,不知道从什么角度回答,有种说不出接口的感觉。其实你是知道的,就差将这些理解串起来。
记住这三个问题。提到kafka,就离不开kafka的三个关键概念:partition(分区),broker(代理)、副本。
现在将自己当成一个产品经理,产品中涉及到多个微服务,服务之间需要传递消息,服务会发送消息,也会接收消息,那么如何管理消息(生产-消费)是我们要解决的
最开始我们只有一台机子,所有相同的消息放在一个队列中,例如支付相关的消息对应一个队列,队列取名为Topic A;
发送的消息尾追队列,需要处理的消息按顺序从头消费。
后来,发现用户太多,都在排队等一个队列,效率不高。因此,建议将支付相关的消息平均存放在多个队列中,这样就保证可以多个消息一起处理。这就是分区 partition
后来,发现即使分区了,所有消息的读写压力都在服务器1上,因此购入服务器2希望分担一下压力。
如将Topoc A的部分 分区放到服务器2上。这就是 分区可以在多个服务器上
此时,我们就要考虑安全因素了。万一服务器1宕机了,岂不是消息都丢失了,服务器2也只能干着急,帮不了一点忙。因此需要将消息进行备份,且将备份的数据放在其他服务器上。
生产者 生产了消息------->将其保存到副本1(副本1:Leader)-----副本1同步给副本2(副本2:Follower)----副本1同步给副本3(副本3:Follower)
这些副本其实就是保存消息的文件
这样,即使服务器1宕机了,也就是副本a1-1 的消息丢失了,服务器2的副本a1-2 就变成了新的Leader,重启服务器1后,生产者与新的leader交互。这就是 多副本
此外,产品越做越大,不同类别的消息越来越多,有支付类的TopicA ,有音频类的 TopicB,有图文类的Topic C。定义一个控制器(Broker),让其负责这些Topic的创建、保证消息负载均衡的分配在多个分区。(如按照轮询策略,将第一条消息放在分区a1,第二条消息放在分区a2,第三条消息放在分区a1...还有其他的分配方式,可以指定不同的分区器)这就是Broker
此时还要考虑安全,万一服务器broker1失效了,怎么办
分区、多副本、Broker这三个概念就是kafka的核心。
根据业务发展,从0到1渗透讲解kafka是如何实现消息管理。
现在回到前面的问题:
kafka为什么快?或者换个问法,为何使用kafka?再换个问法,如果你是产品经理,你会如何使用kafka?
立马想到分区、多副本、Broker,并能结合业务讲出自己的理解,这些问题都可以不攻自破!
在此基础上,可以深究Api使用、多业务场景下kafka的解决方案等等。