大型Web架构应该考虑的问题--转--修改

 

一个大型Web站点架设要考虑的问题很多，但首要的，基本的首先要考虑到，那我们不妨就开始做一些数据分析研究，四个方面：数据库、网络架构、网络带宽、读写。

 

1、数据库
      假设我们前提是：数据库服务器操作系统采用Linux，数据库采用Oracle 11g，CPU采用至强3G x 2或x4，内存8G或16G或以上。如果从内存角度来衡量系统的最大并发连接和处理数量。抑或oracle数据库安装在一台拥有16G内存的服务器上，按照Oracle推荐的，分配给Oracle实例的内存为物理内存的80%。那么对于OLTP应用来，pga_aggregate_target(20%的空间用来进行PGA的存储)的值大约就是2621MB[(16*1024MB×80%)×20%]。这些内存将被分配与PGA区域，并且这个是和并发连接有直接关系的，每个并发的连接都需要一定量的PGA内存以执行SQL语句，假设每个用户session平均需要1M（按照通常的经验值）的空间来计算，那么从并发连接数上来讲，共可以支持近2600左右个并发连接数。另外从TPC-C基准角度方面估算数据库所能支持的并发用户数。根据TPC-C官方网站对Oracle Database 11g Standard Edition One测试结果http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=107091301，在硬件配置为1 CPU、4 Cores的情况下的tpmC值约为10万左右，假设被评估系统采购的数据库服务器为4 CPU，在不考虑任何其他资源消耗的情况下，那么tpmC值能够达到40万。而业界认可的一般性应用系统与TPC-C基准程序的复杂性比例为10-20：1，此处我们采用较低的10：1，另外假设系统数据库交换每60秒处理5笔业务，根据以上基础上推算出该系统所应达到的并发数为：40万tpmC/(10*60/5)=3333.3，从以上分析可以看出如果要达到Web并发5K已经成功了一小半。

 

 补：

解决单点并发瓶颈，目前最有效的方法就是增加镜像和缓存节点数据，增大核心服务中心对外的接口。
解决DB最有效的方法就是群集和单表散列，同时将联系不太紧密的数据分库分机处理。

  

2、网络架构
      常用网络架构大都在硬件防火墙存在TCP并发连接瓶颈。通常平台使用Web界面访问，访问方式采用TCP短连接方式传输数据，我们使用clearsight对与该平台业务类似的淘宝以及阿里巴巴页面的TCP连接数进行了测试，结果没个页面平均短连接数保持在30个左右。目前主流的高端企业防火墙（电信级防火墙除外）在理想情况下（防火墙不受到外界任何攻击，防火墙不开启任何附加的保护策略，只使用默认的防火墙策略）每秒TCP连接数可达30000并发，如果TCP连接在1秒内建立完成，则一个分布式处理中心大约可以承受30000/30=1000个TCP并发。这一点不是非常满意，这样一来在分布式处理中心还要做些文章。

 

   补：多数防火墙都存在并发连接瓶颈问题，不过，有的时候也是很有必要的，是一种安全保护措施（跟自己定的安全策略有关）

3、网络带宽
      对于网络带宽，假设系统有1000个并发用户数，网络是100Mbps，则有效带宽为12.5MBytes，每页面的平均大小按照100KB计算，那么不管服务器本身速度多快，最好的响应时间为：2000User*200KB/(12.5MBytes*1024) = 31.25秒，即：如果网络是100Mbps的话，最好的页面访问执行时间也就是31.25秒。这样无论服务器的响应有多快，总是要在网络上传输这么大的数据量。因此，网络将是一个很大的瓶颈。如果网络是125MBytes即约1Gbps，则响应时间是3.125秒，所以并发飙升，带宽费用将是一笔巨大的开支。

4、读写（IO）

       IO也是一个容易出现问题的地方，容易引起各种问题，如DB访问速度等；    
      假设最大的读写在图片服务器，且配置如下：1、CPU：至强3G x 2，或同级别的其他CPU；2、内存：2G或以上；3、硬盘：300G x 2做RAID 0或146G x 4做RAID 1+0。就普通的服务器而言，其使用的SCSI硬盘的理论最大传输速度是320M/S，实际可能只有一半。按照系统需求中一般的页面的响应时间应在5秒内（局域网内为3秒内，互联网上一般应该在5秒内）的要求计算图片总流量为800M（按照实际值计算）。如果按照每个页面上的图片的平均大小为100K来计算，普通配置图片服务器可以承受8000用户的流量。