存储
Kafka 文件布局
Kafka 文件在宏观上的布局如下图所示:
正如上图所示,Kafka 文件布局的主要特征如下:
文件的组织以 topic + 分区进行组织,每一个 topic 可以创建多个分区,每一个分区包含单独的文件夹,并且是多副本机制。即 topic 的每一个分区会有 Leader 与 Follow,并且 Kafka 内部有机制保证 topic 的某一个分区的 Leader 与 follow 不会存在在同一台机器,并且每一台 broker 会尽量均衡的承担各个分区的 Leader,当然在运行过程中如果不均衡,可以执行命令进行手动重平衡。Leader 节点承担一个分区的读写,follow 节点只负责数据备份。
Kafka 的负载均衡主要依靠分区 Leader 节点的分布情况。
分区的 Leader 节点负责读写,而从节点负责数据同步,如果Leader分区所在的Broker节点发生宕机,会触发主从节点的切换,会在剩下的 follow 节点中选举一个新的 Leader 节点,其数据的流入流程如下图所示:
分区 Leader 收到客户端的消息发送请求时,是写入到 Leader 节点后就返回还是要等到它的从节点全部写入后再返回,这里非常关键,会直接影响消息发送端的时延,故 Kafka 提供了 ack 这个参数来进行策略选择:
ack = 0不等broker端确认就直接返回,即客户端将消息发送到网络中就返回发送成功。
ack = 1 Leader 节点接受并存储后向客户端返回成功。
ack = -1 Leader节点和所有的Follow节点接受并成功存储再向客户端返回成功。
RocketMQ 文件布局
RocketMQ 的文件布局如下图所示:
RocketMQ 所有主题的消息都会写入到 commitlog 文件中,然后基于 commitlog 文件构建消息消费队列文件(Consumequeue),消息消费队列的组织结构按照 /topic/{queue} 进行组织。从集群的视角来看如下图所示:
RocketMQ 默认采取的是主从同步,当然从RocketMQ4.5引入了多副本机制,但其副本的粒度为 Commitlog 文件,上图中不同 master 节点之间的数据完成不一样(数据分片),而主从节点节点数据一致。
RocketMQ的高性能在于顺序写盘(CommitLog)、零拷贝和跳跃读(尽量命中PageCache),高可靠性在于
刷盘和Master/Slave