目前市面上流行的四大消息队列
- ActiveMQ
- 单机吞吐量
- 万级，比 RocketMQ、Kafka 低一个数量级
- topic数量对吞吐量的影响
- 无
- 时效性
- ms 级
- 可用性
- 高，基于主从架构实现高可用
- 消息可靠性
- 有较低的概率丢失数据
- 功能支持
- MQ 领域的功能极其完备
- 建议
- 没经过大规模吞吐量场景的验证，社区也不是很活跃，不推荐
- 单机吞吐量
- kafka
- 单机吞吐量
- 10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
- topic数量对吞吐量的影响
- topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
- 时效性
- 延迟在 ms 级以内
- 可用性
- 非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
- 消息可靠性
- 经过参数优化配置，可以做到 0 丢失
- 功能支持
- 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用
- 建议
- 如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
- 单机吞吐量
- RocketMQ
- 单机吞吐量
- 10 万级，支撑高吞吐
- topic数量对吞吐量的影响
- topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic
- 时效性
- ms 级
- 可用性
- 非常高，分布式架构
- 消息可靠性
- 经过参数优化配置，可以做到 0 丢失
- 功能支持
- MQ 功能较为完善，还是分布式的，扩展性好
- 建议
- 大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择
- 单机吞吐量
- RabbitMQ
- 单机吞吐量
- 万级，比 RocketMQ、Kafka 低一个数量级
- topic数量对吞吐量的影响
- 无
- 时效性
- 微秒级，这是 RabbitMQ 的一大特点，延迟最低
- 可用性
- 高，基于主从架构实现高可用
- 消息可靠性
- 基本不丢
- 功能支持
- 基于 erlang 开发，并发能力很强，性能极好，延时很低
- 建议
-
开源，有稳定的支持，活跃度很高，免费，适合中小型公司
-
- 单机吞吐量
文章引用了：doocs.github.io/advanced-ja… 中的知识点，如有侵权，请联系作者删除
