精华内容
下载资源
问答
  • “我们大家都知道把一个微服务架构变成一个异步架构只需要加一个MQ,现在市面上有很多MQ的开源框架。到底选择哪一个MQ的开源框架才合适呢” MQ就是消息队列,是MessageQueue的缩写。消息队列是一种通信方式。消息的...
  • #“异步架构”课程的作业。
  • 一个国内银行的异步架构设计参考文档,可作为其它银行的异步架构设计参考使用.
  • 分布式消息队列是是大型分布式系统不可缺少的中间件,主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。 对于一个架构师来说,在...2.异步架构的主要组成部分:消息生...

    分布式消息队列是是大型分布式系统不可缺少的中间件,主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。

    对于一个架构师来说,在大型系统设计中,会经常需要面对同步和异步等架构问题,搞明白这些问题,能更好地实现程序并行执行,减少等待或无效操作,以及充分利用计算机的性能!

     

    本文将详细讲解:

    1.同步架构和异步架构的区别

    2.异步架构的主要组成部分:消息生产者、消息消费者、分布式消息队列

    3.异步架构的两种主要模型:点对点模型和发布订阅模型。

    4.消息队列的好处

    5.消息队列相关产品

     

    建议用10min通读,搞懂分布式消息队列的核心内容。

     

    一、同步架构和异步架构的区别

     

    1.同步调用     

     

    是指从请求的发起一直到最终的处理完成期间,请求的调用方一直在同步阻塞等待调用的处理完成。

     

    如图,在这个例子中客户端代码ClientCode,需要执行发送邮件sendEmail这样一个操作,它会调用EmailService进行发送,而EmailService会调用SmtpEmailAdapter这样一个类来进行处理,而这个类会调用远程的一个服务,通过SMTP和TCP协议把请求发送给它。

     

    而远程服务器收到消息以后会对消息进行一系列的操作,然后将邮件发送出去,再进行返回。Adapter收到返回后,再返回给EmailService,EmailService收到返回后再把返回结果返回给Clientcode。

      

    ClientCode在sendEmail发出请求后,就一直都阻塞在这里,等待最终调用结果的返回,是成功还是失败。因为这个过程是阻塞等待的,所以这个过程也就是同步调用。

                   

    2.异步调用

     

    是指在请求发起的处理过程中,客户端的代码已经返回了,它可以继续进行自己的后续操作,而不需要等待调用处理完成,这就叫做异步调用。

     

     

    异步调用过程,同样看刚刚发送邮件的例子,用户Clientcode调用EmailService以后,EmailService会把这个调用请求发送给消息队列,然后就立即返回了。Clientcode收到返回以后继续向下处理,不会继续阻塞等待。实际上消息发送到Queue后,还没有被处理,我们看到后面的消息消费,其实要比EmailService返回可能还要晚一点,EmailService返回以后消息才会被消费处理。

     

    有一个QueueConsumer消息队列的消费者,从消息队列中取出这个消息,再把这个消息发送给SmtpAdapter,也就是调用SmtpAdapter,处理逻辑跟同步调用一样,SmtpAdapter通过SMTP的通讯协议,把消息发送给远程的一个服务器,进行邮件发送,通过RemoteServer进行处理,处理完了收到返回,再把返回结果通知消息队列Queue。

     

    在这个过程中,客户端的调用,也就是应用程序的调用,和业务逻辑真正发送邮件的操作是不同步的。

     

    二、异步架构的主要组成部分

      

    使用异步调用架构的主要手段,就是通过消息队列构建,如下是它的架构图。     

     

    消息的生产者将消息发送到消息队列以后,由消息的消费者从消息队列中获取消息,然后进行业务逻辑的处理,消息的生产者和消费者是异步处理的,彼此不会等待阻塞,所以叫做异步架构。

     

    使用消息队列构建一个异步调用架构,你需要了解如下3种角色。

           

    1.消息的生产者

     

    是客户端应用程序代码的一部分,用来初始化异步调用处理流程。在基于消息队列的处理中,生产者的职责非常少,它要做的就是创建一个合法的消息,并把这个消息发送到消息队列中,由应用开发者决定生产者的代码在哪里执行,什么时候发送消息。

     

    2.消息队列

     

    消息队列是消息发送的目的地和发给消费者的一个缓冲。消息队列实现的方法有好多种,可以用共享文件夹,也可以用关系数据库或者NoSQL系统,当然最主要的还是使用专门的分布式消息队列服务器来实现。

     

    3.消息的消费者

     

    消息的消费者从消息队列中接受并处理消息,消息的消费者也是由应用开发者实现的,但是它是一个异步处理的组件。消息的消费者不需要知道生产者存在,它只依赖消息队列中的消息。消息的消费者通常部署在独立的服务器上,和消息的生产者完全隔离,并且可以通过添加硬件的方式进行伸缩。

     

    三、异步架构的两种主要模型

     

    使用消息队列构建异步的调用架构,你还需要知道两种模型:点对点模型和发布订阅模型。

     

    1.点对点模型

      

     

    消费者和生产者只需要知道消息队列的名字,生产者发送消息到消息队列中,而消息队列的另一端是多个消费者竞争消费消息,每个到达消息队列的消息只会被路由到一个消费者中去,所以消费者看到的是全部消息的一个子集。我们看这张图,消息的生产者有多个,消息的消费者也有多个,多个生产者将消息发送到消息队列中,而有多个消费者去消息队列中对消息进行竞争性的消费。每个消息只会被一个消费者消费,每个消费者只会消费消息队列中的一部分消息。

     

    2.发布订阅模型

     

    在发布订阅模型中,消息可能被发送到不止一个消费者,生产者发送消息到一个主题,而不是队列中。消息被发布到主题后,就会被克隆给每一个订阅它的消费者,每个消费者接收一份消息复制到自己的私有队列。消费者可以独立于其他消费者使用自己订阅的消息,消费者之间不会竞争消息。常用的分布式消息队列都支持发布订阅模型,也就是说消息的发布订阅模型是分布式消息队列的一个功能特性。

     

    3.两个模型的应用

     

    点对点模型:主要用于一些耗时较长的、逻辑相对独立的业务。

     

    比如说我前面的讲到的发送邮件这样一个操作。因为发送邮件比较耗时,而且应用程序其实也并不太关心邮件发送是否成功,发送邮件的逻辑也相对比较独立,所以它只需要把邮件消息丢到消息队列中就可以返回了,而消费者也不需要关心是哪个生产者去发送的邮件,它只需要把邮件消息内容取出来以后进行消费,通过远程服务器将邮件发送出去就可以了。而且每个邮件只需要被发送一次。所以消息只被一个消费者消费就可以了。

     

    发布订阅模型:如新用户注册这样一个消息,需要使用按主题发布的方式。

     

    比如新用户注册,一个新用户注册成功以后,需要给用户发送一封激活邮件,发送一条欢迎短信,还需要将用户注册数据写入数据库,甚至需要将新用户信息发送给关联企业的系统,比如淘宝新用户信息发送给支付宝,这样允许用户可以一次注册就能登录使用多个关联产品。一个新用户注册,会把注册消息发送给一个主题,多种消费者可以订阅这个主题。比如发送邮件的消费者、发送短信的消费者、将注册信息写入数据库的消费者,跨系统同步消息的消费者等。

     

    四、消息队列的好处

     

     

    1.实现异步处理,提升处理性能

     

    对一些比较耗时的操作,可以把处理过程通过消息队列进行异步处理。这样做可以推迟耗时操作的处理,使耗时操作异步化,而不必阻塞客户端的程序,客户端的程序在得到处理结果之前就可以继续执行,从而提高客户端程序的处理性能。

     

    2.可以让系统获得更好的伸缩性

     

    耗时的任务可以通过分布式消息队列,向多台消费者服务器并行发送消息,然后在很多台消费者服务器上并行处理消息,也就是说可以在多台物理服务器上运行消费者。那么当负载上升的时候,可以很容易地添加更多的机器成为消费者。

    如图中的例子,用户上传文件后,通过发布消息的方式,通知后端的消费者获取数据、读取文件,进行异步的文件处理操作。那么当前端发布更多文件的时候,或者处理逻辑比较复杂的时候,就可以通过添加后端的消费者服务器,提供更强大的处理能力。

     

    3.可以平衡流量峰值,削峰填谷

     

    使用消息队列,即便是访问流量持续的增长,系统依然可以持续地接收请求。这种情况下,虽然生产者发布消息的速度比消费者消费消息的速度快,但是可以持续的将消息纳入到消息队列中,用消息队列作为消息的缓冲,因此短时间内,发布者不会受到消费处理能力的影响。

    从这张图可以看到,因为消息的生产者是直接面向用户请求的,而用户的请求访问压力是不均衡的。如淘宝每天的访问高峰是在上午10点左右,而新浪微博则可能在某个明星半夜发一条微博后突然出现访问高峰。

     

    在访问高峰,用户的并发访问数可能超过了系统的处理能力,所以在高峰期就可能会导致系统负载过大,响应速度变慢,更严重的可能会导致系统崩溃。这种情况下,通过消息队列将用户请求的消息纳入到消息队列中,通过消息队列缓冲消费者处理消息的速度。

     

    如图中所示,消息的生产者它有高峰有低谷,但是到了消费者这里,只会按照自己的最佳处理能力去消费消息。高峰期它会把消息缓冲在消息队列中,而在低谷期它也还是使用自己最大的处理能力去获取消息,将前面缓冲起来、来不及及时处理的消息处理掉。那么,通过这种手段可以实现系统负载消峰填谷,也就是说将访问的高峰消掉,而将访问的低谷填平,使系统处在一个最佳的处理状态之下,不会对系统的负载产生太大的冲击。

     

    4.失败隔离和自我修复

     

    因为发布者不直接依赖消费者,所以分布式消息队列可以将消费者系统产生的错误异常与生产者系统隔离开来,生产者不受消费者失败的影响。 当在消息消费过程中出现处理逻辑失败的时候,这个错误只会影响到消费者自身,而不会传递给消息的生产者,也就是应用程序可以按照原来的处理逻辑继续执行。

     

    所以,这也就意味着在任何时候都可以对后端的服务器执行维护和发布操作。可以重启、添加或删除服务器,而不影响生产者的可用性,这样简化了部署和服务器管理的难度。

     

    5.可以使生产者和消费者的代码实现解耦合

     

    也就是说可以多个生产者发布消息,多个消费者处理消息,共同完成完整的业务处理逻辑,但是它们的不需要直接的交互调用,没有代码的依赖耦合。在传统的同步调用中,调用者代码必须要依赖被调用者的代码,也就是生产者代码必须要依赖消费者的处理逻辑代码,代码需要直接的耦合,而使用消息队列,这两部分的代码不需要进行任何的耦合。

     

    耦合程度越低的代码越容易维护,也越容易进行扩展。

           

    比如新用户注册,如果用传统同步调用的方式,那么发邮件、发短信、写数据库、通知关联系统这些代码会和用户注册代码直接耦合起来,整个代码看起来就是完成用户注册逻辑后,后面必然跟着发邮件、发短信这些代码。如果要新增一个功能,比如将监控用户注册情况,将注册信息发送到业务监控系统,就必须要修改前面的代码,至少增加一行代码,发送注册信息到监控系统,我们知道,任何代码的修改都可能会引起bug。

     

    而使用分布式消息队列实现生产者和消费者解耦合以后,用户注册以后,不需要调用任何后续处理代码,只需要将注册消息发送到分布式消息队列就可以了。如果要增加新功能,只需要写个新功能的消费者程序,在分布式消息队列中,订阅用户注册主题就可以了,不需要修改原来任何一行代码。

     

    这种解耦的特点对于团队的工作分工也很有帮助!从消息生产者的视角看,它只需要构建消息,将消息放入消息队列中,开发就完成了。而从消费者的开发视角看,它只需要从消息队列中获取消息,然后进行逻辑处理。它们彼此之间不进行任何耦合。消息的生产者不关心放入消息队列中下一步会发生什么,而消费者也不需要知道消息从哪里来。这两部分程序的开发者也可以不关心彼此的工作进展,他们开发的代码也不需要集成在一起,只要约定好消息格式,就可以各自开发了。

     

    常用的消息队列产品              

     

    目前业界常用的消息队列产品,有这么几种:RabbitMQ 、ActiveMQ、RocketMQ 、Kafka

     

    • RabbitMQ 的主要特点是性能好,社区活跃,但是RabbitMQ用Erlang开发,我们的应用很少用Erlang,所以不便于二次开发和维护。

       

    • ActiveMQ 影响比较广泛,可以跨平台,使用Java开发,对Java比较友好。

       

    • RocketMQ 是阿里推出的一个开源产品,也是使用Java开发,性能比较好,可靠性也比较高。

       

    • Kafka 是LinkedIn出品的,专门针对分布式场景进行了优化,因此分布式的伸缩性会比较好。

     

    目前看来,Kafka因为最初设计时就是针对互联网的分布式、高可用应用场景而设计,并且在大数据领域得到广泛支持,资料文档更加完善,因此在互联网企业得到更多的应用。

     

    这里跟大家分享一个进行技术产品选型的小技巧,供你在进行技术决策的时候参考。当在几个相似的技术产品中进行选型决策,如果拿不定主意,感觉都差不多的时候,一个办法就是利用搜索引擎搜索一下这些产品的名字,搜索结果最多的产品,代表了这个产品是最热门,文档资料最多的、遇到问题有更大概率可以通过搜索引擎找到答案的,最有发展前景、不会半途而废没人维护的。

     

    利用这个技巧,我们看一下消息队列MQ的产品选型,Kafka在百度中的搜索结果数量是其他三个MQ产品的搜索结果数量之和,那么如果你拿不定主意,选择Kafka至少不会是一个糟糕的选择。

     


     

     

    以上内容摘取自拉勾

    《阿里前辈的架构经》  第03讲(分布式消息队列) 点击查看更多

    主讲人:李智慧,前阿里巴巴技术专家

     添加拉勾职场导师微信 lagouandy  ,可领取技术相关100+电子书

    转载于:https://www.cnblogs.com/lagou/p/10985861.html

    展开全文
  • Vite 是新一代响应式区块链 (Reactive Blockchain), 采用了基于消息驱动的异步架构,在其生态体系中,异步是一个很重要的概念,也是 Vite 十分重要的一个创新点。 Vite 中的异步设计主要包括三个方面: 请求和响应...

    引言
    Vite 是新一代响应式区块链 (Reactive Blockchain), 采用了基于消息驱动的异步架构,在其生态体系中,异步是一个很重要的概念,也是 Vite 十分重要的一个创新点。

    Vite 中的异步设计主要包括三个方面:

    请求和响应的异步设计
    交易写入和确认的异步设计
    合约间通信的异步设计

    异步请求模型
    Vite 中的交易分为请求交易和响应交易。无论是一笔转账还是一次合约调用,均会在账本上先后生成两笔交易。
    在这里插入图片描述

    一笔转账交易可以拆分成一个出账交易和一个入账交易;一个合约调用交易可以拆分成一个合约请求交易和一个合约响应交易;每个合约内部的消息调用,可以拆分成一个合约请求交易和一个合约响应交易。

    这样拆分之后,每个交易只影响一个账户的状态,交易之间不会彼此阻塞,有利于与提高系统的吞吐能力。同时,不同账户的交易可以分布在网络中的不同的节点上,为系统带来了扩展性。

    异步确认模型
    Vite 中,交易写入账本和被系统确认也是异步的。不同的用户可以并行的将交易写入账本,快照链将以固定的速度对账本进行快照。一旦交易被快照,就可以认为是 1 次确认,随着快照链的增长,确认数也会累积。

    在这里插入图片描述

    异步确认机制可以削平交易写入速率的峰谷,最大化利用系统资源。

    Vite 采用分层的 HDPoS 共识算法,账本中每条账户链产生候选的局部共识结果,最高层级的快照链从局部共识结果中选择出最终的共识结果。

    异步通信模型
    Vite 的合约间通信采用了一种基于消息驱动的架构,合约间不共享状态,只通过彼此发送消息进行通信。

    在这里插入图片描述

    一个合约调用另一个合约,需要先发送一个请求交易,在逻辑上类似于向 MQ 中生产一个消息。运行目标合约的节点观测到这条请求交易后,向账本中写入一个对应的响应交易,并更新合约的状态。这个操作相当于从 MQ 中消费一条消息。如果需要返回结果,目标合约会以同样的方式向源合约发送另一条消息。

    在这个模型中,Vite 的账本担任了消息中间件的角色,并且可以保障消息的 Exactly Once 语义。

    基于消息的架构具有高吞吐和扩展性的优势。但与此相应,付出的代价是编程模型变得相对复杂,无法保证强一致性,而且有可能使延迟变大。

    Vite 将提供 Solidity++ 合约语言以及完善的 SDK,降低异步编程的成本。经过认真的研究,我们发现在实际场景中,强一致性语义是可以用 BASE 语义替代的。由于 Vite 的 HDPoS 共识算法可以保障交易确认在 1 秒之内完成,因此,延迟的增加仍然在可控范围之内。

    Vite白皮书:https://github.com/vitelabs/whitepaper/blob/master/vite_cn.pdf

    展开全文
  • 分布式消息队列是是大型分布式系统不可缺少的中间件,主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。...2.异步架构的主要组成部分:消息生产者、消息消...

    分布式消息队列是是大型分布式系统不可缺少的中间件,主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。

    对于一个架构师来说,在大型系统设计中,会经常需要面对同步和异步等架构问题,搞明白这些问题,能更好地实现程序并行执行,减少等待或无效操作,以及充分利用计算机的性能!

    本文将详细讲解:

    1.同步架构和异步架构的区别

    2.异步架构的主要组成部分:消息生产者、消息消费者、分布式消息队列

    3.异步架构的两种主要模型:点对点模型和发布订阅模型。

    4.消息队列的好处

    5.消息队列相关产品

    建议用10min通读,搞懂分布式消息队列的核心内容。

    一、同步架构和异步架构的区别

    1.同步调用

    是指从请求的发起一直到最终的处理完成期间,请求的调用方一直在同步阻塞等待调用的处理完成。

    如图,在这个例子中客户端代码ClientCode,需要执行发送邮件sendEmail这样一个操作,它会调用EmailService进行发送,而EmailService会调用SmtpEmailAdapter这样一个类来进行处理,而这个类会调用远程的一个服务,通过SMTP和TCP协议把请求发送给它。

    而远程服务器收到消息以后会对消息进行一系列的操作,然后将邮件发送出去,再进行返回。Adapter收到返回后,再返回给EmailService,EmailService收到返回后再把返回结果返回给Clientcode。

    ClientCode在sendEmail发出请求后,就一直都阻塞在这里,等待最终调用结果的返回,是成功还是失败。因为这个过程是阻塞等待的,所以这个过程也就是同步调用。

    2.异步调用

    是指在请求发起的处理过程中,客户端的代码已经返回了,它可以继续进行自己的后续操作,而不需要等待调用处理完成,这就叫做异步调用。

    异步调用过程,同样看刚刚发送邮件的例子,用户Clientcode调用EmailService以后,EmailService会把这个调用请求发送给消息队列,然后就立即返回了。Clientcode收到返回以后继续向下处理,不会继续阻塞等待。实际上消息发送到Queue后,还没有被处理,我们看到后面的消息消费,其实要比EmailService返回可能还要晚一点,EmailService返回以后消息才会被消费处理。

    有一个QueueConsumer消息队列的消费者,从消息队列中取出这个消息,再把这个消息发送给SmtpAdapter,也就是调用SmtpAdapter,处理逻辑跟同步调用一样,SmtpAdapter通过SMTP的通讯协议,把消息发送给远程的一个服务器,进行邮件发送,通过RemoteServer进行处理,处理完了收到返回,再把返回结果通知消息队列Queue。

    在这个过程中,客户端的调用,也就是应用程序的调用,和业务逻辑真正发送邮件的操作是不同步的。

    二、异步架构的主要组成部分

    使用异步调用架构的主要手段,就是通过消息队列构建,如下是它的架构图。

    消息的生产者将消息发送到消息队列以后,由消息的消费者从消息队列中获取消息,然后进行业务逻辑的处理,消息的生产者和消费者是异步处理的,彼此不会等待阻塞,所以叫做异步架构。

    使用消息队列构建一个异步调用架构,你需要了解如下3种角色。

    1.消息的生产者

    是客户端应用程序代码的一部分,用来初始化异步调用处理流程。在基于消息队列的处理中,生产者的职责非常少,它要做的就是创建一个合法的消息,并把这个消息发送到消息队列中,由应用开发者决定生产者的代码在哪里执行,什么时候发送消息。

    2.消息队列

    消息队列是消息发送的目的地和发给消费者的一个缓冲。消息队列实现的方法有好多种,可以用共享文件夹,也可以用关系数据库或者NoSQL系统,当然最主要的还是使用专门的分布式消息队列服务器来实现。

    3.消息的消费者

    消息的消费者从消息队列中接受并处理消息,消息的消费者也是由应用开发者实现的,但是它是一个异步处理的组件。消息的消费者不需要知道生产者存在,它只依赖消息队列中的消息。消息的消费者通常部署在独立的服务器上,和消息的生产者完全隔离,并且可以通过添加硬件的方式进行伸缩。

    三、异步架构的两种主要模型

    使用消息队列构建异步的调用架构,你还需要知道两种模型:点对点模型和发布订阅模型。

    1.点对点模型

    消费者和生产者只需要知道消息队列的名字,生产者发送消息到消息队列中,而消息队列的另一端是多个消费者竞争消费消息,每个到达消息队列的消息只会被路由到一个消费者中去,所以消费者看到的是全部消息的一个子集。我们看这张图,消息的生产者有多个,消息的消费者也有多个,多个生产者将消息发送到消息队列中,而有多个消费者去消息队列中对消息进行竞争性的消费。每个消息只会被一个消费者消费,每个消费者只会消费消息队列中的一部分消息。

    2.发布订阅模型

    在发布订阅模型中,消息可能被发送到不止一个消费者,生产者发送消息到一个主题,而不是队列中。消息被发布到主题后,就会被克隆给每一个订阅它的消费者,每个消费者接收一份消息复制到自己的私有队列。消费者可以独立于其他消费者使用自己订阅的消息,消费者之间不会竞争消息。常用的分布式消息队列都支持发布订阅模型,也就是说消息的发布订阅模型是分布式消息队列的一个功能特性。

    3.两个模型的应用

    点对点模型:主要用于一些耗时较长的、逻辑相对独立的业务。

    比如说我前面的讲到的发送邮件这样一个操作。因为发送邮件比较耗时,而且应用程序其实也并不太关心邮件发送是否成功,发送邮件的逻辑也相对比较独立,所以它只需要把邮件消息丢到消息队列中就可以返回了,而消费者也不需要关心是哪个生产者去发送的邮件,它只需要把邮件消息内容取出来以后进行消费,通过远程服务器将邮件发送出去就可以了。而且每个邮件只需要被发送一次。所以消息只被一个消费者消费就可以了。

    发布订阅模型:如新用户注册这样一个消息,需要使用按主题发布的方式。

    比如新用户注册,一个新用户注册成功以后,需要给用户发送一封激活邮件,发送一条欢迎短信,还需要将用户注册数据写入数据库,甚至需要将新用户信息发送给关联企业的系统,比如淘宝新用户信息发送给支付宝,这样允许用户可以一次注册就能登录使用多个关联产品。一个新用户注册,会把注册消息发送给一个主题,多种消费者可以订阅这个主题。比如发送邮件的消费者、发送短信的消费者、将注册信息写入数据库的消费者,跨系统同步消息的消费者等。

    四、消息队列的好处

    1.实现异步处理,提升处理性能

    对一些比较耗时的操作,可以把处理过程通过消息队列进行异步处理。这样做可以推迟耗时操作的处理,使耗时操作异步化,而不必阻塞客户端的程序,客户端的程序在得到处理结果之前就可以继续执行,从而提高客户端程序的处理性能。

    2.可以让系统获得更好的伸缩性

    耗时的任务可以通过分布式消息队列,向多台消费者服务器并行发送消息,然后在很多台消费者服务器上并行处理消息,也就是说可以在多台物理服务器上运行消费者。那么当负载上升的时候,可以很容易地添加更多的机器成为消费者。

    如图中的例子,用户上传文件后,通过发布消息的方式,通知后端的消费者获取数据、读取文件,进行异步的文件处理操作。那么当前端发布更多文件的时候,或者处理逻辑比较复杂的时候,就可以通过添加后端的消费者服务器,提供更强大的处理能力。

    3.可以平衡流量峰值,削峰填谷

    使用消息队列,即便是访问流量持续的增长,系统依然可以持续地接收请求。这种情况下,虽然生产者发布消息的速度比消费者消费消息的速度快,但是可以持续的将消息纳入到消息队列中,用消息队列作为消息的缓冲,因此短时间内,发布者不会受到消费处理能力的影响。

    从这张图可以看到,因为消息的生产者是直接面向用户请求的,而用户的请求访问压力是不均衡的。如淘宝每天的访问高峰是在上午10点左右,而新浪微博则可能在某个明星半夜发一条微博后突然出现访问高峰。

    在访问高峰,用户的并发访问数可能超过了系统的处理能力,所以在高峰期就可能会导致系统负载过大,响应速度变慢,更严重的可能会导致系统崩溃。这种情况下,通过消息队列将用户请求的消息纳入到消息队列中,通过消息队列缓冲消费者处理消息的速度。

    如图中所示,消息的生产者它有高峰有低谷,但是到了消费者这里,只会按照自己的最佳处理能力去消费消息。高峰期它会把消息缓冲在消息队列中,而在低谷期它也还是使用自己最大的处理能力去获取消息,将前面缓冲起来、来不及及时处理的消息处理掉。那么,通过这种手段可以实现系统负载消峰填谷,也就是说将访问的高峰消掉,而将访问的低谷填平,使系统处在一个最佳的处理状态之下,不会对系统的负载产生太大的冲击。

    4.失败隔离和自我修复

    因为发布者不直接依赖消费者,所以分布式消息队列可以将消费者系统产生的错误异常与生产者系统隔离开来,生产者不受消费者失败的影响。 当在消息消费过程中出现处理逻辑失败的时候,这个错误只会影响到消费者自身,而不会传递给消息的生产者,也就是应用程序可以按照原来的处理逻辑继续执行。

    所以,这也就意味着在任何时候都可以对后端的服务器执行维护和发布操作。可以重启、添加或删除服务器,而不影响生产者的可用性,这样简化了部署和服务器管理的难度。

    5.可以使生产者和消费者的代码实现解耦合

    也就是说可以多个生产者发布消息,多个消费者处理消息,共同完成完整的业务处理逻辑,但是它们的不需要直接的交互调用,没有代码的依赖耦合。在传统的同步调用中,调用者代码必须要依赖被调用者的代码,也就是生产者代码必须要依赖消费者的处理逻辑代码,代码需要直接的耦合,而使用消息队列,这两部分的代码不需要进行任何的耦合。

    耦合程度越低的代码越容易维护,也越容易进行扩展。

    比如新用户注册,如果用传统同步调用的方式,那么发邮件、发短信、写数据库、通知关联系统这些代码会和用户注册代码直接耦合起来,整个代码看起来就是完成用户注册逻辑后,后面必然跟着发邮件、发短信这些代码。如果要新增一个功能,比如将监控用户注册情况,将注册信息发送到业务监控系统,就必须要修改前面的代码,至少增加一行代码,发送注册信息到监控系统,我们知道,任何代码的修改都可能会引起bug。

    而使用分布式消息队列实现生产者和消费者解耦合以后,用户注册以后,不需要调用任何后续处理代码,只需要将注册消息发送到分布式消息队列就可以了。如果要增加新功能,只需要写个新功能的消费者程序,在分布式消息队列中,订阅用户注册主题就可以了,不需要修改原来任何一行代码。

    这种解耦的特点对于团队的工作分工也很有帮助!从消息生产者的视角看,它只需要构建消息,将消息放入消息队列中,开发就完成了。而从消费者的开发视角看,它只需要从消息队列中获取消息,然后进行逻辑处理。它们彼此之间不进行任何耦合。消息的生产者不关心放入消息队列中下一步会发生什么,而消费者也不需要知道消息从哪里来。这两部分程序的开发者也可以不关心彼此的工作进展,他们开发的代码也不需要集成在一起,只要约定好消息格式,就可以各自开发了。

    常用的消息队列产品

    目前业界常用的消息队列产品,有这么几种:RabbitMQ 、ActiveMQ、RocketMQ 、Kafka

    RabbitMQ 的主要特点是性能好,社区活跃,但是RabbitMQ用Erlang开发,我们的应用很少用Erlang,所以不便于二次开发和维护。

    ActiveMQ 影响比较广泛,可以跨平台,使用Java开发,对Java比较友好。

    RocketMQ 是阿里推出的一个开源产品,也是使用Java开发,性能比较好,可靠性也比较高。

    Kafka 是LinkedIn出品的,专门针对分布式场景进行了优化,因此分布式的伸缩性会比较好。

    目前看来,Kafka因为最初设计时就是针对互联网的分布式、高可用应用场景而设计,并且在大数据领域得到广泛支持,资料文档更加完善,因此在互联网企业得到更多的应用。

    这里跟大家分享一个进行技术产品选型的小技巧,供你在进行技术决策的时候参考。当在几个相似的技术产品中进行选型决策,如果拿不定主意,感觉都差不多的时候,一个办法就是利用搜索引擎搜索一下这些产品的名字,搜索结果最多的产品,代表了这个产品是最热门,文档资料最多的、遇到问题有更大概率可以通过搜索引擎找到答案的,最有发展前景、不会半途而废没人维护的。

    利用这个技巧,我们看一下消息队列MQ的产品选型,Kafka在百度中的搜索结果数量是其他三个MQ产品的搜索结果数量之和,那么如果你拿不定主意,选择Kafka至少不会是一个糟糕的选择。

    以上内容摘取自拉勾

    《阿里前辈的架构经》 第03讲(分布式消息队列)
    点击查看更多

    主讲人:李智慧,前阿里巴巴技术专家

    添加拉勾职场导师微信 lagouandy ,可领取技术相关100+电子书

    展开全文
  • 异步架构:生产者消费者模式

    千次阅读 2016-10-05 13:49:59
    异步架构是典型生产者--消费者模式:两者不存在直接调用,保持数据结构不变,使得彼此之间的功能随意变化互相不受影响。
    异步架构是典型生产者--消费者模式:两者不存在直接调用,保持数据结构不变,使得彼此之间的功能随意变化互相不受影响。
    展开全文
  • 分布式消息队列是是大型分布式系统不可缺少的...对于一个架构师来说,在大型系统设计中,会经常需要面对同步和异步架构问题,搞明白这些问题,能更好地实现程序并行执行,减少等待或无效操作,以及充分利用计算...
  • Spring Boot为此推出了2.X版本,其基于 Spring 5 Framework ,提供了异步非阻塞 IO 的响应式 Stream 、非堵塞的函数式 Reactive Web 框架 Spring WebFlux,试图以此来提升框架能承受的并发量,但目前2.X版本的表现并...
  • /*  * akg.h  * 业务逻辑注册  *  */ #ifndef AKG_H_ #define AKG_H_ #include "conn.h" #include "msgqueue.h" #define MAX_PKG_TYPE (0xffff) extern const ui
  • 在单片机裸机开发中,...为此我分享出一段由朋友:流星原创的event_delay异步延时方案。使用此库便可以给N个函数增加指定延时时间,异步非阻塞方式,数据结构简单,合作式调度方式。另:此代码已在很多实体项目中使用
  • /*  * handle.h  */ #ifndef HANDLE_H_ #define HANDLE_H_ #include "msgqueue.h" typedef struct HANDLER{ int send_sock; char send_ip[128]; uint16 send_port;...pthread_t th
  • 同步架构与异步架构 背景 把智能系统比喻成KFC营业厅,处理器是窗口和窗口后面的服务员(把一个窗口当作一个核心),指令集是后面排队的人,窗口是数据吞吐量。 当中午就餐人多的时候,一个窗口肯定忙不过来, 这...
  • [微服务异步架构—MQ之RocketMQ] “我们大家都知道把一个微服务架构变成一个异步架构只需要加一个MQ,现在市面上有很多MQ的开源框架。到底选择哪一个MQ的开源框架才合适呢?” 一、什么是MQ?MQ的原理是什么? MQ就是...
  • 这个实现使用到了异步消息队列。 异步消息队列 主要用于实现生产者-消费者模式。也就是说,这个队列应当是可以阻塞的,否者会带来大量的性能浪费。 生产者-消费者模式 实现 1.定义事件类型 – 定义Enum类 – Enum...
  • 微服务异步架构

    千次阅读 2016-10-19 18:17:17
    对这种情况的优化,除了在程序上不断调优(数据库调优,算法调优,缓存等等),可以考虑在架构上做些调整,先返回结果给客户端,让用户可以继续使用客户端的其他操作,再把服务端的复杂逻辑处理模块做异步化处理。...
  • 最近的消息异步架构用得蛮多的,开始这个架构的不成熟,功能不够强大可能导致后期架构不够用或出现一些问题。我小小总结一下现在的IM项目的异步消息架构。  这几次没有注意到的架构是:  一、消息并发处理,  ...
  • Python中的分布式异步socket架构
  • Reactive架构升级实践——淘宝全站业务的全异步流式架构升级.pdf
  • 异步通信架构设计

    2011-11-23 12:47:14
    设计前提:所有业务接入都必须是异步调用,如果有同步调用,也必须想办法化为异步模式来传输调用; 线程模型:采用一组线程,处理所有的任务,如接受连接、接收数据、协议处理、业务调用、发送数据等。
  • Flask+gevent 异步 WEB 架构

    千次阅读 2018-07-31 17:48:07
    异步 WEB 架构的特点: gevent 为 Python 提供了比较完善的协程支持,其基于 greenlet 实现协程。 当 greenlet 遇到如网络访问、磁盘 IO 等操作时,就将自动切换至其他的 greenlet,待操作完成后,在适合的时间点...
  • MySQL异步复制延迟解决的架构设计与运维架构
  • 使用异步架构构建提醒应用。 启动事件存储 下载adbrowne/eventstore映像,然后运行以下命令: docker run -i -p 2113:2113 -p 1113:1113 adbrowne/eventstore 电子邮件接收者 电子邮件接收者的工作是将收到的电子...
  • 一种基于Qt的可伸缩全异步CS架构服务器实现,绝对值5分。 郑重声明:该资源仅供学习交流使用。
  • 异步导入导出架构设计 2018年04月27日 00:00:00 架构文摘 阅读数:409 为什么要用异步?   在我们平时的业务系统中,文件导入,文件导出是一个很常见的业务需求。正常情况下,同步导出就可以满足我们80%的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 243,432
精华内容 97,372
关键字:

异步架构