高并发Web 电商系统的设计与优化∗

黄芝龙 徐莉莎 瞿少成

（华中师范大学物理科学与技术学院电子信息工程系 武汉 430079）

1 引言

随着互联网的快速发展和互联网用户量的急剧增加，高并发Web应用系统面临更大的并发访问压力，容易出现网站响应时间过长，甚至会出现服务器压力过大，导致系统崩溃等问题。12306 铁路购票网站就是一个典型的高并发Web 应用。2012年春运期间，该网站日均近10 亿次访问，同时在线人数高达500 万，如此高的负载与高并发量使网站访问拥堵，频繁出现错误，大量用户买不到票［1］。

电商应用是一类有代表性的高并发Web 应用。目前针对高并发Web 应用系统性能低下的问题，解决的方案主要围绕以下几个方面:提高数据库配置［2］、优化数据库性能［3］、优化服务器参数配置［4］、优化网络拓扑结构［5］和Web 容器的性能［6］，但上述方法限制了系统的扩展性，并加大了系统的开发和维护成本。本文从网站的系统架构入手，提出了一个高并发Web电商系统的解决方案，针对Web前端、后台程序、数据库和服务器4 个部分的处理给出了优化方案。在最近的100 次测试中承受住了近12 万次的访问，在解决高并发访问的问题上取得了较好效果。

2 电商系统的特点、目标和流程分析

2.1 电商系统的特点

电商系统平时的访问量不是特别大，因为用户会在不同的时间段来选择商品。但是，在年中和双十一等购物狂欢节，同一时间访问的用户量过多，后台服务器瞬间接收的请求量过大，巨大的访问量会导致服务器崩溃等严重后果，降低用户体验的同时也会造成很大的损失。此时，电商系统的前端Web和后台数据库查询都面临高并发问题。

2.2 电商系统的设计目标

电商系统的设计目标主要有:1）满足高并发访问。这是电商系统的主要目标和首要解决的问题。2）高可用性。将停止服务时间降到最低甚至是无间断服务。3）可扩展性。随着访问量的增加，系统具有良好的伸缩能力。4）高可靠性。经过优化的体系结构和合理的备份策略，使得电商系统具有稳定性，发生故障时能快速排查和恢复。

2.3 电商系统的流程

电商系统的流程为用户注册、用户登录、用户查询商品、添加购物车、提交订单、付款、送货等。具体流程是用户在访问商品信息时看到商品的价格、用途等属性，将需要的商品加入购物车。购物车自动计算商品的总价，之后用户想提交订单时，若用户是游客，则会提示用户注册；若用户是电商系统的会员，则在用户信息齐全的条件下可以进行支付。支付成功后接到支付成功的信息而更改状态，商户通知物流发货，用户收到货物后确认收货，交易完成。

3 电商系统的架构与负载均衡

为了解决高并发问题，最重要的是系统架构设计。本节首先介绍电商系统的功能模块及瓶颈，然后介绍负载均衡技术，最后给出一个应对高并发的架构解决方案。

3.1 电商系统的功能及瓶颈

如图1 所示，电商系统的主要功能包括商品模块、用户模块、订单模块、反馈模块和统计模块。

商品模块包括商品的添加、修改及商品信息的管理。用户模块包括用户的注册、登录、权限的管理和用户信息的维护。统计模块包括统计商品信息、用户信息和用户点击，购买的商品的统计信息。反馈模块收集用户对商品的评论，同时回答用户的问题。订单模块是用户添加购物车、下单、付款和物流等流程。

图1 电商系统的功能模块

在功能模块中，用户模块一般不会成为高并发的瓶颈。系统规定只有注册并登录过的模块才能参与购物，由于注册和登录的时间分散，一般不会造成高并发问题。反馈模块和统计模块也不是高并发问题产生的主要地方。商品模块和支付模块往往是高并发问题出现的主要位置，在购物狂欢节开始的短短几分钟内，会产生极大的并发流量，对系统造成巨大压力，本文应用负载均衡和缓存等技术来减轻并发压力。

3.2 电商系统的负载均衡方案

在电商系统中，尤其是在高并发、多节点的情况下，经常会出现服务器负载过重的情况，而单纯的升级一台服务器的配置已经不能满足需求，必须设置多台物理服务器，采用负载均衡技术构建系统。负载均衡好处是:1）将负载分担在多台服务器上，解决了高并发难题；2）增强了安全性；3）改善了可扩展性。

负载均衡可分为，1）前端Web服务器的负载均衡；2）逻辑层应用服务器负载均衡；3）后端数据库和文件系统的负载均衡。

负载均衡实现的方法主要有:1）软件负载均衡；2）硬件负载均衡；3）反向代理负载均衡；4）DNS负载均衡；5）基于NAT的负载均衡［7］。

本方案采用硬件和反向代理方式，用F5 负载均衡器和Nginx 反向代理服务器实现负载均衡。F5 由于其稳定性和技术成熟，应用于诸多大型网站［8］。F5 负载均衡器的优点有:1）管理简单，方便操作和维护；2）容易部署和扩展；3）提高系统安全性；4）F5 具有缓存功能；5）开启并使用了 F5 的SSL加速功能。Nginx 是一个高性能的HTTP 和反向代理服务器，是目前使用很广泛的HTTP 软负载均衡器，因高效的性能、稳定性和低系统资源的消耗而闻名于业界。许多大型门户及商业网站都采用Nginx进行HTTP网站的数据分流。

3.3 电商系统的架构

电商系统的系统架构图如图2所示。

图2 电商系统架构图

根据三层逻辑结构，将Web 服务器、应用服务器和数据库服务器三层分离。在Web 服务器群前端应用Nginx 反向代理服务器和F5 负载均衡器进行负载均衡，并在Nginx反向代理服务器和F5负载均衡器中进行缓存设置。系统使用服务器集群和分布式系统改善性能，将多台Web服务器与多台应用服务器相连，最后再连接分布式缓存服务器、文件服务器和数据库服务器，其中数据库服务器分为主从服务器，主服务器主要完成写操作，从服务器完成读操作。

4 电商系统的优化方案

在实际应用中，影响Web电商系统性能的因素有很多，本节主要从Web前端、后台程序、数据库以及服务器四个方面给出应对高并发的系统优化方案。

4.1 电商系统的Web前端优化方案

对于高并发电商网站，页面质量是影响网站运行速度的重要原因之一［9］。首先要考虑的是页面的大小，如果页面设计的太大，在页面加载时就会耗费大量的网络带宽，因此，页面设计应尽可能地简洁，以此减少不必要的网络流量，进而有效的减缓高并发带来的带宽压力。

另外，现在广泛采用动态网页，在加载这些页面中的动态元素时，也会大大增加服务器的负担，利用页面压缩技术和页面静态化技术可以有效解决该问题。电商系统中的首页index.jsp 和支付页面pay.jsp 是用户最常访问的两个页面。本方案在Web 服务器上部署了页面静态化服务。当用户需要访问首页和支付页面时，就不需要访问应用服务器，访问到的就是Web 服务器中已经静态化的index.html 和pay.html。这样可以大幅提高加载和访问速度。页面压缩技术是指系统开启Apache 的Gzip压缩，将页面压缩后再传送。此技术有效减少了页面尺寸，节省了大量带宽，缓解了高并发压力。

4.2 电商系统的后台程序优化方案

4.2.1 电商系统的缓存方案

缓存技术是解决高并发难题的一个重要手段。电商系统中的缓存技术是指将用户要访问的数据存在服务器内存中，当用户要访问这些数据时就不再访问数据库；而数据库询问是系统最耗时的工作，该技术大幅提升了访问速度，减小了各台服务器的负担，缓解了高并发所带来的拥堵。根据缓存的位置与内容不同，Web 缓存主要分为:1）前端页面缓存；2）浏览器和客户端缓存；3）后端数据库的数据缓存［10］。

根据电商系统的系统架构图，本方案利用CDN服务器、Nginx 服务器和F5 服务器提供缓存功能，将首页index.html、支付页面pay.html等经过处理的常用静态化页面放进缓存。在高并发的环境下，这样可以有效地降低前台Web 服务器集群的访问压力，同时也可以大大提高访问效率。此外，为了减小数据库访问压力，本方案在数据库与应用服务器之间配置了redis 服务器。将用户常用的查询结果存在redis 缓存中，当用户再次访问时，先检查缓存中是否有该查询结果，如果有则直接从缓存中读取，如果没有才访问数据库，这样可以减少数据库服务器的访问压力。

当缓存区存满时，要删除旧的数据，添加新的数据，因此缓存的替换算法也是需要考虑的问题。在电商系统中，首页中的商品信息经常是最常用的商品信息，被访问量最多的数据要长时间留在缓存中，因此缓存的替换算法应用最近最少使用算法，最近最少使用算法原理如图3所示。

图3 最近最少使用算法

假如缓存区能存储三个数据，在数据没有存储满时，新数据会添加在缓存中。而在缓存存满时，若再去更新缓存，则会删掉最近最少使用的数据，更新后来有的数据，图4为更新缓存数据的流程图。

图4 最近最少使用算法流程图

应用最近最少使用算法，能将长时间无人查询的记录删除，从而易于插入新的记录。最近最少使用算法是将每个存储值添加一个计数器的标签，当这个值被查询或是更新时就同时更新对应的计数器。因此，当缓存区满时，计数器中最低值将会被优先替换掉。

4.2.2 多线程

高并发访问是电商系统的基本需求，由于线程比进程更轻量，更少占有系统资源，切换代价更小，所以Web 应用服务器都采用多线程的方式响应并发用户请求，因此本系统采用多线程编程。

例如用户的下单流程，对于用户提交的订单请求，如果用户点击提交订单，则系统会自动调用用户信息和商品信息。调用之后验证该商品是否有货，配送区域是否符合要求等信息，而查验的用户信息是用户是否为游客，用户的id是否被禁用等信息。只有商品信息和用户信息都验证通过时，系统才认为该订单提交成功。如果有一项不符合要求则认为这次订单提交失败。这两部分验证无论先后都对判断结果没有影响，并且这两个判断相互之间不影响，可是如果顺序执行会降低效率，因此应用多线程来处理业务逻辑内能并发处理的事情，从而达到提高效率的目的。

如果未添加多线程，则程序按顺序执行，该程序执行流程如图5所示。其中，examineProduct（）方法会检验商品库存，商品配送区域是否满足需求，而examineUser（）方法则会验证用户的地址，权限等是否符合要求。因为这两部分的验证是互不影响的，所以将两种方法并行处理，然后集中处理返回数据就会提高处理效率。

图5 不添加多线程处理的流程图

用户提交订单后，如果采用多线程的处理方式，就可以同时调用两种方法，不过其内部处理的顺序是不定的。多线程处理用户提交订单的流程图如图6 所示。其中用户数据的获取和商品数据的获取是相对独立的，对两者用多线程处理后的结果进行判断，可以减少处理时间。对于其他如付款和计算商品价格等流程也利用到多线程处理技术，提高系统的处理效率。多线程处理是调用jdk自带的Thread对象来完成，并且一个Thread有一个完整的生命周期，在处理完成后，线程会自动调用destory进行销毁，不会占用系统资源。

4.3 电商系统的数据库优化方案

4.3.1 数据库的读写分离

电商系统的用户大部分是查看商品信息、浏览推荐的内容和查看资料等读的内容。用户注册，下单量比查询量少得多。由于数据库压力较大，所以系统部署了多个数据库来分担请求。但为了保持数据的高效性和一致性，仅设置了单个服务器进行写入，其他的服务器则接受读取的操作。其中负责写入的服务器称为主服务器，其在一定时间内将服务器中的数据同步到从服务器中。如图7 所示，本系统的服务器利用的是master-slave 模式，将数据库服务部署在多台服务器上，一台master服务器专门负责数据的写入，而其他服务器则负责返回业务逻辑层读取的数据。同时，现有master服务器还会定时对另一台master服务器进行备份，如果主服务器宕机，就立即启用备份服务器作为主服务器。

图6 添加多线程处理的流程图

图7 数据库读写分离

4.3.2 创建索引

当数据库执行操作语句时，一般是根据条件进行全表扫描，每当遇到匹配项时，便将其添加到搜索结果内；在已经针对某唯一标识建立索引时，查询时会优先到索引中定位符合条件的记录数，从而得到所要结果。这样可以减少查询的记录数从而大幅提升查询速度。建立索引是为了提高数据库查询速度［11］，但是索引的建立和存储也会占用一定空间，修改表内数据时索引也要进行相应的维护，进而影响到维护数据的速度，通常在有以下特征的字段上建立索引:需要频繁和快速查询的字段；建立了主键或外键的字段；定义了排序规则的字段；在检索中需要组合到一起的字段。

4.3.3 数据库操作语言的优化

对于关系型数据库，通常需要写数据库操作语句来访问所需数据，数据库查询效率是影响电商系统并发响应能力的一个重要因素，因此对数据库操作语句的优化成为了不可少的一部分。对于ORACLE 数据库中的SQL 优化原则，例如:将具有最大限制的条件放在where 语句的最后面，从而减少子句的访问次数［12］；需要使用联合查询时，对from 后面的各个表应当选择记录条数最少的表来作为基础表。本方案在研发过程中，利用这些原则对代码中的SQL语句进行了优化，提高了数据库的访问速度。

4.4 电商系统的服务器优化方案

4.4.1 图片服务器分离

对于电商系统的Web 服务器来说，不管是Apache 还是其他容器，图片是最消耗资源的，因此有必要将图片与页面进行分离，部署独立的图片服务器，甚至是多台服务器，从而减少高并发页面访问请求的服务器系统压力，并且可以确保系统不会因为图片问题而崩溃，在图片服务器和应用服务器上，可以进行不同的配置优化。

4.4.2 服务器集群技术

对于单台服务器的Web系统来说，在高并发的情况下，服务器的处理能力和I/O 能力肯定会成为服务的瓶颈，如果用户的访问超出了服务器能承受的范围，就可能出现严重的后果甚至宕机。可以通过各种方法将单台服务器的性能最优化，然而单台服务器的性能有限，这时就必须考虑服务器集群技术了。服务器集群技术是将很多台服务器集中起来进行同一服务，各台服务器之间可以通过内部局域网进行相互通讯，在用户看来就像是只有一台服务器。集群可以应用多台计算机来进行并行计算，从而获得非常高的计算速度，也可以用多台计算机做备份，如果其中某台服务器出现故障，那么它所运行的服务就会被其他服务器替代，从而实现整个电商系统的高性能和高可靠性。

5 测试与应用

本方案分别对优化前和优化后的电商系统进行压力测试，选取并发量最高的首页index.jsp 作为测试页面。测试指标包括响应时间、各种服务器的CPU 利用率和最高并发量。在3 万并发访问的情况下，优化前后各测试指标的对比见表1。

表1 优化前后各测试指标对比

由表1 的对比可知，电商系统在优化后各项指标都有明显提升，其中响应时间减少约25%，各服务器的CPU 利用率降低45%左右。另外，在优化前，由于各服务器CPU 利用率已接近或达到90%，由此可估计系统最高并发量为3 万左右；优化后经测试，在系统并发量为6 万时，各服务器CPU 利用率接近90%，估计最高并发量为6 万左右。另外，在不同并发数时，负载均衡器F5 和Nginx 对三台Web服务器分配的session数见表2。

表2 不同并发数时的session分配情况

由表2 中的数据可知经过F5 和Nginx 的调度，负载是接近均衡分配的。

本电商系统经多方面测试后上线应用。在最近的一次大型购物活动中，该系统承受住12 万人次的在线访问，最高并发量为5 万人，此时Web 应用服务器的CPU利用率约为70%，应用服务器CPU利用率约为55%，数据库服务器CPU 利用率约为60%。系统的各部分功能运行正常，各个服务器的CPU 利用率不超过80%，响应时间在2s 左右，这也验证了本方案可以有效解决高并发问题。

6 结语

本文设计了一个高并发Web电商系统，分析并提供了在高并发情况下的优化方案。首先分析了高并发Web电商系统的响应时间过长，服务器负载压力过大和系统易崩溃的原因并提出了一个有效的优化方案。从负载均衡、Web前端、后台程序、数据库以及服务器几个方面进行了优化。与其他高并发Web 应用系统相比，该系统具有可扩展性、高可用性和高可靠性等特点，并有效解决了Web电商系统的高并发难题。对类似高并发应用系统的优化具有重要意义。另外，随着用户量的持续增长，对电商系统的要求会越来越高，如何进一步优化电商系统还有待研究。