设计一个mq中间件，不得不考虑这些

mq简介

mq 全称message queue,也叫消息队列。通俗来讲也就是一个队列，这个队列用来存储消息的。生产者负责往队列里投递消息，消费者在队列中取消息。在分布式应用架构中，常用来做应用的解耦。

为什么用mq

• 解耦。例：订单支付成功，需要给会员卡积分，优惠券核销，扣减库存，通知商家发货等。如果使用传统的方式，需要在订单支付成功后，需要与这么多系统发生交互。使用消息队列后，只需要各自需要订单支付成功的系统订阅支付成功的消息即可。
• 异步，提高接口性能。订单支付成功后即可立即响应，如果耦合其它的调用，势必使接口调用时长提高。
• 削峰。在请求数量暴增时，消息队列能适当“存储”一定的请求，峰值过后立即消化这部分积压请求。

使用mq带来的额外成本

• 系统可用性降低。因为多引入了额外的消息中间件。依赖越多出问题的风险越大。
• 系统复杂性提高：需要考虑多种场景，比如消息重复消费，消息丢失。
• 需要更多的资源，比如机器以及人力维护: 消息队列一般集群部署，而且需要配套的运维和监控等

架构设计思路

最基本的架构

消息队列既然是一个队列，那么当然需要一个server来承载这些消息，于是我想到了如下的架构图。server负责维护全部queue的元数据信息。生产者投递消息到server，指定queue名称，消费者从queue中获取消息，这也是消息队列的核心思想。

问题思考：由于使用者越来越多有一天，发现这个server有点扛不住压力了，响应非常缓慢，怎么办？

server横向扩展

无论你能想到其它优化方案，但是随着用户量越来越大，最终还是要考虑增加server 来分担压力。增加server需要考虑这样一个问题，所有的producer和consumer 都需要面临一次server地址的调整。这显然是不能接受的。于是我想到了如下的架构。再引入一个配置中心节点，配置中心负责维护所有server的元数据信息，所有的producer和consumer 也是直接和配置中心打交道，从配置中心获取到具体的server地址。