【转】【选型】【MQ】消息中间件对比

https://blog.csdn.net/huayushuangfei/article/details/80866642 

消息中间件对比


为什么选择RocketMQ
性价比,社区活跃度 
性价比之“性”: 
性能:阿里支撑,经受住淘宝,天猫双11重重考验;性能高;可靠性好;可用性高;易扩展 
功能:功能完善,我们需要的功能,基本都够满足,如:事务消息,消息重试,私信队列,定时消息等; 
易用,跨平台:跨语言,多协议接入(支持HTTP, MQTT, TCP协议,支持Restful风格HTTP收发消息) 
性价比之“价”: 
钱能解决的问题,一般都不是问题,所以免费服务不能满足的,适当的花钱购买所需服务是值得的,早期阿里引进的IOE,那我们引进的就是RocketMQ的阿里云和VIP服务; 
当然,钱解决不了的问题,那必然是问题,IOE的高消费,不如去IOE寻找技术方面的突破, 
社区活跃度: 
技术突破就分能突破的和不能突破的,需要社区支持,社区不活跃,版本问题不改善,自己修复问题不仅耗时,而且未必正确能够经受考验

RocketMQ队列消费谨记
一个消费者可以消费多个队列,但一个队列只能由一个消费者消费

RocketMQ消息顺序和重复消费问题
RocketMQ特性
顺序性 
消息过滤 
消息持久化 
消息回溯 
大量消息堆积 
定时消息 
消息重试

RocketMQ广播与集群区别
RocketMQ高可用
RocketMQ分布式事务
RocketMQ有哪些坑
RocketMQ的namesrv全挂掉是否影响通信
RocketMQ的生产者和发送者Reblance
RocketMQ队列中的消息有序,能否保证消费者消费也有序
必须是顺序消费才可以,并行消费无法做到有序。是否受网络影响,顺序消费也有可能无序,待测

RocketMQ怎么设置消息是从Master消费还是从Slaver消费。Master和Slaver同时在线,消息是否会从Master消费一遍,然后再从Slaver消费一遍?
RocketMQ默认端口
namesrv默认端口9876,broker默认端口10911,VIP默认端口10909,每个broker启动后默认占用两个端口10911和10913或10912和10914

RocketMQ同一台机,启动多个生产者实例或多个消费者实例,需要设置不同的实例名称
RocketMQ无论何种情况(发送到单个队列,顺序消费或并行消费;或者发送到多个队列,顺序消费或者并行消费),延时/定时消息总是迟于非延时/非定时消息到达broker,延时/定时消息是在延时/定时时间过后才被投放到broker,也即延时/定时消息不会影响非延时/非定时消息到达broker。如果等待所有消息全部到达broker之后,才启动消费者,这个延时/定时是否还有意义?
RocketMQ在不考虑网络影响的情况下,只有将同一ID的消息发送到同一队列上,并且消费端使用顺序消费,才能保证消息被顺序消费。即生产者不使用MessageQueueSelector或者消费者不使用MessageListenerOrderly的任何一种情况出现都不能保证消息被顺序消费,考虑网络影响的情况待测。
RocketMQ消费端消息ack是ack到本地队列,然后由本地队列登记后,再5秒钟间隔上报到broker?
经测试:调大上报时间,本地ack之后(返回CONSUME_SUCCESS,且#Diff > 0),立即停掉消费端,过许久,发现仍#Diff > 0,证明消费端确实还没有上报ack进度给broker;重启消费端之后,因#Diff > 0,消息又被重新消费了一次,证明之前broker确实没收到ack,也由此可证明消费端ack是先ack到本地队列,停掉消费端,本地队列的所有信息都没有了,也就因此迟迟不会将#Diff变为0。
--------------------- 
作者:多隆 
来源:CSDN 
原文:https://blog.csdn.net/huayushuangfei/article/details/80866642 
版权声明:本文为博主原创文章,转载请附上博文链接!

猜你喜欢

转载自blog.csdn.net/kingdelee/article/details/83119573