简述

Kafka是一个分布式流处理平台，它诞生自日志聚合案例。它不需要太高的并发性。在阿里的大规模案例中，我们发现

原始模式不能满足我们的事件需求。因此，我们开发了一个名为RocketMQ的消息中间件，来解决更广泛的使用场景，从传统的发布/订阅情景到超大容量的不容忍消息丢失的事物系统。现在，在阿里，RocketMQ集群每天处理超过5000亿次事件，为3000多核心应用提供服务。

kafka的分区设计

1. 生产者的并行写受分区数量的限制。
2. 消费者的消费并行级别同样受到消费分区数量的限制。假设最大分区数量是20，当前消费中的消费者最大数量也只能是20.
3. 每个主题由固定数量的分区组成。分区数量决定单个broker可能拥有的最大主题数，而不会显著的影响性能。

更多详情请参考

为什么Kafka不支持更多分区

1. 每个分区都存储着所有的消息数据。尽管每个分区都按照顺序写盘，但随着并发写入分区的数量增加，从操作系统层面来说，写入就变的随机。
2. 由于数据文件的分散，使用Linux IO组提交机制会比较困难。

Rocket如何支持更多分区？

1. 所有的消息数据存储在提交日志文件。所有的写操作都是完全有序的，而读操作是随机的。
2. 消费队列存储用户实际消费位置信息，这些消息也可以以顺序方式刷到磁盘。

优势

1. 每个消息队列都是轻量级的，并且包含有限的元数据。
2. 访问磁盘是完全按序的，这也会避免磁盘锁的争夺，当大量队列被创建也不会引发高磁盘IO等待。

劣势

1. 消息消费会首先读取消费队列，然后是提交日志。这个过程将会带来一定的成本，在最坏的情况下。
2. 提交日志和消费队列需要保证逻辑一致，这将会给编程模型带来额外的复制性。

动机

1. 随机读。尽可能多的读取以提高页面缓存的命中率，减少读取IO操作。因此大容量内存依然是更可取的。如果大量消息堆积，读性能会不会下降很严重？答案是否定的，理由如下：

1,即使消息的大小只有1KB，系统也会提前读取更多数据。这意味着后续数据的读取，这将访问主存储器，而不是缓慢的磁盘IO读取。2,从磁盘随机访问提交日志。在SSD情况下将I/O调动程序设置为NOOP，读qps将显著提速，这样会比电梯调度算法更快。

1. 鉴于消费队列仅保存固定大小的元数据，主要用来记录消费进度，因此会很好的支持随机读。拥有页面缓存预取的优势，访问消费队列同访问主内存一样快，即使在大量消息堆积的情况下。作为结果，消费队列不会对读性能带来明显的损失。
2. 提交日志保存几乎所有的信息，包括消息数据。类似关系数据库的重做日志，只要提交日志存在，消费队列，消息健索引和所有其他所需数据都能被完全恢复。