kafka与rocketMq的存储对比

Mq	结构	存储	优缺点
kafka	topic对应多个partition 同一个服务器（broke）会有多个 不同topic-partition对，patition为单主多从结构 主挂了会重新选主	消息直接存储在partition中， 对单topic为顺序写	缺点：如果服务器承载的topic过多，相应的patition也会变多，因此会造成随机写，导致io效率降低 优点：直接从partition顺序读取数据，效率高
rocketmq	topic对应多个consumequeue， 同一个服务器会有不现的 topic-consumerqueue对，consumerqueue为多主多从结构 主由配置指定，主挂了其它主提供服务。	同一个服务器的所有消息 都统一写到commitlog中 consumequeue只存储在 CommiLog中的起始offset，log大小和MessageTag的 hashCode，数据量较少	优点：因为consumequeue数据量小，绝大部分的访问还是Page Cache的访问，而不是磁盘访问。正式部署也可以将CommitLog和consumerQueue放在不同的物理SSD，避免多类文件进行IO竞争。 Commit Log中存储了所有的元信息，包含消息体，类似于Mysql、Oracle的redolog，所以只要有Commit Log在，Consume Queue即使数据丢失，仍然可以恢复出来 缺点：读取消息时，由于不同的topic消息都写在同一个文件，导致读取顺序不连续，造成随机读，降低了读IO，为了优化这个问题rocketmq会预读取更多的数据到pagecache所以消耗系统内存比较大

 

转载于:https://my.oschina.net/laigous/blog/3079368