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所以消耗系统内存比较大 |