高并发电商平台设计

原创
2019/09/21 20:02
阅读数 247

最近很多客户商家, 非常关心我们Legendshop商城系统并发量数据, 其实经过 包括中烟集团, 上汽集团商城,中核集团,招商银行等客户项目这么多年的实战落地,我们有一套相对成熟的落地方案;我们整理了一些设计思路,给大家做一个分享:

1、概述

Legendshop B2B2C电商平台具有大用户量、大业务量和高并发的特点。常规条件下,大数据量将使B2B2C电商平台性能下降,系统响应速度变慢。而对电子商务网站,用户对响应速度要求高。在这种情况下,我们要根据具体的性能要求来设计我们的Legendshop B2B2C电商平台。

这里,我们建设一个能承受500万日活跃用户的B2B2C的平台,需要如何建设

2、名词解析

DAU(Daily Active User)日活跃用户数量。

PV(Page View)访问量, 即页面浏览量或点击量,衡量网站用户访问的网页数量;

UV(Unique Visitor)独立访客,统计1天内访问某站点的用户数(以cookie为依据);访问网站的一台电脑客户端为一个访客。

IP(Internet Protocol)独立IP数,是指1天内多少个独立的IP浏览了页面,即统计不同的IP浏览用户数量。

 

3、常用业务场景分析

在Legendshop B2B2C电商平台,最常见的业务场景有以下几个,他们的并发要求是怎么样呢?

 

3.1、电商平台首页

计算模型: 

每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) 。

其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时,有80%的请求发生一天的9.6个小时当中(很适合电商平台的应用,高峰时间请求多,闲时请求少,不是一天的访问都是平均,晚高峰 18点-22点是一般电商平台最高峰时期)。 

计算结果:

500万DAU  ,估算会产生10倍比率的首页PV访问

((80%*500万*10倍)/(24小时*60分*60秒*40%)) = 1157个请求/秒 

以上请求数量是均匀的分布在白天的9.6个小时中,但实际情况并不会这么均匀的分布,会有高峰有低谷。为了应对高峰时段,晚高峰 18点-22点是一般电商平台最高峰时期,应该留一些余地,最少也要x2倍,x3倍也不为过。

1157个请求/秒 *3倍=3471个请求/秒。

3.2、商品页面

计算模型: 

每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) 。

计算结果:

500万DAU  ,估算会产生10倍比率的商品页面PV访问

((80%*500万*10倍)/(24小时*60分*60秒*40%)) = 1157个请求/秒 

1157个请求/秒 *3倍=3471个请求/秒

3.3、订单下单

 

计算模型: 

习惯以3%-5%的日活跃用户下单比例来推算用户的订单数,每个订单会产生10个请求

每秒处理请求的数量=((80%*日活跃用户数量*5%)/(24小时*60分*60秒*40%)) 。

计算结果:

((80%*500万*5%*10)/(24小时*60分*60秒*40%)) = 60个请求/秒

60个请求/秒*3倍=180请求/秒

3.4、秒杀

计算模型: 

习惯以1%的日活跃用户同一时间参与秒杀,

计算结果:

500万*1% = 50,000个请求/秒

 

4、高并发常用技术

在B2C网站架构设计中,将通过如下方法保持大数据量情况下网站系统的高性能:

4.1动静分离与数据缓存

数据库访问的性能往往是网站性能的瓶颈。

根据经验数据,用户在访问互联网站时,超过90%的操作只是读取数据,提交、修改数据不到10%。因此可以将内容相对固定、主要供用户浏览的页面(如产品展示页面)生成缓存,而无须访问数据库。这样,可以大幅度提高网站性能。

 

对于静态内容(网页、图片、音频文件、脚本文件等)可以选择CDN(Content Delivery Network,内容分发网络)方式发布,从而通过专业内容发布服务提高网站访问速度。

频繁修改的数据可以采用缓存的办法处理。Redis功能强大、简单易用,支持分布式数据处理,是商城平台常用的缓存方案。

4.2数据库集群和应用集群

可以配置数据库集群,实现读写分离。选用MySQL数据库,主数据库负责处理数据写入操作,对于单纯读操作,分发给从数据库处理。数据发生更改时,主数据库自动同步数据到从数据库。从而提高数据库整体性能。可以根据需要配置多台从数据库服务器。也可以根据业务发展随时增加。

4.3负载均衡

对于应用服务器、数据库集群均配置负载均衡,充分利用系统资源。

4.4 数据库

数据库系统性能是网站性能的瓶颈。

通过配置数据库集群,实现读写分离之外,还可以通过多种技术手段提高数据库访问性能。如下:

数据库分表:同一个数据表中,不同字段读写频率存在差异,或者存在大字段时,采用纵向分表,从而降低数据库I/O次数,提高性能;一个数据库表中数据条目增多,查询性能低下时,采取横向分表策略,减少单个表中数据条目数。

 

充分利用索引:分析用户查询行为,合理建立索引。

4.5程序

采用技术手段对程序和页面进行优化,充分利用缓存。

4.6秒杀的程序常用技术

1,随机丢弃,减少进入核心逻辑的请求。

2,多层筛选,平均核心逻辑的IO。

3,缓存,消息队列,保证业务和数据正确,开启多个服务节点处理消息队列,当没有库存后,抛弃队列里的剩余请求。

 

  1. 微服务下高并发指标

针对B2B2C多用户商城的设计思路, 以下指标经过实践得出, 详见下一篇文章(springcloud微服务高并发设计)

到微服务,在和大家讨论时发现最大的问题是,是否要落地实践微服务?因为很多企业并没有达到所需的规模,所以,在准备实践微服务之前需要考量的几个问题是:

·数据量和业务复杂度有没有达到,若是一个库或一个集群即可搞定,那么建议不要去考虑微服务的问题,大型企业有很多数据库集群去支撑业务,此时,才应该去考虑实践微服务。

·团队规模,若团队只有十几个人,很多传统WEB三层结构就可以满足需求也无需去考虑微服务,除非团队规模达到上百人,拆分成十几二十几个团队,沟通比较困难时去考虑微服务是比较好的。

·应对大规模流量并发,很多企业将原来系统的业务开了互联网接口就送出去,此时会遇到很多高流量高并发的问题,此时需要考虑是否要转向微服务,因为传统架构很难应对突发性流量问题。

·是否需求足够的容错容灾,不要认为所有的系统都需求100%可靠,对于很多企业而言,一些系统停机一天或几个小时并不重要,其实并非任何系统都要做高可用,是否需要自动恢复,运维强度等都是需要考虑的问题。

·功能重复度和维护差错成本,系统规模越大,功能的重复也越高,现在企业里有很多系统,都要进行认证授权,其实可以单独考虑,否则每个系统都要进行一次,而且并不相同。

若以上问题都不存在,建议还是以三层结构的模式,不要给自己挖坑跳不出来,并非所有企业度适合微服务。

 

5.1、平台首页: 1157个请求/秒 *3倍=3471个请求/秒。(系统要求)

                微服务性能理论可以达到指标:6000请求/秒

5.2、商品页面 1157个请求/秒 *3倍=3471个请求/秒。(系统要求)

                微服务性能理论可以达到指标:6000请求/秒

5.3、订单下单 60个请求/秒*3倍=180请求/秒。(系统要求)

               微服务性能理论可以达到指标:300请求/秒

5.4、秒杀 500万*1% = 50,000个请求/秒。(系统要求)

               微服务性能理论可以达到指标:100,000请求/秒

 

以上是一些实践思路, 欢迎更多同行相互交流

www.legendshop.cn

 

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部