例如说这个消息身上的系统,我们从以下几个角度来考虑一下:
-
首先这个mq得支持可伸缩性吧,就是需要的时候快速扩容,就可以增加增量和容量,那怎么搞?设计个分散的系统呗,参照一下kafka的设计理念,经纪人->主题->partition,每个partition放一个机器,就存一部分数据。如果现在资源不够了,简单啊,给topic增加partition,然后做数据迁移,增加机器,不就可以存放更多数据,提供更高的破坏了?
-
那肯定要了,落磁盘能力保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊?顺序写,这样就没有磁盘随机读写的预期开销,磁盘顺序读写的性能是很高的,这就是kafka的思路。
-
这个副本,>领导者和跟随者->经纪人挂了重新选举领导者可以随时对外服务。这件事儿,具体参考之前可用那个间接讲解的kafka的高可用保障机制。
-
能不能支持数据0丢失啊?可以的,参考我们之前说的那个kafka数据零丢失方案。
-
mq肯定是很复杂的,面试官问你这个问题,其实是个开放题,他就是看看你有没有从架构角度整体构思和设计的思维以及能力。确实这个问题可以刷掉一大批人,因为大部分人平时不思考这些东西。