消息中间件企业级应用

　　本文转载与Java团长微信公众号，原文链接为：https://mp.weixin.qq.com/s/vq7inOyby23dI0DYav51GQ

　　众所周知，消息中间件是大型分布式系统中不可或缺的重要组件。它使用简单，却解决了不少难题，比如异步处理，系统藕合，流量削锋，分布式事务管理等。实现了一个高性能，高可用，高扩展的系统。本章通过介绍消息中间件的应用场景，消息中间件的传输模式 两个面来对消息中间件进行入门介绍。还在等什么，赶快来学习吧！

　　说明：消息中间件非常强大，值得我们认真去学习和使用。完整代码请异步github。
　　技术：消息中间件的应用场景，通信模式。

消息中间件应用场景

　异步处理

　　异步处理：调用者发起请求后，调用者不会立刻得到结果，也无需等待结果，继续执行其他业务逻辑。提高了效率但存在异步请求失败的隐患，适用于 非核心业务逻辑处理。

　　同步处理：调用者发起请求后，调用者必须等待直到返回结果，再根据返回的结果执行其他业务逻辑。效率虽然没有异步处理高，但能保证业务逻辑可控性，适用于核心业务逻辑处理。

　　举一个比较常见的应用场景：为了确保注册用户的真实性，一般在注册成功后会发送验证邮件或者验证码短信，只有认证成功的用户才能正常使用平台功能。如下图所示：同步处理和异步处理的比较。

　　用消息中间件实现异步处理的好处：
　　一、在传统的系统架构，用户从注册到跳转成功页面，中间需要等待邮件发送的业务逻辑耗时。这不仅影响系统响应时间，降低了CPU吞吐量，同时还影响了用户的体验。
　　二、通过消息中间件将邮件发送的业务逻辑异步处理，用户注册成功后发送数据到消息中间件，再跳转成功页面，邮件发送的逻辑再由订阅该消息中间件的其他系统负责处理。

　　三、消息中间件的读写速度非常的快，其中的耗时可以忽略不计。通过消息中间件可以处理更多的请求。

　　小结：正确使用消息中间件将非核心业务逻辑功能异步处理，可以提高系统的响应效率，提高了CPU的吞吐量，改善用户的体验。

　系统藕合和事务的最终一致性

　　分布式系统是若干个独立的计算机（系统）集合。每个计算机负责自己的模块，实现系统的解耦，也避免单点故障对整个系统的影响。每个系统还可以做一个集群，进一步降低故障的发生概率。在这样的分布式系统中，消息中间件又扮演着什么样的角色呢？

　　举一个比较常见的应用场景：订单系统下单成功后，需要调用仓库系统接口，选择最优的发货仓库和更新商品库存。若因为某种原因在调用仓库系统接口失败，会直接影响到下单流程。如下图所示：感受一下消息中间件扮演的重要角色。

　　用消息中间件实现系统藕合的好处：
　　一、消息中间件可以让各系统之间耦合性降低，不会因为其他系统的异常影响到自身业务逻辑。各尽其职，订单系统只需负责将订单数据持久化到数据库中，仓库系统只需负责更新库存，不会因为仓库系统的原因从而影响到下单的流程。
　　二、各位看官是否发现了一个问题，下单和库存减少本应该是一个事务。因为分布式的原因很难保证事务的强一致性。这里通过消息中间件实现事务的最终一致性效果(后续会详细介绍)。

　　小结：事务的一致性固然重要，没有库存会导致下单失败是一个理论上很正常的逻辑。但实际业务中并非如此，我们完全可以利用发货期通过采购或者借库的方式来增加库存。这样无疑可以增加销量，还是可以保证事务的最终一致性。

　流量削锋

　　流量削锋也称限流。在秒杀，抢购的活动中，为了不影响整个系统的正常使用，一般会通过消息中间件做限流，避免流量突增压垮系统，前端页面可以提示"排队等待"，即便用户体验很差，也不能让系统垮掉。

　小结：限流可以在流量突增的情况下保障系统的稳定。系统宕机会被同行抓住笑柄。

消息中间件的传输模式

　　消息中间件除了支持对点对和发布订阅两种模式外，在实际开发中还有一种双向应答模式被广泛使用。

　点对点(p2p)模式

　　点对点(p2p)模式有三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。发送者将消息发送到一个特定的队列中，等待接收者从队列中获取消息消耗。
P2P的三个特点：
　　一、 每个消息只能被一个接收者消费 ， 且消息被消费后默认从队列中删掉（也可以通过其他签收机制重复消费） 。
　　 二、 发送者和接收者之间 没有依赖性 ， 生产者发送消息和消费者接收消息并不要求同时运行 。
　　三、接收者在成功接收消息之后需向队列 发送接收成功的确认消息 。

　发布订阅(Pub/Sub)模式

　　发布订阅(Pub/Sub)模式也有三个角色：主题（Topic），发布者（Publisher），订阅者（Subscriber）。发布者将消息发送到主题队列中，系统再将这些消息传递给订阅者。
Pub/Sub的特点：
　　一、 每个消息可以被多个订阅者消费 。
　　二、发布者和订阅者之间 存在依赖性 。订阅者必须先订阅主题后才能接收到信息，在订阅前发布的消息，订阅者是接收不到的。
　　三、非持久化订阅：如果订阅者不在线，此时发布的消息订阅者是也接收不到，即便订阅者重新上线也接收不到。
　　四、持久化订阅：订阅者订阅主题后，即便订阅者不在线，此时发布的消息可以在订阅者重新上线后接收到的。

　双向应答模式

　　双向应答模式并不是消息中间件提供的一种通信模式，它是由于实际生成环境的需要，在原有的基础上做了改良。即消息的发送者也是消息的接收者。消息的接收者也是消息的发送者。如下图所示