为什么要用消息队列 及 自己如何设计一个mq架构

　　1. 解耦：如左图, 系统a因为业务需求需要调用系统b，后续因为业务需求可能需要改代码调用系统c，甚至还要考虑被调用的系统挂了访问超时的问题。耦合性太高！ 如右图, 系统a产生一条数据发送到消息队列里面去， 需要数据的系统就去监控消息队列就好了。

　　2. 异步：如左图，一个请求过来，3个服务走完需要花450ms； 右图，系统a处理完请求后直接丢给消息队列，然后响应用户，不需要等待。只花了150ms这样就节约了不少时间！一般互联网项目用户请求不超过200ms体验是最好的。

　　　　　　

　　3. 削峰：

　　　　　　

消息中间件的选择

　　activemq：万级吞吐量，老牌产品 mq领域的功能比较完善，(社区不活跃, 不建议用)

　　rabbitmq：吞吐量比activemq高一点点，基于erlang开发 并发性能好。(社区活跃，适合中小公司)

　　rocketmq：十万级吞吐量，阿里产品java开发，经过双十一考验。topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降(怕像dubbo一样后期黄了，自己团队没人能改造源码。适合中大公司)

　　kafka ：十万级吞吐量，topic从几十个到几百个的时候，吞吐量会大幅度下降。天然适合大数据实时计算以及日志收集。

MQ架构设计思路

1. 可伸缩性：
　　设计为分布式的，例如分为nameBervice和broker；broker负责Topic消息存储、管理和分发等功能；bs就是一个注册中心、维护所有Brokers信息。这样通过水平扩展就提升了吞吐量和容量了。
2. 可靠性：
　　数据要磁盘落地，来做到可恢复、持久化。然后顺序写随机读来提高性能。
3. 容错性：
　　多个机器中有的宕机后,要有类似zookeeper的的投票选举功能，确保集群稳定运行。