《支持高并发的购物系统设计与实现》11000字（论文）

系统分析3.1可行性分析3.1.1技术可行性整个系统在Windows下运行，只需按照性能要求配置足够的Web服务器。本系统使用的技术均十分成熟。系统的开发无论大小，无论运用在什么场景，都是需要一定的技术支持的。在开发前的准备工作中，一定要对开发人员的技术说明做出整体评估，掌握开发人员的技术栈。并对系统所运用到的技术进行规划与匹配，否则在开发过程中对开发人员更加麻烦，增加了工期与经济成本，很可能会造成难以忍受的损失。通过课上所学内容或者网上资料，本次开发所运用到的环境是可以自行安装，使用MySQL管理用户数据，后端使用Java处理业务逻辑，使用JDBC对数据库进行操作，系统使用目前最流行的SpringBoot框架进行搭建，并运用Nginx，Redis等在高并发领域或许不可缺少的相关技术来完善系统，在系统完成了基础功能有对系统仅有有针对性，有计划性的优化，实现其具有面对秒杀活动的基本性能。3.1.2经济可行性本系统的开发是有一定难度的，是有一定程度上的科技资源消耗的。系统的设计和开发阶段需要一定的经济资源和人力资源的投入。系统的稳定开发工期与后续的运行，跟大程度上取决于前期对系统投入的经济资源与人力资源，这决定了系统是否可以满足程序使用方的需要，这样也避免了在开发过程中因为投入经济问题导致中途开发失败或者之后的投入产出比不符合使用方的现实利益而引发出一系列的纠纷。因此需要对系统进行经济可行性分析。由于使用的技术均开源且较为成熟，所以学习、使用成本很低。但是因为要解决高并发的问题，服务器的开销是必不可少的。因此比其他的系统成本要高，但是使用了分布式之后，平台便可以根据自己的需求与流量决定服务器的数量，这便给了平台选择服务器的权力，节省了成本。3.1.3操作可行性待本系统开发出来之后，对系统的操作不会要求其用户必须专业技术，只需要用户按照页面提示等信息一步一步的进行操作，便可以查找下单到用户想要的商品。因此本系统是具备操作可行性的。 3.2系统需求分析3.2.1功能需求分析根据软件工程的要求，开发系统之前需要有完整的任务需求分析，俗话说好的开头是成功的一半，需求分析的质量决定着该系统的开发意义。对于双十一限时秒杀系统平台的设计与实现来说前期的分析更加显得尤为重要，需求分析决定了系统的开展与设计，质量过硬的需求分析可以将许多问题提前解决，这样不仅在开发过程中可以顺利进行，做出的成品也将更加完美，用户将更加满意。任务需求分析在整个系统的开发过程中非常重要，它直接决定着系统在开发过程中的质量，任务需求分析的是否完善，是否设计整个系统的步骤，设计思路，可能出现的问题，优化方案等在其中有对应体现。这些都决定着需求分析的质量，进而决定着软件的质量，能否让客户满意。需求分析是整个体统开发的前提。本课题要求实现一套双十一限时秒杀系统的设计与实现，系统实现主要是对用户根据自己的手机号进行获取OTP短信信息，用户注册、登录、秒杀商品、商品抢购等操作。双十一限时秒杀系统的基本要求：功能要求：商品管理、用户模块、订单模块等功能模块，如图3-1所示。图3-1系统模块图（2）安全与保密要求：用户需要通过获取验证码才可以注册，登陆时需要注册手机和密码，并且密码与用户信息分开管理。（3）环境要求：支持多种平台，可以在Windows系统上运行，也可以部署在Linux等服务器集群上。3.2.2性能需求分析秒杀系统的特点是在极短的时间内并发量极大，但是实际上可以秒杀成功的请求却很少，所以如果不在前端进行拦截的话，大概率会造成数据库读写冲突，甚至导致死锁，最终请求超时，为了解决这一问题，一定充分利用缓存，利用好缓存可以极大的提高系统读写速度。在设计时，浏览器端可以将活动页面静态化，尽量减少动态原始，通过CDN来抗峰值，并且减少前端到后端的数据请求；后端设计，虽然前段设置了限流，但是当秒杀的用户量很大时，到服务层的请求数量还是很大，所以可以采用消息队列缓存请求、缓存应对读请求、缓存应对写请求的方式进行缓解。4系统设计4.1系统结构设计为了反应整个系统的结构与其他一些元素之间的关系，我们需要进行系统架构的设计，也是为了解决软件系统的复杂度所带来的问题，细分下来也有流程的梳理，理清代码逻辑，并且按照模块逐层分析，使层次结构分明，功能接口之间的连接正确。最好结合数据库，将表的逻辑理清，有助于项目的开发。系统的结构设计决定着该系统的上限，因此对系统进行合理的结构设计可以使今后的维护工作变得更加轻松，节省公司成本，合理运用资源。对于整体项目的部署，将使用分布式扩展来完成，通过部署线上来解决其单机容量的问题。其中，包括Nginx反向代理负载均衡，分布式会话管理，使用Redis实现分布式会话存储等。分布式结构图如图4-1所示。图4-1系统分布式结构图4.2系统流程设计4.2.1注册流程进入系统首先需要用户信息，只有登陆了才能进行功能模块相对应的操作。没有账号则需要在注册页面注册信息。如果用户输入的账号密码有误，则会提示用户重新输入。如图4-2所示。图4-2注册流程图4.2.2添加信息流程用户信息的添加需要在注册页面按照页面填写相关信息，信息格式无误后即可成功添加。商品信息的添加也是如此，若经过检测信息有误或者不符合格式则需重新填写，流程如图4-3所示。图4-3添加信息流程图4.2.3下单操作流程分析下单流程分析，在下单时系统会对当前页面的用户进行判断，只有注册过的用户才可以在本平台进行下单操作。4.3高并发模块设计4.3.1并发模块分析秒杀系统的主要模块分为商品模块、订单模块和用户模块。商品模块的主要功能是对商品进行如下操作：添加、修改和设置秒杀信息。订单模块的主要功能是用户对商品的下单和支付操作。用户模块则是获取验证码、注册和登录等功能。在这些功能模块当中，下单支付、商品浏览和商品详情页等模块往往是产生高并发问题的主要位置。在秒杀活动开始后，巨大的流量会在短短的几分钟之内浪涌般席卷而来，巨大的并发流量普通系统无法应对，所以我们使用Nginx来对数据进行分流。4.3.2秒杀系统的反向代理与负载均衡方案当web前端项目，后端代码与数据库部署在同一台服务器上时。在高并发的情况下，单单对服务器进行硬件的升级在技术与经济上已经不能满足我们的需求。但是系统在多个服务器上运行时，便会产生域名不统一的问题。因此，我们需要系统又一定的水平扩展能力。而Nginx的反向代理可以代理后端的服务器集群，以一个统一域名的方式暴露出去，供用户的调用。核心配置如图4-4所示。图4-4Nginx核心配置图使用负载均衡有如下的好处：1）使用服务器集群分担了主服务器的高并发压力；2）大大增加了整个系统的安全性和稳定性3）可以根据需求添加服务器数量，增强了水平扩展能力[1]。Nginx是一个高性能的反向代理和HTTP服务器。它的主要优点有：性能十分高效，较强的稳定性和较低的系统资源消耗。4.4查询优化设计在进行了如上的优化之后，秒杀系统应对并发流量的能力又了一定的提升。但是，即使我们将数据库单独部署在一台服务器上，但对于数据库存储的时间瓶颈并没有得到一个有效的解决。本节中将完成对页面查询优化的解决方案。4.4.1缓存缓存技术是解决高并发问题的一个重要手段。在秒杀项目中，将用户需要访问的数据存放到内存当中，当用户要访问这些数据时，便不再访问数据库而是访问内存，内存的运行速度时磁盘运行速度的几千倍甚至上万倍。因此极大的提升了访问速度，减小了因为数据库的读写造成的对服务器的压力，缓解了高并发所带来的拥堵。而缓存我们一般认为应该推到离用户最近的地方，这样便减少了在访问链路上的消耗。根据系统结构图，将商品浏览，商品详情页，下单等常用的页面放入Redis缓存中。在高并发的环境下，该方法可以有效降低访问Web服务器集群的压力，提高访问静态页面的效率。有时候，频繁的访问数据库会使数据库崩溃，所以应该在数据库和服务器之间配置相应的Redis缓存。用户第一次缓存时，该数据就会存放到Redis中，待到用户第二次访问，便会首先在Redis中进行查找。如果有便可以直接在缓存中进行访问，这样做便可以减少数据库访问对服务器进行的压力。由于Redis在内存数据库中属于稀缺资源，也应该设置过期时间，而对于一些热端数据。存储在本地内存空间是一个非常优秀的方案。4.4.2本地热点缓存由于Redis的特性，导致了对Redis的存取都需要经过网络的IO，到达server上，并通过Redis的协议更新状态。因此，相对于操作本地缓存来说，Redis显的并不是那么适用。本地热点缓存特点：1）只有热点数据才可以进入本地热点缓存。2）脏读非常不敏感。3）内存可控。本地热点缓存方案：使用Guavacache组件。优点：1）本质上是一个可并发的HashMap，他可以控制Key和Value的大小和对应的Key的超时时间。2）可以配置lru策略：最近最少访问的Key有限被淘汰。3）线程安全。4.5数据库设计4.5.1数据库概念模型设计学习编程，我们都知道数据库应该基于系统的功能进行设计，我们需要建立一个数据库的关系模型，用来存储数据信息。数据库可以说是系统的核心和基础，数据库还提供了添加、删除、修改和检查，使系统能够快速找到自己想要的信息，而不是在程序代码中找到。数据库中信息表的每个部分根据一定的关系精确地组合，排列和组合成数据表。在数据库的设计中，通常使用E-R图来了解表与表之间的关系。本系统的数据库概念模型E-R图如4-5所示。图4.5E-R图4.5.2数据库逻辑设计通过双十一限时秒杀系统的功能进行规划分成几个实体信息，主要有商品表item，库存表item_stock,订单表order_info,秒杀信息表promo，用户表user_info,用户密码表user_password。部分表如下所示。表4.6item信息表字段名数据类型备注idbigint(20)主键titlevarchar商品名称pricedouble(10)价格descriptionvarchar(500)简介salesInt(11)单价img_urlvarchar(255)图片表4.7order信息表字段名数据类型备注idvarchar(32)单号user_idInt(11)用户iditem_idint(11)商品iditem_pricedouble(20)商品价格amountint(20)数量order_pricedouble订单价格promo_idint(11)秒杀id表4.8promo信息表字段名数据类型备注idbigint(20)主键promo_nameVarchar(255)活动名称start_datedatetime开始时间item_idint(11)商品idpromo_item_pricedouble活动价格end_datedatetime活动结束时间表4.9user_info信息表字段名数据类型备注idbigint(20)主键nameVarchar(64)昵称gendertinyint性别ageint年龄telphonevarchar电话5系统实现5.1用户模块实现该系统实行会员制，需要用户在登录的情况下才可以对商品进行下单操作，如果没有账号，则需要在注册界面注册一个平台账号。注册之前需要输入手机号并发送一条随机的OTP短信，如图5-1所示。图5-1获取验证码页面在注册的时候输入对应短信，确定是本人操作后才可以进行注册，提高了系统的安全性。在注册时，需要输入对应的手机号，验证码，用户昵称，性别，年龄和密码，如图5-2所示。图5-2注册页面注册成功后便可以通过手机号和密码进行登录，如图5-3所示。图5-3登录页面HTTP请求有对应的一套session会话管理的机制，以用来标识用户会话的过程。目前秒杀系统使用的是SpringBoot内嵌Tomcat的默认会话管理机制，他是基于coolkie传输sessionid来实现的。但是当在分布式架构中，因为使用了Nginx的轮询机制，便有可能出现一种sessionid不一致的情况，如当获取OTP短信的时候，后台系统将手机号与随机生成的验证码进行绑定，但到了注册页面时，页面通过轮询访问的便是另一台服务器了。这便会造成用户注册失败的情况，在系统实现中是一个不可接受的BUG。在本文中，对于该问题的解决方案是将Tomcat容器session实现迁移到Redis当中。这样会在访问页面时提前访问Redis，并且通过设置过期时间确保了验证码的时效性。通过使用这样的方法完美的解决了sessionid前后不一致的问题。5.2商品模块实现管理员可以在创建商品页面对商品进行管理，添加商品的名称，描述，价格，图片，库存等。并根据实际情况策划活动，选择性填写秒杀时间与秒杀价格。如果没有填写秒杀时间与秒杀价格，系统依旧会在promo表中创建信息，避免查询时出现空指针的情况。在创建后便可以通过商品详情页对查看其基本信息，如图5-4，图5-5所示。图5-4商品管理页面图5-5商品列表浏览页面作为产生高并发问题严重的页面，用户对商品列表浏览页的访问不能直接进行，这样会对数据库造成很多大的并发压力。所以用户在访问该页面时，会先对缓存进行读取，查看Redis中是否存储了该页面的信息，也就是说，只有用户在一定时间内第一次访问列表浏览页面，才会对数据库造成直接的访问。同时，当页面请求通过Nginx对外暴露的一个统一域名对server层进行轮询访问时，其权重比为1比1。这样相当于server层的服务器集群平均的处理了这些请求，目的是减少后端系统处理请求的压力，并且因为Nginx的特性，错误的请求会被即使关闭请重新开启，减少了开发人员对锁的工作。如此操作之后，不仅减少了server层对数据库进行读的操作，同时降低了页面对server层的访问。5.3订单模块实现在浏览页面点击某商品后，可以查看该商品的基本信息，并对其进行下单操作。在页面上可以看到该商品的活动信息。如果该商品为秒杀活动商品，那么秒杀活动价格会覆盖普通价格，并且会现显示秒杀活动的截止时间。如果秒杀活动还未开始，用户不能对商品进行下单，但可以看到秒杀活动的倒计时。但是，如果用户没有登陆是不可以下单的。具体如图5-6所示。图5-6商品详情页面对于热点商品，在对数据库进行直接访问之前，还需要使用cacheService.getFromCommonCache方法对其进行本地缓存存取，进一步降低了前端请求，并减少了请求在网络链路上的消耗。如果本地缓存中没有，需要使用redisTemplate.opsForValue().get()在Redis缓存中查找,如果Redis缓存中没有才会对数据库进行直接操作。如图5-7所示。部分对商品详情页进行查询的代码如下：//先取本地缓存

itemModel=(ItemModel)cacheService.getFromCommonCache("item_"+id);

if(itemModel==null){

//根据商品的id到redis内获取

itemModel=(ItemModel)redisTemplate.opsForValue().get("item_"+id);

//若redis内不存在对应的itemModel,则访问下游service

if(itemModel==null){

itemModel=itemService.getItemById(id);

//设置itemModel到redis内

redisTemplate.opsForValue().set("item_"+id,itemModel);

redisTemplate.expire("item_"+id,10,TimeUnit.MINUTES);

}

//填充本地缓存

cacheService.setCommonCache("item_"+id,itemModel);

}图5-7请求访问流程图6系统测试6.1系统测试的目的在程序的运行过中，系统出现BUG是不可避免的，而程序的设计或许也会有一些逻辑上的问题。但是我们不能将有问题的程序交到用户手中，如果系统没有经过测试便上线，一旦出现一些不可预知的问题，后果就会十分严重。用户也不会在一个满是BUG的网站上多做停留。为了避免这种情况，我们应该在程序上线之前，将程序功能一一测试，如果发现问题便要及时修改，使系统长期稳定运行。另一个目的便是对秒杀系统优化前和优化后进行压力测试，对比优化前和优化后系统面对高并发情况时的能力。本章便是要发现这些问题，并对其进行修改，从长远来看是非常重要和必要系统的开发的过程。6.2功能测试测试环境是Windows10System，对所有模块的功能一一进行测试，检查数据查看是否交互成功，查看用户是否可以对系统进行越权操作，这些都是需要测试。功能测试的主要作用是查看系统是否会出现以下几种问题：（1）系统功能是否完善：或许会出现少写漏写功能的情况，并从用户的角度出发，想象用户会进行什么操作，测试实用功能是否方便与人性化。（2）检查系统流程设计的合理性与正确性，并确定系统所能实现的功能是否是用户所需要的，且满足系统性能的需求。当使用该系统的数据数较多时，需要合理的分配对多个功能的组合运用和与数据库之间的交互。（3）当用户在页面上输入相对应的数据时是否可以正确响应用户的输入，对用户的输入是否进行了检测并能返回正确的显示结果。在多用户同时使用时，会不会出现数据之间的冲突。业务逻辑部分测试如测试用例表6-1所示。表6-1优化前测试指标表测试需求测试重点预期结果结果用户注册输入错误验证码，输入被注册手机号。提示验证码错误与手机号被注册通过商品管理不输入正确商品信息格式提示创建失败通过订单管理在未到达秒杀活动时间时下单，为登录时进行下单。下单按钮锁定与跳转登陆页面通过表6-1优化前测试指标表（续）6.3性能压力测试6.3.1测试工具ApacheJMeter是Apache组织开发的基于Java的压力测试工具，最初设计用于测试Web应用程序，现已扩展到其他测试领域，可用于测试Web应用程序，静态和动态资源（例如静态文件，CGI脚本，FTP服务器等），JMeter可用于模拟服务器，网络或对象上的巨大负载，测试其在不同压力类别下的抵抗力并分析其总体性能。6.3.2测试注意事项压测时除了需要一些基本事项之外，该应该以具体系统为参考，对注意事项做出一系列的个性化修改。在本次项目设计中，压测时也有些需要注意的地方。因为该系统用到了Redis与本地缓存，因此在测试时不能进行连续的测试，否则便会产生出错误的测试结果。比如在第一次测试1000并发时，当前缓存中并没有进行存储被测试的页面。而当连续的进行第二次测试时，因为页面信息已经在缓存中，测试时结果便会存在误差。因此在进行测试时，首先要在Redis中清除相关的数据，并且需要间隔60秒后才可以对系统继续进行压测。等待60秒的目的是为了等待本地缓存的自动消散，只有做到这样才可以在测试中得到正确的压测结果。6.3.3测试过程在项目上线之前，有一个必不可少的步骤便是性能压测，依靠性能压测，我们可以发现许多系统的性能瓶颈。而了解系统的性能瓶颈可以有效的帮助企业对系统进行能力预测，结合市场调研的数据可以将技术以及硬件成本控制在一个可接受的经济范围。JMeter压测必备：1）线程组：在客户端内部启动多个并发的线程，并发的发送接口的请求，以测试系统的压力。2）Http请求：接口的请求地址。3）查看结果树：查看返回结果是否正常和异常时的原因。4）聚合报告：包含性能评测的指标来表现对应接口的响应情况。对优化前的系统进行测试，从10秒内1次请求，这时候的平均响应时间为65/ms，吞吐量为15.4，到对其进行1000次并发数的测试，此时系统感受到了明显的压力，响应时间增加，吞吐量已经达到了167.6。等到10000并发时，未优化的系统已经不能对所有的请求进行正确的响应，开始出现了错误返回，吞吐量的表现也不良好。对优化后的系统进行测试，10秒内5000次并发的平均响应时间为73/ms，吞吐量来到了997.6。当给系统进一步的压力，来到了20000并发时，系统依旧表现良好，平均相应时间只有38/ms，无论是并发数，响应时间还是吞吐量，优化后的系统在面对高并发问题时的表现都远远超过了优化前系统。因此，本文优化设计实现有效的解决了高并发的问题。指标如表6-2，表6-3所示。表6-2优化前测试指标表并发数平均响应时间/ms吞吐量/(ks/sec)90%响应时间/ms16515.4651000266167.6745100005001261365表6-3优化后测试指标表并发数平均响应时间/ms吞吐量/(ks/sec)90%响应时间/ms500073997.64520000383421.163300001452832.6261对比如图6-4，图6-5分析后对比后可以看出，无论是吞吐量（TPS）还是一些其他的测试指标如平均耗时，90%耗时等，在实施了了Nginx,Redis,Guavacache等操作之后的系统都优于未实施的系统。在20000高并发的情况下，系统依然表现良好，并且有一个很好的TPS和平均相应时间。这时候用户体会不到任何因为高并发所引发的一系列问题。从之后的30000并发时的数据可以看出，在上一层次的并发数时系统的表现是最好的，达到了性能上的峰值。而因为使用了分布式扩展，系统可以根据需求水平扩展各个模块的服务器，因此，该系统的性能峰值可以随着实际服务器的部署而调整。有效的解决了在活动外因为多余部署而引发的经济浪费。综上所述，本文中的高并发解决方案实行成功。图6-4TPS对比图图6-590%响应时间对比图7总结到达本章，此时项目的基本功能都已经完成，从敲定题目到项目完工，这个过程中除了巩固了我这几年所学习的专业知识，也帮助我进一步开拓了视野。在其中也逐渐的认识到自己的不足，但这些不足也在这几个月中得到了历练，甚至有些还成为了我的优势。毫无疑问，本次毕业设计对我在毕业找工作这方面的帮助是十分巨大的，从系统的分析到系统的设计实现，再到提出优化方案并实行。这其中遇到的种种困难都将成为我今后的资本。其中遇到的各种不成熟的问题，也都通过寻找专业网站和论坛来解决。老师和同学也都帮助了我很多，而总会在不经意的地方出现问题并等着你来解决。而本次毕业设计的结束并不是该系统的终点，而是优化的起点。我会继续在实践中寻找系统可以优化的功能模块并找到解决方案，让秒杀系统更符合市场大众的需求。本次毕业设计巩固了我的JAVA知识，让我更加熟练的掌握和运用SpringBoot框架和SQL语句，更是新掌握了如Redis等流行的中间件，可谓是收获满满。在今后的学习以及工作中，我相信自己仍然回从事计算机方面的工作，而在该行业中是需要终身学习的，掌握新的技术才可以在该行业中立足，我相信，之后我会在学习-工作这种互补的模式中不断向前，为社会做出更大的贡献。参考文献黄芝龙,徐莉莎,瞿少成.高并发Web电商系统的设计与优化[J].计算机与数字工程,2019,47(07):1719-1724+1775.戴伟,马明栋,王得玉.基于Nginx的负载均衡技术研究