大型Web架构思想系列专题之-未雨绸缪

      首先要感谢诸多朋友对鄙人的一些拙见表示关注，不少朋友反应上一篇的分享有点意犹未尽，我的理解可能是大家觉得我写的不够快。呵呵...由于系统整理相关资料需要一段时间，另外要尽量保持原创的风格。所以周期会稍微长一点点，但我尽量会一周写1-2篇相关专题。

      上篇看到不少反馈，主要是在“瓶颈”这个问题上有些疑问。的确大型站点很容易造成瓶颈问题，但是这些问题都需要在需求分析阶段或者之前就要弄明白这些问题，至少要知道将来可能会存在哪些缺陷。不知道用-未雨绸缪这个词合不合适。如果想建一座摩天大厦，我想在暴风雨来临之前就应该把大楼都建踏实了，至少建造大楼的方案都已经研究过了。同样一个大型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已经成功了一小半。

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、读写
      假设最大的读写在图片服务器，且配置如下：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用户的流量。

      有了这些数据我们在做系统架构的时候就知道如果规避种种问题，当然在架构阶段尽可能的为升级留有余地。我喜欢在建楼之前画尽可能多的图纸，做尽可能多的实验。不管怎样我们都热爱这份Web大楼的建造，有的三两层，有的几十层甚至上百层。高度说明不了问题，关键在于你的心是否容的下这所建筑！