1，消息队列企业级应用场景分析
什么是消息队列？
消息队列是在消息传输过程中保存消息的容器，生产者和消费者不直接通讯，依靠队列保障消息的可靠性，避免了系统间的呼吸影响。
消费队列注意角色
服务端、客户端：生产者，消费者
业务解耦
将模块间的RPC调用改为通过消息队列中转，接触系统间的耦合。
MQ解耦合的有点：
1，提升系统稳定性：ServiceB挂了不会影响到ServiceB
2，通过广播消息避免多次调用：假如ServiceA除了需要调用ServiceB，还需要调用其他的服务，则其他服务都来订阅topic即可。
3，提高编码效率：如果是直接同步调用各个服务，还需要知道各个服务的接口信息，参数传递等，也就是说有一些对接的工作不可避免。MQ的话，消息直接丢到MQ即可。
异步调用
无需关注调用结果的的场景，可以通过消息队列异步处理。
比如一个电商的下单业务：1，风控验证；2，下单处理；3，扣减库存；4，通知卖家；5，记录数据
如果此5步都是同步调用的，处理过程RT必然会很长。第4,5步无需关注返回结果的，通过投递到MQ，进行异步处理。从而可以缩短主流程的RT。
流量削峰
系统的吞吐量往往取决于底层存储服务的处理能力，应用可以调整消费速度缓解存储服务压力，避免短暂的高峰将系统压垮。
应用层可以横行扩展增加吞吐量，但是底层DB扩展没这么简单，处理能力有限，可以通过MQ来消除流量高峰，应用层匀速进行处理。
MQ对系统架构的影响
使用消息队列可以带来很大的收益，但是也会对系统架构造成一些负面影响，而且MQ不能完全替代RPC，需要合理设计业务调用。
架构复杂度：MQ毕竟是引入了一个组件，架构的复杂度肯定是提高的。
系统的可用性：新引入的组件链路变长了，毕竟是多了一个环节，可用性必然是会有所降低的。站在架构角度来讲，多一个环节对系统的影响必须是要统一来评估的。
排查问题路径：链路边长了，排查问题的路径自然也就会更长，更复杂。
2，主流消息队列比对分析
目前主流的MQ主要是RocketMQ，kafka，RabbitMQ，选型应当从如下几个维度来看：
- 系统定位
- 支持功能
- 可用性
- 可靠性
- 运维
基础比对
可靠性/可用性比对
功能比对
结论
各个MQ最初的设计定位不一样，所以才造成了各MQ之间差异较大。
Kafka：系统间数据流的通道
RocketMQ：高性能可靠消息传输
RabbitMQ：可靠消息传输
所以RocketMQ和RabbitMQ更偏向于业务应用。 Kafka各个偏向于做数据流通道，日志收集等。
3，RocketMQ高可用及高扩展解决方案剖析
且听下回分解。
