1、适用场景 kafka适合日志处理 rocketmq适合业务处理 结论：两者没有区别，根据具体业务定夺 2、性能 kafka单机写入TPS号称在百万条/秒 rocketmq大约在10万条/秒 结论：追求性能方面，kafka单机性能更高 3、可靠性 kafka使用异步刷盘方式，异步Replication rocketmq支持异步/同步刷盘，异步/同步Replication 结论：rocketmq所支持的同步方式提升了数据的可靠性 4、实时性 kafka和rocketmq均支持pull长轮询，rocketmq消息实时性更高 结论：rocketmq胜出 5、支持的队列数 kafka单机超过64个队列/分区，消息发送性能降低严重 rocketmq单机支持最高5W个队列，性能稳定 结论：长远看，rocketmq胜出， 6、消息顺序性 kafka某些配置下，支持消息顺序，但是一台Broker宕机后，就会产生消息乱序 rocketmq支持严格的消息顺序，一台Broker宕机后，发送消息会失败，但是不会乱序 结论：rocketmq胜出 7、消息失败重试机制 kafka消费失败不支持重试 rocketmq消费失败支持定时重试，每次重试间隔时间顺延 8、定时/延时消息 kafka不支持定时消息 rocketmq支持定时消息 9、分布式事务消息 kafka不支持分布式事务消息 rocketmq未来会支持 10、消息查询机制 kafka不支持消息查询 rocketmq支持根据message id查询消息，也支持根据消息内容查询消息 11、消息回溯 kafka可以按照offset回溯消息 rocketmq支持按照时间回溯消息，例如从一天之前的某时某分开始重新消费消息 问题一：push和pull模式 push模式：客户端与服务端建立连接后，当服务端有消息时，将消息推送到客户端 pull模式：客户端不断的轮询请求服务端，来获取新的消息 在具体实现时，push和pull模式都是采用消费端主动拉取的方式，即consumer轮询从broker拉取消息 区别： push 方式中，consumer把轮询过程封装了，并注册了MessageListener监听器，取到消息后，唤醒MessageListener的consumerMessage来消费，用户而言，觉得消息被推送过来的 pull方式中，取消息的过程需要用户自己写，首先通过打算消费的Topic拿到MessageQueue的集合，遍历MessageQueue集合，然后针对每个MessageQueue批量获取消息，一次取完之后，记录该队列下一次要取的开始offset，直到取完了，再换另一个MessageQueue 疑问：既然都是采用pull方式实现，rocketmq怎么保证消息的实时性？ 长轮询：rocketmq时采用长轮询的方式实现的，指的是在请求的过程中，若是服务器端数据并没有更新，那么则将这个连接挂起，直到服务器推送新的数据，再返回，然后进入循环周期 客户端像传统轮询一样从服务端请求数据，服务端会阻塞请求不会立刻返回，直到有数据或者超时才返回给客户端，然后关闭连接，客户端处理完响应信息后再向服务器发送新的请求
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/182023.html原文链接：https://javaforall.cn
