因业务需要而对消息中间件的频繁使用后，每次总会问自己一个问题：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的解决方案等等。
