kafka学习笔记（5）——基本架构

   在B站尚硅谷学习Kafka时记录一下笔记，感兴趣的可以去看原视频
【尚硅谷Kafka教程，2024新版kafka视频，零基础入门到实战】 

---

 基本架构

 上面这张图是之前学习kafka的简单示意图，为了方便只有一个生产者和一个消费者，但是在实际开发中肯定是不止这点的，而且kafka可是号称10万级的吞吐量。

那么就有问题了，在搭建kafka时如果就一个broker，当数据吞吐量过大时肯定是忙不过来的，而且一旦其崩溃了，那么所有的数据交互就全部罢工了。

为了解决这一问题，提出了两种方法，一种是增强其性能，让它更给力；一种是人多力量大，给它多来几个broker。

第一种只能是治标不治本，在强悍的机器也会有崩溃的一天；第二种就成为了普遍的解决方案了。

 所以就引申出了下面这张图的kafka架构示意图：（还是从简。。。）

•  首先我们可以看到增加了broker，将多个broker统称为kafka集群（最上面只漏出一半的那里）
• 其次发现topic被分成了几个部分，因为如果只是增加broker的话，其实没什么变化，因为生产者消费者都是在同一个topic下进行数据生产消费的，不把topic切分开那么他们还是全都跑到同一个broker中。
  这里被分开的topic在kafka中就是用partition来表示了，也就是“分区”的概念。
• 目前为止，吞吐量过大的问题算是缓解了，那么当某一个broker崩溃时要怎么解决呢？
• 之前提到过kafka虽然是在内存中进行数据的读写，但仍然会在磁盘保存数据，这就是.log文件了。不过当这个broker崩溃了，其服务已经停止，也没办法访问其log文件了，这该怎么办呢
• 很简单，每个broker除了保存自己的log文件，在额外保存其他broker的log文件副本，这样当某个broker停止服务了，还可以通过其他的broker保存的副本访问其中的数据。
  这里的副本文件在自己的broker中叫做leader副本，而在其他broker中叫做follower副本。

 选举

kafka集群中有那么的broker，为了方便管理就需要设置一个“大哥”，这个设置的“大哥”叫做controller控制器，通过它可以知道集群中的其他broker的状态（关闭、无法连接、正常、新增等）

 “小弟”出了问题还有其他的“小弟”顶上，如果“大哥”倒了呢？

按照集群的普遍思想，给“大哥”弄一个备份是很正常的思路。可是如果“二哥”也倒了，甚至于“三哥”“四哥”，我们总不能设置∞的备份吧？

  这种时候只需要转变一下思路，“王侯将相宁有种乎”？让下面的小弟也有机会过一把瘾

可是该让哪一个上位？为了公平起见，就需要第三方登场了，那就是ZooKeeper。

通过zookeeper的选举机制从集群中选一个broker作为Master。

 如果其他的broker也都無了呢？那就完犊子了呗

架构图