TimzzZ的博客

一、前言一个商业化消息队列的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。 下面将从Kafka文件存储机制和物理结构角度，分析Kafka是如何实现高效文件存储，及实际应用效果。分析过程 topic中partition存储分布 partiton中文件存储方式 partiton中segment文件存储结构 在partition中如何通过offset查找message 二、

kafka存储Kafka的存储布局非常简单。话题的每个分区对应一个逻辑日志。物理上，一个日志为相同大小的一组分段文件。每次生产者发布消息到一个分区，代理就将消息追加到最后一个段文件中。当发布的消息数量达到设定值或者经过一定的时间后，段文件真正写入磁盘中。写入完成后，消息公开给消费者。 与传统的消息系统不同，Kafka系统中存储的消息没有明确的消息Id。消息通过日志中的逻辑偏移量来公开。这样就避免了

一、入门1、简介Kafka 是linkedin 公司用于日志处理的分布式消息队列，同时支持离线和在线日志处理。kafka 对消息保存时根据Topic进行归类，发送消息者成为Producer,消息接受者成为Consumer,此外kafka 集群有多个kafka 实例组成，每个实例(server)称为broker。无论是kafka集群，还是producer和consumer 都依赖于zookeeper

我们知道，在早期的RocketMQ版本中，是有依赖ZK的。而现在的版本中，是去掉了对ZK的依赖，转而使用自己开发的NameSrv。并且这个NameSrv是无状态的，你可以随意的部署多台，其代码也非常简单，非常轻量。那不禁要问了：ZooKeeper是业界用来管理集群的一个非常常用的中间件，比如Kafka就是依赖的ZK。那为什么RocketMQ要自己造轮子，自己做集群的管理呢？纯粹就是再做一个Zooke