Kafka设计原理解析--broker设计

背景

上一章简单讲了下producer设计的大体思路，当数据被producer之后，就是broker的主要工作了，broker是kafka里面的核心，主要是负责了消息的接收，存储，以及跟consumer的交互。我们可以想一下，在设计broker的时候，面临哪些问题呢？第一个是谁要接收数据？接收到数据之后如何存储？数据丢失怎么办？怎么能优化速度么？下面根据上面的思路，来看下broker的设计。

谁要接收数据？

设计演变

一个消息队列，本质也就是接收消息存储，然后再给别人读，脑门一拍，简单嘛，看我的设计

满足了接收消息，被消费，一台机器搞定了，但是这个会不会有问题呢？如果消费者生产者有多个怎么办？都写在一个队列里面么？这个队列被所有人读，岂不是数据就乱七八糟了，你思考了片刻，说，那就给多个队列么，这样就好了

是不是满足多个消费了，并且还完全的不干扰，但是需要思考另外的问题是，这是一台机器，如果生产者消费者多的话，一台机器搞得定么？网络连接，磁盘之类的，能搞定么，压力会很大。这时候，你会很自然想到分布式，那就多台机器嘛，看我分分钟给设计出来。

看，满足了，性能还是杠杠的，分布式的设计。这种设计看起来没问题，但是如果producer很多很多，上百成千，那就搞这么多机器么，是不是太浪费了，能不能用比较少的机器，干最大的活呢？并且，如果某一个队列消息丢失，或者挂了怎么办？是不是这种结构就不满足了。正是因为上面的问题，kafka的broker设计才会最终是如下图的样子：

上面设计的好处是，每台机器都有备份，如果要发送的话，可以建立很多的队列，并且也不用集中在一台机器上去链接。

乱乱乱！！

机器多了，队列也多了，这么多人，怎么管理？谁去接收哪个消息？太乱了！！这时候就会面临上面的这些问题，那要怎么解决这些问题呢