高并发大型网站架构设计思路(待补充)

一个大型的网站网站应该由以下6个子系统组成nginx


负载均衡系统数据库

反向代理系统缓存

Web服务器系统服务器

分布式存储系统网络

底层服务系统架构

数据库集群系统并发


为何要作高并发系统设计?负载均衡

事实上,针对于任何单一的网络服务器程序,其可承受的同时链接数目是有理论峰值的,经过C++中对TSocket的定义类型:word,咱们能够判 定这个链接理论峰值是65535,也就是说,你的单个服务器程序,最多能够承受6万多的用户同时链接。可是,在实际应用中,能达到一万人的同时链接并能保 证正常的数据交换已是很不容易了,一般这个值都在2000到5000之间,能达到上万已经很不错了。目前的门户网站动辄几千万的访问量,因此,高并发的 系统架构在所不免。框架


总体架构分布式

真实中的网站架构也许并不如此也能够实现高性能。可是高性能的网站莫不过如此。以下图所示。

第一 负载均衡系统

负载均衡系统分为硬件和软件两种。

硬件负载均衡效率高,可是价格贵,好比F5等。

软件负载均衡系统价格较低或者免费,效率较硬件负载均衡系统低,不过对于流量通常或稍大些网站来说也足够使用,好比lvs。


第二 反向代理系统

目前广泛使用Squid或者nginx,或者Lighttpd,Varish。

这四者又各自有很大的差别。

Squid:主要用来作反向代理,使用内存+硬盘

Nginx:能够反向代理+负载均衡+WWW解析

Lighttpd:反向代理能力通常,处理FastCGI比较好,消耗内存很小

Varish:主要作内存的反向代理,性能最优


第三 Web服务器系统

由Apache负责解析PHP内容,也能够用Nginx,或者Lighttpd,相对来讲Apache比较稳定。

 

第四 分布式存储系统

存储量很大,常常会达到单台服务器没法提供的规模,好比相册、视频等应用。所以须要专业的大规模存储系统。

 

第五 底层服务系统

根据各自须要由C/C++开发设计供上层CGI调用。

 

第六 数据库系统

1)使用MySQL数据库,考虑到Web应用的数据库读多写少的特色,咱们主要对读数据库作了优化,提供专用的读数据库和写数据库,在应用程序中实现读操做和写操做分别访问不一样的数据库。

2)使用同步机制实现快速将主库(写库)的数据库复制到从库(读库)。一个主库对应多个从库,主库数据实时同步到从库。

3)写数据库有多台,每台均可以提供多个应用共同使用,这样能够解决写库的性能瓶颈问题和单点故障问题。

 

 

客观地说,开源的框架作得更好。Openfire 应该是目前最火热的,它只是一个平台,你能够在此平台基础上作二次加强,支持集群等企业级能力。 偷偷的说,我知道的几家中型企业,就用这个作运营平台中的即时通信部分,量级约50万。 若是你不是运营级要求,就用这个应该是差很少了的。 若是非要自行开发,那么给你以下建议:◎ 分离:登陆服务器、通信服务器、消息服务器 和 数据库服务器;◎ 登陆服务器(有状态):除给Client提供登陆和分配通信服务器外,重点功能是提供关于用户目前链接在哪台服务器上的查询,因此全部查询基本基于缓存完成;考虑到单点故障问题,登陆服务器应双机冗余,但不能太多,不然双机之间的缓存同步代价过高;缓存可以使用开源组件。◎ 通信服务器(有状态):负责维护消息长链接,以及消息的收发;通信服务器缓存自身的全部用户链接信息,和部分(这个要时状况动态调整)非自身的热点用户链接信息(即该用户连在哪台通信服务器上);消息到达时,将消息转发给消息服务器进行落地;而后根据目标最终用户先查询本地表,查不到就去查询登陆服务器;而后直接寻找目标通信服务器,发送消息到达的通知;通信服务器的问题是没有Failover,可是也不重要,客户端链接不上就由登陆服务器从新分配新的通信服务器来提供服务便可。◎ 消息服务器(无状态):负责接收通信服务器所发来的消息,批量写入数据库中,以及供其它消息服务器存取;另外也提供历史消息查询这类辅助性功能;由于是无状态,因此集群较为简单,略。◎ 数据库服务器:略。

相关文章
相关标签/搜索