Category: MQ in distributed Architecture
一、资料文档 二、开发语言 三、支持的协议 四、消息存储 五、消息事务 六、负载均衡 七、集群方式 八、管理界面 九、可用性 十、消息重复 十一、吞吐量TPS 十二、订阅形式和消息分发 十三、顺序消息 十四、消息确认 十五、消息回溯 十六、消息重试 十七、并发度 本文将从,Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ 17 个方面综合对比作为消息队列使用时的差异。
消息队列是一种帮助开发人员解决系统间异步通信的中间件,常用于解决系统解耦和请求的削峰平谷的问题。本文从 Kafka 和 RocketMQ 的对比介绍了作者对消息队列的看法。
消息中间件消费到的消息处理失败怎么办? 一般生产环境中,如果你有丰富的架构设计经验,都会在使用MQ的时候设计两个队列:一个是核心业务队列,一个是死信队列。 核心业务队列,就是比如专门用来让订单系统发送订单消息的,然后另外一个死信队列就是用来处理异常情况的。比如说要是第三方物流系统故障了,此时无法请求,那么仓储系统每次消费到一条订单消息,尝试通知发货和配送,都会遇到对方的接口报错。 此时仓储系统就可以把这条消息拒绝访问,或者标志位处理失败!注意,这个步骤很重要。
1. 消息队列有什么优点和缺点? 为什么使用消息队列?假设你的业务场景遇到个技术挑战,如果不用 MQ 可能会很麻烦,但是你用了 MQ 之后会带给你很多好处。 消息队列 MQ 的常见使用场景其实有很多,但是比较核心的有如下三个: 解耦 异步 削峰 1-1-1. 解耦:A 系统发送个数据到 BCD 三个系统,接口调用发送,那如果 E 系统也要这个数据呢?那如果 C 系统现在不需要了呢?
1. 一、面试题 如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?有几百万消息持续积压几小时,说说怎么解决?
1. 一、背景介绍 背景情况是这样:线上一个系统,在某次高峰期间MQ中间件故障的情况下,触发了降级机制,结果降级机制触发之后运行了一小会儿,突然系统就完全卡死,无法响应任何请求。 给大家简单介绍一下这个系统的整体架构,这个系统简单来说就是有一个非常核心的行为,就是往MQ里写入数据,但是这个往MQ里写入的数据是非常核心及关键的,绝对不容许有丢失。
1. 一、写在前面 上篇文章《同学,消息中间件在你们生产项目里如何落地使用的?》,我们用一个简单易懂的电商场景给大家引入说明了一个消息中间件的使用场景。 同时,我们还基于RabbitMQ的HelloWorld级别的代码,给出了订单服务和仓储服务如何基于MQ中间件收发消息的示例。
1. 一、前情回顾 之前给大家聊了一下,面试时如果遇到消息中间件这个话题,面试官上来可能问的两个问题: 你们的系统架构中为什么要引入消息中间件? 系统架构中引入消息中间件有什么缺点?
这篇文章给大家讲讲,如果你在系统架构里引入了消息中间件之后,会有哪些缺点? 1. 1 系统可用性降低 首先是你的系统整体可用性绝对会降低,给你举个例子,我们就拿之前的一幅图来说明。
GitHub 开源项目地址传送门: https://github.com/qunarcorp/qmq 1. 背 景 2012 年,随着公司业务的快速增长,公司当时的单体应用架构很难满足业务快速增长的要求,和其他很多公司一样,去哪儿网也开始了服务化改造,按照业务等要素将原来庞大的单体应用拆分成不同的服务。那么在进行服务化改造之前首先就是面临是服务化基础设施的技术选型,其中最重要的就是服务之间的通信中间件。一般来讲服务之间的通信可以分为同步方式和异步方式。同步的方式的代表就是 RPC,我们选择了当时还在活跃开发的 Alibaba Dubbo(在之后 Dubbo 官方停止了开发,但是最近 Dubbo 项目又重新启动了)。 异步方式的代表就是消息队列 (Message Queue),MQ 在当时也有很多开源的选择:RabbitMQ, ActiveMQ, Kafka, MetaQ(RocketMQ 的前身)。首先因为技术栈我们排除了 erlang 开发的 RabbitMQ,而 Kafka 以及 Java 版 Kafka 的 MetaQ 在当时还并不成熟和稳定。而...