有很多人在面试的时候，简历都准备的是电商的项目，其实这个项目有的时候，还比较头疼。
因为我们都知道电商业务上其实大体一致，技术点上相对于其他的项目都会问的比较深入。
比如上面这个问题电商项目亮点：
电商项目最大的亮点无非是在性能上解决了多少用户同时在线抢购。
首先，我们了解下企业电商这块对系统架构的设计：
在电商领域，存在着典型的秒杀业务场景，那何谓秒杀场景呢。简单的来说就是一件商品的购买人数远远大于这件商品的库存，而且这件商品在很短的时间内就会被抢购一空。
比如每年的 618、双 11 大促，小米新品促销等业务场景，就是典型的秒杀业务场景。
我们可以将电商系统的架构简化成下图所示：
由图所示，我们可以简单的将电商系统的核心层分为：负载均衡层、应用层和持久层。
接下来，我们就预估下每一层的并发量：
假如负载均衡层使用的是高性能的 Nginx，则我们可以预估 Nginx 最大的并发度为：10W+，这里是以万为单位。
假设应用层我们使用的是 Tomcat，而 Tomcat 的最大并发度可以预估为 800 左右，这里是以百为单位。
假设持久层的缓存使用的是 Redis，数据库使用的是 MySQL，MySQL 的最大并发度可以预估为 1000 左右，以千为单位。Redis 的最大并发度可以预估为 5W 左右，以万为单位。
所以，负载均衡层、应用层和持久层各自的并发度是不同的，那么，为了提升系统的总体并发度和缓存，我们通常可以采取哪些方案呢?
①系统扩容
系统扩容包括垂直扩容和水平扩容，增加设备和机器配置，绝大多数的场景有效。
②缓存
本地缓存或者集中式缓存，减少网络 IO，基于内存读取数据。大部分场景有效。
③读写分离
采用读写分离，分而治之，增加机器的并行处理能力。
秒杀系统的特点
对于秒杀系统来说，我们可以从业务和技术两个角度来阐述其自身存在的一些特点。
秒杀系统的业务特点
这里，我们可以使用 12306 网站来举例，每年春运时，12306 网站的访问量是非常大的，但是网站平时的访问量却是比较平缓的，也就是说，每年春运时节，12306 网站的访问量会出现瞬时突增的现象。
再比如，小米秒杀系统，在上午 10 点开售商品，10 点前的访问量比较平缓，10 点时同样会出现并发量瞬时突增的现象。
所以，秒杀系统的流量和并发量我们可以使用下图来表示：
由图可以看出，秒杀系统的并发量存在瞬时凸峰的特点，也叫做流量突刺现象。
我们可以将秒杀系统的特点总结如下：
①限时、限量、限价
在规定的时间内进行;秒杀活动中商品的数量有限;商品的价格会远远低于原来的价格，也就是说，在秒杀活动中，商品会以远远低于原来的价格出售。
例如，秒杀活动的时间仅限于某天上午 10 点到 10 点半，商品数量只有 10 万件，售完为止，而且商品的价格非常低，例如：1 元购等业务场景。
限时、限量和限价可以单独存在，也可以组合存在。
②活动预热
需要提前配置活动;活动还未开始时，用户可以查看活动的相关信息;秒杀活动开始前，对活动进行大力宣传。
③持续时间短
购买的人数数量庞大;商品会迅速售完。在系统流量呈现上，就会出现一个突刺现象，此时的并发访问量是非常高的，大部分秒杀场景下，商品会在极短的时间内售完。
秒杀系统的技术特点
我们可以将秒杀系统的技术特点总结如下：①瞬时并发量非常高
大量用户会在同一时间抢购商品;瞬间并发峰值非常高。
②读多写少
系统中商品页的访问量巨大;商品的可购买数量非常少;库存的查询访问数量远远大于商品的购买数量。
在商品页中往往会加入一些限流措施，例如早期的秒杀系统商品页会加入验证码来平滑前端对系统的访问流量，近期的秒杀系统商品详情页会在用户打开页面时，提示用户登录系统。这都是对系统的访问进行限流的一些措施。
③流程简单
秒杀系统的业务流程一般比较简单;总体上来说，秒杀系统的业务流程可以概括为：下单减库存。
针对这种短时间内大流量的系统来说，就不太适合使用系统扩容了，因为即使系统扩容了，也就是在很短的时间内会使用到扩容后的系统，大部分时间内，系统无需扩容即可正常访问。
如果你要在性能方面找寻亮点，有个必备条件就是你必须对性能很熟悉，要不面试官会在性能的测试把你问的死死的，当然如果回答的很好，也是可以多要些工资。
比如之前的电商项目，我负责了性能方面的测试，最终成功保障多少用户同时参加抢购，没有bug和性能问题。
拿50W-100W高并发，秒杀功能来说：
QPS（Query Per Second），即一秒内可以处理的请求数量。假如一个服务的RT是20ms，则QPS为50，这里计算的是单机单线程QPS，如果计算集群的话，需要考虑集群数量和线程数量。
这时候需要确认秒杀商品的请求QPS是多少。如果面试官说峰值大概量级在100万，那么按照服务单线程QPS是50，单台最大线程数按3来计算的话，单台机器最大支撑150的QPS，那么至少需要100W/150=6667台机器。
常见的组件最大QPS，mysql单机1000QPS，Redis单机10万QPS。
但是，对于大多数的小白来说，我不建议在这里过多强调性能，毕竟水太深，容易被淹！！！
亮点可以说，经过我们每次迭代测试的版本，上线之后，用户使用过程中很少有用户反馈问题，保障用户使用正常。
每次都会较高版本的迭代测试。
至于难忘的bug：这个主要还是你的电商网站具体的业务。
比如：第三方支付如果有涉及，可以说当时电商这块我最印象深刻的是在调起支付接口的时候，实际上是没有成功的，但是提升成功了 ，后来发现是开发把mock的代码，未及时替换回来，也让我有个提示，无论测试什么最好从业务到数据都应该进行关注。
