kafka与rocketMq的存储对比 原
欢迎来到阿八个人博客网站。本 阿八个人博客 网站提供最新的站长新闻,各种互联网资讯。 喜欢本站的朋友可以收藏本站,或者加QQ:我们大家一起来交流技术! URL链接:https://www.abboke.com/jsh/2019/0726/102332.html
挑战A.I.,赢百万奖金......了解更多详情>>>
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所以消耗系统内存比较大 |