赞
踩
目录
MQ全称 Message Queue,也就是消息队列,是应用程序之间的通信方法。
MQ使用的业务场景:
Kafka和RocketMQ都是基于发布/订阅模式的消息系统,但是在架构上有如下不同:
Kafka:
RocketMQ:
Kafka和RocketMQ都是高可靠性的消息系统,但是他们在可靠性上还是有一定差异:
在数据可靠性方面,Kafka表现更为出色,主要是因为Kafka在Broker的数据模型存储上采用了多副本机制,每个Partition都有多个副本,当某个Broker节点失效时,可以通过其他的副本来保证数据的可用性。而RocketMQ采用则是主从复制的特性,当主节点失效时,需要进行主节点选举才能保证保证数据的可用性,在这个进行选举的期间就会存在着一定的延迟,而延迟则就可能会导致消息的丢失。
消息大小都以10个字节为例。
Kafka和RocketMQ都是高吞吐,低延迟的消息系统,以下是他们之间的差异:
在吞吐量方面,Kafka表现更加出色。Kafka的使用顺序写磁盘的方式存储消息,因为这一特性,可以达到非常高的吞吐量,而且在读取方面也能够达到非常高的性能。RocketMQ虽然也使用了顺序写磁盘的方式存储消息,但是其读取性能会不如Kafka,尤其是在批量处理的情况下。
在延迟方面,不得不提及RocketMQ的表现十分出色,RocketMQ通过采用 零 Copy技术和缓存池技术来降低延迟,而Kafka则是通过批量发送和异步处理的方式来提高吞吐量,但相应的会增加一定的延迟。
目录
在这里就要提出RocketMQ的强大重试机制,举例这样一个场景:
A服务为下单服务,B服务为积分服务,A服务此时调用下单一系列功能完成后,为了进行流量的削峰处理,此时我们引入MQ的中间件,A服务生产消息,发送至MQ中,B服务去消费消息,进行积分服务一系列功能处理。 但是这个B服务尝试去从MQ去消费这个过程,由于网络或者B服务延迟问题,导致MQ的这条消息消费失败。
此时引用RocketMQ利用MQ的消费失败重试机制,就可以很好的处理这个问题,但是Kafka并不能。
RocketMQ可在broker.conf文件中配置Consumer端的重试次数和重试时间间隔,如下:
messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h
如有描述理解错误,请大家指出交流!
最后的最后,觉得文章对你有用的小伙伴,留个关注和点赞吧,谢谢支持!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。