众所周知,消息中间件是大型分布式系统中不可或缺的重要组件。它使用简单,却解决了不少难题,比如异步处理,系统藕合,流量削锋,分布式事务管理等。实现了一个高性能,高可用,高扩展的系统。本章通过介绍消息中间件的应用场景,消息中间件的传输模式 两个面来对消息中间件进行入门介绍。还在等什么,赶快来学习吧!
说明:消息中间件非常强大,值得我们认真去学习和使用。完整代码请异步github。
技术:消息中间件的应用场景,通信模式。
消息中间件应用场景
异步处理
异步处理:调用者发起请求后,调用者不会立刻得到结果,也无需等待结果,继续执行其他业务逻辑。提高了效率但存在异步请求失败的隐患,适用于 非核心业务逻辑处理。同步处理:调用者发起请求后,调用者必须等待直到返回结果,再根据返回的结果执行其他业务逻辑。效率虽然没有异步处理高,但能保证业务逻辑可控性,适用于核心业务逻辑处理。
举一个比较常见的应用场景:为了确保注册用户的真实性,一般在注册成功后会发送验证邮件或者验证码短信,只有认证成功的用户才能正常使用平台功能。如下图所示:同步处理和异步处理的比较。
用消息中间件实现异步处理的好处:
一、在传统的系统架构,用户从注册到跳转成功页面,中间需要等待邮件发送的业务逻辑耗时。这不仅影响系统响应时间,降低了CPU吞吐量,同时还影响了用户的体验。
二、通过消息中间件将邮件发送的业务逻辑异步处理,用户注册成功后发送数据到消息中间件,再跳转成功页面,邮件发送的逻辑再由订阅该消息中间件的其他系统负责处理。
三、消息中间件的读写速度非常的快,其中的耗时可以忽略不计。通过消息中间件可以处理更多的请求。
小结:正确使用消息中间件将非核心业务逻辑功能异步处理,可以提高系统的响应效率,提高了CPU的吞吐量,改善用户的体验。
系统藕合和事务的最终一致性
分布式系统是若干个独立的计算机(系统)集合。每个计算机负责自己的模块,实现系统的解耦,也避免单点故障对整个系统的影响。每个系统还可以做一个集群,进一步降低故障的发生概率。在这样的分布式系统中,消息中间件又扮演着什么样的角色呢?
举一个比较常见的应用场景:订单系统下单成功后,需要调用仓库系统接口,选择最优的发货仓库和更新商品库存。若因为某种原因在调用仓库系统接口失败,会直接影响到下单流程。如下图所示:感受一下消息中间件扮演的重要角色。
用消息中间件实现系统藕合的好处:
一、消息中间件可以让各系统之间耦合性降低,不会因为其他系统的异常影响到自身业务逻辑。各尽其职,订单系统只需负责将订单数据持久化到数据库中,仓库系统只需负责更新库存,不会因为仓库系统的原因从而影响到下单的流程。
二、各位看官是否发现了一个问题,下单和库存减少本应该是一个事务。因为分布式的原因很难保证事务的强一致性。这里通过消息中间件实现事务的最终一致性效果(后续会详细介绍)。
小结:事务的一致性固然重要,没有库存会导致下单失败是一个理论上很正常的逻辑。但实际业务中并非如此,我们完全可以利用发货期通过采购或者借库的方式来增加库存。这样无疑可以增加销量,还是可以保证事务的最终一致性。
流量削锋
流量削锋也称限流。在秒杀,抢购的活动中,为了不影响整个系统的正常使用,一般会通过消息中间件做限流,避免流量突增压垮系统,前端页面可以提示"排队等待",即便用户体验很差,也不能让系统垮掉。
小结:限流可以在流量突增的情况下保障系统的稳定。系统宕机会被同行抓住笑柄。
消息中间件的传输模式
消息中间件除了支持对点对和发布订阅两种模式外,在实际开发中还有一种双向应答模式被广泛使用。
点对点(p2p)模式
点对点(p2p)模式有三个角色:消息队列(Queue),发送者(Sender),接收者(Receiver)。发送者将消息发送到一个特定的队列中,等待接收者从队列中获取消息消耗。P2P的三个特点:
一、 每个消息只能被一个接收者消费 , 且消息被消费后默认从队列中删掉(也可以通过其他签收机制重复消费) 。
二、 发送者和接收者之间 没有依赖性 , 生产者发送消息和消费者接收消息并不要求同时运行 。
三、接收者在成功接收消息之后需向队列 发送接收成功的确认消息 。
发布订阅(Pub/Sub)模式
发布订阅(Pub/Sub)模式也有三个角色:主题(Topic),发布者(Publisher),订阅者(Subscriber)。发布者将消息发送到主题队列中,系统再将这些消息传递给订阅者。Pub/Sub的特点:
一、 每个消息可以被多个订阅者消费 。
二、发布者和订阅者之间 存在依赖性 。订阅者必须先订阅主题后才能接收到信息,在订阅前发布的消息,订阅者是接收不到的。
三、非持久化订阅:如果订阅者不在线,此时发布的消息订阅者是也接收不到,即便订阅者重新上线也接收不到。
四、持久化订阅:订阅者订阅主题后,即便订阅者不在线,此时发布的消息可以在订阅者重新上线后接收到的。