作者：纽威。
最近，许多客户和企业都非常关注商城系统中Legendshop的并发数据。事实上，他们已经通过了中国烟草集团，
经过SAIC商城、CNNC、招商银行等客户项目这么多年的实际落地，我们有了比较成熟的落地方案。我们整理了一些设计思路，并与大家分享：
1、概述
Legendshop
B2B2C电商平台具有用户数量大、业务量大、并发度高的特点。正常情况下，大量的数据会降低B2B2C电商平台的性能，降低系统的响应速度。对于电商网站来说，用户对响应速度有很高的要求。在这种情况下，我们应该根据具体的性能要求来设计Legendshop。
B2B2C电商平台。
在这里，我们如何构建一个可以支持500万日活跃用户的B2B2C平台？
2、名词解析
DAU(每日活跃用户)每日活跃用户数。
PV(Page View)访问量，即页面浏览量或点击量，衡量网站用户访问的网页数量；
UV(Unique Visitor)是一个独立的访问者，统计一天内访问一个网站的用户数量(基于cookie)；访问网站的计算机客户端是访问者。
IP(Internet Protocol)独立IPS数是指一天内有多少个独立IPS浏览了页面，即统计了浏览不同IPS的用户数。
3、常用业务场景分析
在Legendshop B2B2C电商平台中，最常见的业务场景如下。他们的并行需求是什么？
3.1、电商平台首页
计算模型：
每秒处理的请求数=((80%*总PV量)/(24小时*60分钟*60秒*40%))。
关键参数是80%和40%。这意味着一天中80%的请求发生在一天的40%之内。40%的24小时时段是9.6小时，80%的请求发生在一天9.6小时内(非常适合电商平台的应用，高峰时段请求多，空闲时段请求少。并非一天中所有的访问都是平均的，在晚上达到高峰。
18: 00 -22: 00是一般电商平台的高峰期)。
计算结果：
500万DAU，估计它将产生10倍的主页PV访问率。
((80% * 500万*10次)/(24小时*60分钟*60秒*40%))=1157次请求/秒。
以上请求在白天9.6小时内平均分布，但实际情况并没有那么平均分布，会有高峰和低谷。为了应对高峰时段和傍晚高峰。
18: 00 -22: 00是一般电商平台的高峰期，所以要留一些余地，至少x2倍，x3倍也不为过。
157请求/秒* 3x=3471请求/秒。
3.2、商品页面
计算模型：
每秒处理的请求数=((80%*总PV量)/(24小时*60分钟*60秒*40%))。
计算结果：
500万DAU，估计光伏对商品页面的访问将以10倍的速度产生。
((80% * 500万*10次)/(24小时*60分钟*60秒*40%))=1157次请求/秒。
157请求/秒* 3x=3471请求/秒。
3.3、订单下单
计算模型：
习惯上是从日活跃用户的3%-5%来计算订单数，每个订单会产生10个请求。
每秒处理的请求数=((80%*每日活跃用户*5%)/(24小时*60分钟*60秒*40%))。
计算结果：
((80% * 500万* 5% * 10%)/(24小时*60分钟*60秒*40%))=60个请求/秒。
60请求/秒* 3x=180请求/秒。
3.4、秒杀
计算模型：
习惯了每天有1%的活跃用户同时参与spike，
计算结果：
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
