大型网站架构(4) 分布式中的异步通信

我们知道在面向对象编程中,总会想着各种办法来实现代码的解耦,从而让项目中的各种人员面对自己熟悉的业务进行开发,做到术业有专攻,比如大家非常熟悉的三层架构,MVC,MVP以及MVVM模式,让前端设计专注于html的制作,让后端开发人员更加专注于业务逻辑的编写,可以看到,我们这么做的目的就是想最大程度的做到系统的可扩展和可维护性,那么我们的大型网站是不是也要遵守这种模式呢?

一:分层和分割

1:分层

对于分层,我们可能非常熟知了,数据访问层,业务逻辑层,缓存层,应用层,层层专注于自己的业务,然后根据需要建立起 各自的集群,各自分离部署,而从达到系统的扩展性和维护性。

2:分割

如果说前面是横向切割,那分割就是纵向切割,我们可以把网站的整体业务切分成很多的小业务,比如博客园的导航栏,我们都可以认为是一个独立的网站,配上各自的二级域名,建立各自的集群来实现系统的扩展性,当然这个粒度可大可小。

如果说这些子网站不存在相互调用,那么我们新增模块或者修改模块基本上都不会对其他模块造成影响,这也是我们做扩展性的终极目标,现在既然都做到解耦了,下面的目标就是做如何通信了,通信可以分为“同步”和“异步”,这篇主要是讨论下异步操作,在分布式系统中做到"异步操作“,当然少不了强大的消息队列。

二:消息队列

在分布式的系统中使用消息队列后,我们的生产者只管向消息队列中甩完数据后立即返回,而不管是哪个消费者来消费,可以看到其实消息队列有如下三个优点。

1.  加快网站的相应速度

这个刚才也说了,应用层直接把消息给消息队列然后直接返回调用端,这样就避免了处理复杂的业务逻辑然后同步的插入到数据 库后再返回造成的响应延迟,在很多网站上用户提交订单就是这么处理的,应用层生成一个订单号之后,将订单丢给消息队列,然后直接到订单成功页面,此时后端消费者对订单还没有处理完毕,因为后面会有比较多的数据操作,比如减库存,数据库同步等等,而用户如果想要看到订单详情,需要点击“订单号”才能进入到订单详情页,这种处理也是因为消息队列的非及时性,所以需要得到网站设计方改进和支持。

查看本栏目更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/web/Skills/

2. 提供系统的可用性

既然是异步操作,就造成了生产者不知道消费者的存在,而反过来消费者不知道生产者的存在,如果消费者挂了就不会影响到生产者,  生产者还会照常无误的向消息队列甩消息,当消费者恢复正常后就会继续消费消息队列,系统的表现可能就是email或者短信延迟收到,不会对系统造成太大的影响。

3. 并发削峰

既然是大型网站就免不了高并发的读写操作,很典型的一个例子就是电商中的秒杀,这种高并发的写操作,如果一下子都涌入到数据库里面去了,会导致数据库的压力非常大,从而导致客户端的访问延迟,就是不挂也容易造成数据库的死锁从而造成很多灵异事件,遇到这种一拥而入的情况,我们就必须进行线性化操作,在代码层面上我们可以用lock机制来串行化,在分布式中我们用“消息队列”来串行化,而且还可以通过逻辑操作来对消息队列进行动态的防洪,控洪。

在消息队列的选择上,微软有自己的MSMQ,但是在大型网站中,我们的消息队列同样需要集群,并且希望能跑在内存中,并且支持序列化硬盘,同时在“伸缩性”和“可靠性”上要有好的作为,所以推荐大家用用开源的RabbitMQ,网址:http://www.rabbitmq.com/  不过很多公司都有自己开发的消息队列,比如携程的CMessage,淘宝的MetaQ。

作者:cnblogs 一线码农

时间: 2024-12-23 18:59:20

大型网站架构(4) 分布式中的异步通信的相关文章

大型网站架构系列:分布式消息队列(一) (转)

以下是消息队列以下的大纲,本文主要介绍消息队列概述,消息队列应用场景和消息中间件示例(电商,日志系统). 本次分享大纲 消息队列概述 消息队列应用场景 消息中间件示例 JMS消息服务(见第二篇:大型网站架构系列:分布式消息队列(二)) 常用消息队列(见第二篇:大型网站架构系列:分布式消息队列(二)) 参考(推荐)资料(见第二篇:大型网站架构系列:分布式消息队列(二)) 本次分享总结(见第二篇:大型网站架构系列:分布式消息队列(二)) 一.消息队列概述 消息队列中间件是分布式系统中重要的组件,主要

大型网站架构系列:分布式消息队列(一)

以下是消息队列以下的大纲,本文主要介绍消息队列概述,消息队列应用场景和消息中间件示例(电商,日志系统). 本次分享大纲 消息队列概述 消息队列应用场景 消息中间件示例 JMS消息服务(见第二篇:大型网站架构系列:分布式消息队列(二)) 常用消息队列(见第二篇:大型网站架构系列:分布式消息队列(二)) 参考(推荐)资料(见第二篇:大型网站架构系列:分布式消息队列(二)) 本次分享总结(见第二篇:大型网站架构系列:分布式消息队列(二)) 一.消息队列概述 消息队列中间件是分布式系统中重要的组件,主要

【转载】大型网站架构演化

大型网站系统特点 高并发.大流量:PV 量巨大 高可用:7*24 小时不间断服务 海量数据:文件数目分分钟 xxTB 用户分布广泛,网络情况复杂:网络运营商 安全环境恶劣:黑客的攻击 需求快速变更,发布频繁:快速适应市场,满足用户需求 渐进式发展:慢慢地运营出大型网站 大型网站架构演化过程 (1)初始阶段网站架构:一台 Server 就刚需.应用程序.数据库.文件等所有资源都集中在一台 Server 上,典型案例:基于 LAMP 架构的 PHP 网站: (2)应用和数据服务分离:三台 Serve

大型网站架构系列:负载均衡详解(3)

原文:大型网站架构系列:负载均衡详解(3) 软件负载均衡概述 Ngnix负载均衡 Lvs负载均衡 Haproxy负载均衡 本次分享总结 一.软件负载均衡概述 硬件负载均衡性能优越,功能全面,但是价格昂贵,一般适合初期或者土豪级公司长期使用.因此软件负载均衡在互联网领域大量使用.常用的软件负载均衡软件有Nginx,Lvs,HaProxy等.本文参考大量文档,部分为直接拷贝,参考出处见负载均衡详解(4). 二.Ngnix负载均衡 Ngnix是一款轻量级的Web服务器/反向代理服务器,工作在七层Htt

大型网站架构演变

之前也有一些介绍大型网站架构演变的文章,例如LiveJournal的.ebay的,都是非常值得参考 的,不过感觉他们讲的更多的是每次演变的结果,而没有很详细的讲为什么需要做这样的演变,再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂 的技术,于是有了写这篇文章的想法,在这篇文章中将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系,希望能给 想从事互联网行业的同学一点初步的概念,:),文中的不对之处也请各位多给点建议,让本文真正起到抛砖引玉的效果.

大型网站架构系列:消息队列(二) (转)

本文是大型网站架构系列:消息队列(二),主要分享JMS消息服务,常用消息中间件(Active MQ,Rabbit MQ,Zero MQ,Kafka).[第二篇的内容大部分为网络资源的整理和汇总,供大家学习总结使用,最后有文章来源] 本次分享大纲 消息队列概述(见第一篇:大型网站架构系列:分布式消息队列(一)) 消息队列应用场景(见第一篇:大型网站架构系列:分布式消息队列(一)) 消息中间件示例(见第一篇:大型网站架构系列:分布式消息队列(一)) JMS消息服务 常用消息队列 参考(推荐)资料 本

大型网站架构系列:负载均衡详解(1)

原文:大型网站架构系列:负载均衡详解(1) 面对大量用户访问.高并发请求,海量数据,可以使用高性能的服务器.大型数据库,存储设 备,高性能Web服务器,采用高效率的编程语言比如(Go,Scala)等,当单机容量达到极限时,我们需要考虑业务拆分和分布式部署,来解决大型网站访 问量大,并发量高,海量数据的问题. 从单机网站到分布式网站,很重要的区别是业务拆分和分布式部署,将应用拆分后,部署到不同的机器上,实现大规模分布式系统.分布式和业务拆分解决 了,从集中到分布的问题,但是每个部署的独立业务还存在

大型网站架构系列:负载均衡详解(4)

原文:大型网站架构系列:负载均衡详解(4) 本文是负载均衡详解的第四篇,主要介绍了LVS的三种请求转发模式和八种负载均衡算法,以及Haproxy的特点和负载均衡算法.具体参考文章,详见最后的链接.   三.LVS负载均衡 LVS是一个开源的软件,由毕业于国防科技大学的章文嵩博士于1998年5月创立,用来实现Linux平台下的简单负载均衡.LVS是Linux Virtual Server的缩写,意思是Linux虚拟服务器. 基于IP层的负载均衡调度技术,它在操作系统核心层上,将来自IP层的TCP/

大型网站架构不得不考虑的几点问题

前言:这两天机器坏了,正在送修中,写个系列的大型http://www.aliyun.com/zixun/aggregation/11116.html">网站架构的文章,希望对有志在互联网做出一番事业的站长朋友们一些帮助. 注意:这里的大型网站架构只包括高互动性高交互性的数据型大型网站,基于大家众所周知的原因,我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了,我们以高负载高数据交换高数据流动性的网站为例,比如海内,开心网等类似的web2.0系列架构.我们这里不讨论是PHP还是JSP

大型网站架构演化历程

大型网站的挑战主要来自庞大的用户,高并发的访问和海量数据,任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户,问题就会变得棘手.大型网站架构主要就是解决这类问题. 本文内容大部分来自<大型网站技术架构>,这本书很值得一看,强烈推荐. 大型网站系统的特点 高并发,大流量 需要面对高并发用户,大流量访问. 高可用 系统 7 x 24 小时不间断服务. 海量数据 需要存储.管理海量数据,需要使用大量服务器.Facebook 每周上传的照片数量接近 10 亿,百度收录的网页数目有数百亿,Go