大规模，高并发网站开发经验都有哪些

高并发量网站解决方案

一个小型的网站，可以使用最简单的html静态页面就实现了，配合一些达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单。随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。

大型网站，比如门户网站，在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。这几个解决思路在一定程度上意味着更大的投入。

1、HTML静态化

其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化、有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现。比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储在数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

2、服务器分离

大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，是最消耗资源的，于是我们有必要将与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的、甚至很多台的服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为问题而崩溃。

在应用服务器和服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持、尽可能少的LoadMole，保证更高的系统消耗和执行效率。

3、数据库集群、库表散列

大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。

在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。

我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。

sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

4、缓存

缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。

架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。

5、镜像

镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和ENet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

6、负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的高端解决办法。

负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。

（1）、硬件四层交换

第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。

第四层交换功能就像是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。“Yahoo中国”当初接近2000台服务器，只使用了三、四台Alteon就搞定了。

(2)、软件四层交换

大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。

软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是LinuxVirtualServer，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的强壮性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。

对于大型网站来说，前面提到的每个方法可能都会被同时使用到，这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会。有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大。

最新：CDN加速技术

CDN的全称是内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。

CDN有别于镜像，因为它比镜像更智能，或者可以做这样一个比喻：CDN=更智能的镜像+缓存+流量导流。因而，CDN可以明显提高Internet网络中信息流动的效率。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等问题，提高用户访问网站的响应速度。

CDN的类型特点

CDN的实现分为三类：镜像、高速缓存、专线。

镜像站点（MirrorSite），是最常见的，它让内容直接发布，适用于静态和准动态的数据同步。但是购买和维护新服务器的费用较高，还必须在各个地区设置镜像服务器，配备专业技术人员进行管理与维护。对于大型网站来说，更新所用的带宽成本也大大提高了。

高速缓存，成本较低，适用于静态内容。Internet的统计表明，超过80%的用户经常访问的是20%的网站的内容，在这个规律下，缓存服务器可以处理大部分客户的静态请求，而原始的服务器只需处理约20%左右的非缓存请求和动态请求，于是大大加快了客户请求的响应时间，并降低了原始服务器的负载。

CDN服务一般会在全国范围内的关键节点上放置缓存服务器。

专线，让用户直接访问数据源，可以实现数据的动态同步。

CDN的实例

举个例子来说，当某用户访问网站时，网站会利用全球负载均衡技术，将用户的访问指向到距离用户最近的正常工作的缓存服务器上，直接响应用户的请求。

当用户访问已经使用了CDN服务的网站时，其解析过程与传统解析方式的最大区别就在于网站的授权域名服务器不是以传统的轮询方式来响应本地DNS的解析请求，而是充分考虑用户发起请求的地点和当时网络的情况，来决定把用户的请求定向到离用户最近同时负载相对较轻的节点缓存服务器上。

通过用户定位算法和服务器健康检测算法综合后的数据，可以将用户的请求就近定向到分布在网络“边缘”的缓存服务器上，保证用户的访问能得到更及时可靠的响应。

由于大量的用户访问都由分布在网络边缘的CDN节点缓存服务器直接响应了，这就不仅提高了用户的访问质量，同时有效地降低了源服务器的负载压力。

对服务器来说，硬盘因为其机械结构，是最容易出现故障的设备。但恰恰是这最容易出现故障的设备中，存储着对企业来说最至关重要的IT资源——数据。一旦硬盘出现故障，会给企业带来重大的损失。据统计，为了解决硬盘故障带来的损失，目前全球每年的数据恢复市场价值大约在千亿美元——而这仅仅是是企业损失的一小部分。近年来，为了解决这一问题衍生出了大量的技术如：Raid、双机热备等。但这些技术都是在基于增加磁盘的数量的方式来尝试解决问题，降低了数据丢失的概率，但同时大大增加了运维成本，提高了管理的难度。

为此，蚁巡运维平台尝试引入一种新的方式，通过远程实时监控服务器硬盘的健康状态，达到在不增加硬件成本和管理成本的基础上保障数据安全的做法。通过蚁巡运维平台，可以自动发现安装了SMART标准技术的硬盘并远程监控其磁盘的健康指标。

SMART的全称为“Self-Monitoring Analysis and Reporting Technology”，即“自我监测、分析及报告技术”。支持SMART技术的硬盘可以通过硬盘上的监测指令和主机上的监测软件对磁头、盘片、马达、电路的运行情况、历史记录及预设的安全值进行分析、比较。当出现安全值范围以外的情况时，就会自动向用户发出警告。几乎所有主流的硬盘，包括固态硬盘都支持这一技术。但该技术只适用于单机环境，且必须手工获取数据，使用该技术防止硬盘故障的管理成本很高。而在蚁巡中，可以批量的、远程的、实时的监控使用了该技术的硬盘，大大降低了管理成本。

同时，通过蚁巡还可以获得硬盘的使用时间、使用次数等基本指标数据。可以有效的评估硬盘的使用情况，从而进一步评估设备的使用率、寿命等信息。

据统计，通过这项技术，可以提前发现超过60%的硬盘故障，给企业带来的价值无可估量。

前段时间出差，在北京现场遇到一个F5网络不通问题，现记录下来以备后面查阅。

问题解决方案很简单，主要记录下排查过程中的思路。

现场环境是使用F5做负载均衡，即F5对外提供服务地址和端口，F5负载转发请求到后端业务服务器。环境是客户的测试环境，F5也是客户的。我们向客户提交F5转发策略和F5健康检查策略，等待网络开通。本来以为不用担心这一块问题，但客户的网络部门配置完成后，网络一直不通。由于未接触过F5所以前面不知怎么和客户沟通，后拿到F5账号和密码，登录进去后开始定位问题。

进去F5登录界面后，看到配置的转发策略中，后端服务器健康检查是失效的，即F5认为后端服务器不在线。这是怎么回事？

这里首先弄清F5健康检查规则是怎么回事？

F5健康检查规则是指F5在一定周期内向后端服务器发送请求来确认后端服务器是否在线。

如下图：

图中 Send String 就是 F5发送的请求字段， Receive String 是F5接收到响应后对比字段，只要响应中有对比字段则认为成功。Receive String为空时，F5接收到响应就认为成功。

继续排查F5健康检查失效问题。

问题主要在两点：1 发送请求字段写的有问题。2接收的响应中没有包含200 OK，匹配不上。

上述这两点通过抓包可以分析。因为现场没法登陆F5服务器上去抓包，下面就利用nc工具模拟F5发请求。

nc 全名 Netcat (网络刀)，是一个强大的网络工具，可以模拟发送http请求。

下面在和业务服务器同网段的任意一台服务器上装上nc 工具。

然后使用nc 命令发送请求，请求如下：

引号中的请求字段和F5中sendString一致。

利用nc 发送http请求后，得到的响应如下：

把得到的结果复制到一个html文件中，然后打开如下：

现在F5健康检查问题找到了：是因为业务服务器返回400错误，但F5匹配200 OK， 没有匹配上造成F5认为服务器有问题。

继续看问题，nginx为啥会返回错误码400？

这也是本片文章重头戏。

网上查询原因如下：Nginx官方文档介绍，400状态码含义如下：

上面是http11的rfc关于host部分的解释，从上面我们了解到如果一个http11的请求没有host域，那么server应该给client段发送400的状态码，表明这个请求server不能处理。而对于Nginx server来说，也遵循这样的方式，说明client发送了一个无效的请求，Nginx server无法处理，于是返回了400的状态码。

本次故障中，客户端的调用方式没有使用host 参数，传递了空的Host头给服务端，一旦Nginx设置了proxy_set_header Host $http_host，空Host头就传给了后端。然而，在http 11的规范中，Host只要出现空，就会返回400，所以出现了这个故障。

最后，重新修改发送规则如下：这里HOST随便写一个地址就可以。

利用nc 命令测试，结果如下：

F5修改发送规则后，终于网路联通了，如下图：

至此，问题解决。