MQ在分布式系统中的使用场景

解决的问题

一项技术的产生必然是为了解决问题而生,了解了一项技术解决的问题,就能够很轻松的理解这项技术的设计根本,从而更好地理解与使用这项技术。 消息中间件和RPC从根本上来说都是为了解决分布式系统的服务间通信问题,我们的服务从最初的单体应用发展到SOA架构到现在的微服务架构,必不可少的就是服务间通信,但从最初的设想,服务间通信仅仅就是一次请求响应调用而已,为什么发展出如此多的消息中间件与RPC技术,我们是否真的需要学习这么多的消息中间件技术? 答案是肯定的,接下来我们将分析我们为什么要了解及使用如此多的服务间通信技术,以及他们究竟都解决了哪些问题,在什么场景下他们是必不可少的。

消息中间件 VS RPC

首先来说一下什么是消息中间件和RPC,简单来说,他们最主要的区别是,完成一次服务间通信需要的组件数量,本篇文章我们先来讨论一下消息中间件的优势与使用场景

RPC
消息中间件

从上面两幅图可以清晰地看出消息中间件比RPC要多了一个组件,那就是消息中间件本身,从而我们也能想到,使用消息中间件通信时,相较于使用RPC通信,会有更多的组件运维成本,也会增加一次通信的通信延迟,那么我们为什么要使用消息中间件?一个很重要的原因就是,他为我们增加了消息堆积能力,而这个能力提供给我们了很重要的流量削峰,高可用以及广播等问题的解决方案。

流量削峰

流量削峰是指在发生突发性流量增长时,并不会让上游服务(接收请求的服务)出现超负荷并发从而导致宕机等风险,MQ(消息队列)的解决方案是将流量暂缓存至自己的Queue中,将稳定的持续的将流量发送给消费者。

(在发生流量突增时,上游服务的实时消息处理量,RPC(上),MQ(下)) 上面的图展示的是不同时间段上游服务的请求量曲线,可以看出,通过RPC进行请求的上游服务在短时间内会接收大量超出最高负载的请求,从而可能引发大量的请求超时和CPU 100%导致的服务宕机等情况。而通过MQ进行通信时,若MQ发现接收到的请求超出消费者的最大负载时,则会将请求暂存至消息队列中,并将请求保持在一个持续稳定的量发送给消费者(上游服务),从而保证了系统的稳定。 流量削峰在面对例如秒杀等场景就显得尤为重要,例如淘宝的双十一整点秒杀,12306的整点放票等活动,消息队列均起到的重要作用,我们也就可以很好地理解,为什么12306在推出排队系统后,服务宕机的概率被大大减小了(虽然体验依旧是一团糟...?)。 推荐中间件:RabbitMQ

使用消息中间件提高服务的可用性

可用性是指服务在某个时间段内正常运行的时间,提高可用性就是指减少服务的故障停机时间,那么MQ是如何提高服务的可用性的呢。

(当Service B宕机时的MQ(上)与RPC(下)) 当上游出现问题时,将无法接收下游服务给予的请求,这时上游服务会因上游服务不能完成请求而报错,从而导致这个请求无法完成,导致整个系统不能接收更多的请求,用户就会感知到,服务挂掉了... 而消息中间件的处理方式是,上游服务出现宕机时,将消息缓存至消息队列中,等待上游服务恢复正常时,在继续处理请求。当然这里你应该也会发现,在该场景下,消息中间件更适合处理一些无需立即处理,也就是异步的请求,例如日志,数据持久化等操作,他们是并不需要返回或立即返回处理结果给用户的。 推荐中间件:Kafka

使用MQ实现事务的最终一致性

分布式事务是个极其复杂的话题,本文不展开讨论,这里主要讨论一下MQ在分布式事务中所起到的作用。 最终一致性简单地说就是弱一致性的一种,允许存在一定的不一致窗口,但要求在有限的时间内关闭不一致窗口并让所有系统最终一致。

(图片出处:http://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html) 上图描述了一个基于MQ实现最终一致性的一种解决方案(异步确保模式)。 主要描述的是DB A和DB B分属两个不同的数据中心要进行数据同步,消息发送方会将数据写入至MQ中并在本地记录消息标识(已发送的消息),当消息接收方接收到该消息并处理后会告知发送方处理结果(成功/失败),消息发送方对接收方的处理结果进行处理,如若处理失败则进行补偿操作。 (关于更多相关细节不在本文中过多讨论...) MQ主要起到的作用有两点:

  1. 采用异步方式提高了事务请求的性能及并发量,如果采用同步方式调用的事务请求并且事物的调用链非常长则会导致用户等待时间极长,并降低系统的并发量及可用性
  2. 提供了消费方接收消息的重试机制,消费方能够处理该事务的前提是能够接收该事务,MQ更多的保证了不会因消费方宕机,网络超时等等原因的消费失败。

本文简单的说了一下消息中间件的优势和使用场景,在接下来的文章将更详细的介绍每种消息中间件的优劣及其原理,以及使用RPC框架相较于消息中间件的优势所在及使用场景,希望大家能够支持:)

原文发布于微信公众号 - Java架构沉思录(code-thinker)

原文发表时间:2018-10-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯云技术沙龙

白瑜庆:知乎基于Kubernetes的kafka平台的设计和实现

我是知乎技术中台工程师,负责知乎存储相关的组件。我的分享主要基于三个,第一,简单介绍一下Kafka在知乎的应用,第二,为什么做基于Kubernetes的Kafk...

1K11
来自专栏ThoughtWorks

别再加端到端集成测试了,快换契约测试吧 | 洞见

正如大家所知,最初QA都是手动执行测试用例,开发人员每修改一个版本,QA就要手动测试一遍,随着功能的不断增加,手动测试重复的工作量越来越大。为了解脱QA重复性劳...

3795
来自专栏IT笔记

从构建分布式秒杀系统聊聊重复购买

秒杀时为了公平起见,往往是单个用户只能购买一件商品,但是又要做到不能少买,那么问题来了,如何保证?

2673
来自专栏安恒信息

邮箱安全服务专题第5期 | 邮箱APT检测分析关键技术

上一期我们介绍了钓鱼邮件的常规检测方法,其实,无论采用怎么样的方式,人的安全意识永远都是第一位,纵使钓鱼邮件写得多么诱人深入人心,只要我们守住底线,点击之前先思...

3206
来自专栏后端技术探索

大规模Nginx平台化实践,京东能提供哪些参考经验?

Nginx是优秀的HTTP和反向代理服务器,京东各部门都在广泛使用,但普遍都面临着一些问题:

1701
来自专栏互扯程序

5分钟了解swagger

随着互联网技术的发展,现在的网站架构基本都由原来的后端渲染,变成了:前端渲染、先后端分离的形态,而且前端技术和后端技术在各自的道路上越走越远。

1893
来自专栏Python研发

linux入门总结

linux的核心概念知识:      linux软件是开源免费的,而linux是由Unix演变而成,Unix是由MINIX演变而成。 2000年以后,linu...

1612
来自专栏张善友的专栏

MongoDB新版本特性

MongoDB 2.4已经发布,该版本增加了一些新特性,如文本搜索、基于哈希的分片、更好的地理空间功能、支持GeoJSON以及一些性能和工具方面的提升。我们还和...

2225
来自专栏大数据和云计算技术

阿里HBase的数据管道设施实践与演进

摘要:第九届中国数据库技术大会,阿里巴巴技术专家孟庆义对阿里HBase的数据管道设施实践与演进进行了讲解。主要从数据导入场景、 HBase Bulkload功能...

1652
来自专栏Android 开发者

后续更新 | 减少使用非 SDK 接口以提升稳定性

2394

扫码关注云+社区

领取腾讯云代金券