【转】【选型】【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 
版权声明：本文为博主原创文章，转载请附上博文链接！