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

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

负载均衡系统

反向代理系统

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，但是也不重要，客户端连接不上就由登录服务器重新分配新的通讯服务器来提供服务即可。
◎ 消息服务器（无状态）：负责接收通讯服务器所发来的消息，批量写入数据库中，以及供其它消息服务器存取；另外也提供历史消息查询这类辅助性功能；因为是无状态，所以集群较为简单，略。
◎ 数据库服务器：略。