我们的网站压力究竟在哪里-凯发app官方网站

目前网站架构一般分成负载均衡层、web层和数据库层，我其实一般还会多加一层，即文件服务器层，这样我们在后面的讨论过程中，我们可以依次对这四层进行讨论；这里为了更具有说服力，我将用三个并发较大的生产环境来说明下，一个是我现在维护的电子商务网站（并发最大值2000，日pv500万左右，此并发并不是总这么高的，只是最高峰是有2900，下面的网站类似）、我的一拍网网站（并发最大值500，日pv50万左右）、以前维护的大型cdn广告网站（并发最大值5000，日pv5000万左右）。

首先说下负载均衡层，我们熟悉的硬件/软件技术有f5/lvs、haproxy，还有nginx，它们的性能都是非常优异的，且不说f5的抗并发能力，lvs现在在全世界范围内的应用，而且淘宝现在升级架构，也将lvs取代了f5，haproxy可能大家不是特别熟悉，但它确实在生产环境下表现优异，强大的吞吐能力，稳定性比之硬件过尤不及，再说下nginx，我是将nginx/haproxy keepalived架构用于了各种生产环境中的，经过长时间的线上观察，发现nginx/haproxy作为负载均衡器/反向代理也很稳定，就算并发压力过大，我们前面可以用f5/lvs来顶，而将nginx作为中层代理，这样的效果其实也不差，所以负载均衡层的压力不能算是特别大。

web层这块压力比较大的网站现在都换成了nginx作为web应用服务器，事实上，它的抗并发能力确实超过了预期；我朋友维护的一家门户网站，高峰期时某台nginx应用服务器的并发达到了一万以上，但nginx也很负责和稳定的提供服务，在实际的生产环境中，如果我们考虑到后端的数据库服务时，一万并发应该也算是一个比较大的数值了；另外，linux集群有一个优势，就是它的高扩展性，就算我们的网站的并发有一万以上，我们后端的web服务是apache，我们多加几台apache服务器即可，在实际的线上维护时，我们发现，高峰期间，实际上每台web的并发并不算是特别大，所以网站的压力在这一层我们也能通过技术手段加以克服。

再说下文件服务器层，由于网站的后期宣传策话，名气也越来越大，pv值也越来越高，原先的drbd heartbeat nfs（这个其实也只是单nfs，只不过我们利用drbd来保证nfs的高可用而已）已经越来越顶不住压力了，这个时候我们想到了分布式文件系统，我测试的的是moosefs，在内网测试了很长时间还是没敢用到生产环境下面，googel的分布式文件系统还是很成熟的，推荐大家学习；最后还是用采用以前的cdn传统的方法解决这个问题，即用了squid反向代理加速器来解决小文件过多的问题，nginx强大的正则处理分发能力，也让后端的nfs压力变得很小；另外，我还用采用域名的分散策略例如使用pics.xxx.com/pdf.xxx.com...来区分标记为a或b的一系列文件，这些文件存储的时候，依然按照标记，存到pics或pdf的服务器上。这个策略将区分机器的任务交由dns服务器来执行，扩容时会相应轻松。这需要web项目初期就规划好这些东东，后期才转用域名策略的成本比较高甚至不可以实现，大家可以注意下，其实这一层如果网站是专业的图片服务器网站时压力还是很大的，我们需要在这个上面投入足够多的硬件资源。

最后说下数据库层的压力，我觉得网站的pv和并发上去以后，数据库这块的压力是最大的，cdn大型广告网站我们用的是oracle rac方案，它保证了数据的高可用性，当然了价格也是非常昂贵的（如果使用高配置的pc服务器，oracle一般按照cpu个数收费）；那么免费的mysql数据库，面对这种并发压力大的情况，又用哪些方法呢？首先，我们说下传统的mysql主从方案，配置简单，单机mysql优化做好事性能也不弱，如果这种架构解决不了数据库的压力情况，我们可以考虑以下几种方案：

常规复制架构--master-slaves，是由一个master复制到一个或多个salve的架构模式，主要用于读压力大的应用数据库端廉价扩展凯发app官方网站的解决方案，读写分离，master主要负责写方面的压力。级联复制架构，即master-slaves-slaves,这个也是为了防止slaves的读压力过大，而配置一层二级 slaves，很容易解决master端因为附属slave太多而成为瓶劲的风险。

dual master与级联复制结合架构，即master-master-slaves，最大的好处是既可以避免主master的写操作受到slave集群的复制带来的影响，而且保证了主master的单点故障。

mysql的数据库切分，我们可以通过数据切恰好技术将一个大的mysql server切分成多个小的mysql server，既解了写入性能瓶颈问题，同时也一次提升了整个数据库集群的扩展性，从而解决了数据库压力过大的问题，这个现在也是我在生产环境中比较推荐的做法之一。

事实上我也跟许多系统维护人员和mysql dba线下交流过，现在生产环境下用得比较多的mysql架构有：一、mysql一主一从(这个优化得好，百多万pv的网站完全没问题)；二、drbd heartbeat mysql（mysql官方推荐）；三、mysql一主多从，读写分离，lvs或haproxy作读的lb。

这段时间一直跟老男孩前辈交流千万级pv的网站架构，系统架构其实是件艺术活儿，我们应该尽量做到以下几点:一、保证高可用；二、保证高可扩展性；三、尽量把用户往外面推(老男孩语)，足矣。