菜单

循序渐进

    Java Oracle MySQL Bash Python Nginx Apache Redis MongoDB Git HTML Javascript Node CSS

最近来访

    架构设计.高流量高并发电商活动设计方案

    张嘉杰.原创 2017-11-01 architect

    最近热搜:英雄联盟S7大事件:大麦网"一战成名"。公司领导呼吁:大家不能光看热闹,也要看清问题的背后的原因。研发部例会上也提到了,如果英雄联盟由我们来开售,我们用什么方案解决并扛住压力的一些问题。

    architect

    API接口规范


    起因

    最近热搜:英雄联盟S7大事件:大麦网"一战成名"。公司领导呼吁:大家不能光看热闹,也要看清问题的背后的原因。研发部例会上也提到了,如果英雄联盟由我们来开售,我们用什么方案解决宕机问题,并扛住压力的一些问题:

    关于LOL事件

    2017年09月28号LOL S7半决赛门票开售,LOL玩家满心期待去购票却迎来失望,而此时,有网友爆料黄牛在淘宝等交易平台上却早已高价出售门票,更有门票被炒到了5000+的价格。这在网络上引起了不少玩家的不满,大麦网也第一次因为《英雄联盟》门票售卖被骂上了热搜。

    也许是不堪舆论的压力,大麦网在今晚7点过在微博上专为LOL玩家致歉,表示是当时抢票人数高达80万,导致网络波动引起服务异常。

    LOL玩家们对此并不买账,坚持认为是主办方或大麦网将票卖给了黄牛,微博评论一片骂声:

    最后LOL玩家对315网监局进行了举报!

    PS:其实票务这个圈子,和大家知道的其他圈子也没差别,圈外看过去, 80%的从众者,19%的高知沉默者,1%的行内知情者。网上出来说话的,懂行且是真话的1%都不到。

    关于黄牛

    这里简单说一下我理解的黄牛产业链

    在没有黄牛的参与下,产业链是这样的:

    在有了黄牛的参与下,产业链是这样的:

    那么黄牛的票源从哪里来呢?主要有3个方面:

    * 抢(刷票)
        - 使用抢票软件,从普通消费者手里抢,这个大家都比较熟悉
    * 收购赠票
        - 赠票主要是一般项目都会有大量的赠票从各个渠道发出去,有的人不想去,所有会低价卖出
    * 与主办方勾结
        - 与主办方勾结是情节最恶劣的一种,是绝对的违法行为
    

    整个产业链条,最关键的就是要有人肯出大价钱去买票。消费者可以说是整个博弈中最弱势也最强势的角色。看似价格权掌握在别人手里,然而其实只要消费者统一战线,坚决不购买黄牛票,黄牛组织在最后关头也只能降低价格,但是要做到这一点确实很难很难,粉丝的热情,有时候就是愿意购买高价票。

    电商活动(秒杀、促销)难点

    活动业务原则

    1. 尽量将请求流量拦截在系统上游
    2. 读多写少的业务一定要使用缓存

    活动业务描述

    简单说一下技术上的业务描述,一般活动分为`活动开始前`、`活动进行中`、`活动结束后`三个阶段。
    1. 活动开始前
        大量用户频发刷新活动页面,都想第一个看到活动开始,越临近开始时间,刷新越频繁(系统有巨大的读压力)
    2. 活动进行中
        用户的请求短时间内持续涌入,前端访问量暴增,并且会牵扯到写库的需求,还有在对于单一热点商品库存判断(写库是排他操作,排队处理,数据库写压力很大)
    3. 活动结束后
        短时间内单页面很多用户访问,活动时间一过,页面就没有访问量了

    活动难点及方案

    场景:xx演唱会,票价1000(100张)、票价800(300张)、票价500(600张),总库存 1000 张,活动时间为1小时,假设实际用户数量为 50000,并发请求2000/s** 下面每个方案会给出对应的解决方案,和衍生出来的问题。

    1. 预估流量算出大概所需要的服务器
    	
    解决方案:
    1.网络带宽:假设活动页面大小 100k,那么 2000*100/1024 ≈ 200M 的带宽可保证设计中的速度
    2.单服务器WEB容器数量:假设Tomcat 单个 8G内存,单台服务器有 96G 内存,那么可部署 96/8 ≈ 10个 Tomcat应用服务(剩余内存给其他服务使用,如:Nginx等等)
    3.QPS指标:Nginx 10wQPS(不是瓶颈),Tomcat 500~800QPS,那么单台服务器最大可接受的 QPS 为 800 * 10 = 8000 QPS(这里是请求简单jsp页面,实际业务大概能到优化到 800 * 10 / 3 = 2500 QPS 理想状况)
    4.平均响应时间:系统在高并发的状态下,响应时间有可能从 300ms 变成 500ms,会影响实际应用的 QPS (800 * 10 / 5 = 1600 QPS 理想状况)
                  
    衍生问题1:某 Tomcat 运行过程中突然宕机或响应变慢,Nginx 快速切换问题?
    讨论(Q&A)
    1.Nginx 的负载均衡机制(check interval=3000 rise=2 fall=5 timeout=1000 type=http;)每隔 3 秒检测一次,请求 2 次正常则标记 realserver 状态为 up,如果检测 5 次都失败,则标记 realserver 的状态为down,超时时间为 1 秒。
    1. 对于活动前后单页面的大量访问处理
    解决方案:提前预热把活动页面推入 cdn,大量的请求就可以抗住了。
            
    衍生问题1:cdn 上的活动页如何确认活动开始时间?
    讨论(Q&A)
        1.生成活动已开始静态页更新cdn缓存?
        2.活动页ajax请求接口服务确认开始时间?
        3.活动开始后生成带跳转的js文件,活动页加载跳转?
        
    衍生问题2:如何保证用户看到活动页倒计时一致?
    讨论(Q&A)
        1.部署集群 ntp 服务同步?保证服务器时间一致。
        2.倒计时误差,解决网络传输耗时造成的误差问题?
        3.统一获取分布式中间件时间?如:redis等等
    1. 简化活动交易流程(公平公正,安抚用户心理)
    解决方案:参照上述场景,假如活动商品为选座商品,按票价分为三个区域,可以引导用户进入不同的票价区域房间(逐级分流的思路,票价房间可单独部署服务),每个房间对进入的人数有一定的限制,控制最终参加活动的人数
    
    衍生问题1:如何让用户感知自己可能买不到活动商品?
    讨论(Q&A)       
        1.显示房间总人数?库存?已售座位数?
        2.类似 12306 提示用户前面有多少人排队,预估大约等待时间?
            
    衍生问题2:房间里面的用户可否采用摇号的方式?
    讨论(Q&A)    
        1.提前告示摇号公式,活动完毕,公布摇中的用户?
        2.从房间里随机选出对应库存的用户,与用户id绑定,并生成独立的请求链接
    1. 活动中压力最大的库存处理
    解决方案:为了防止出现超卖问题,所以采用一个萝卜一个坑的方式,预先生成 1000 个资格 token,获得购买资格的用户,拿 token 作为凭证,完成创建订单,订单支付等后续流程
        
    衍生问题1:token 是否可以采用提前发放的形式?
    讨论(Q&A)
        1.运营部门提前发放?
        2.预先充值的用户提前发放?
        
    衍生问题2:token 是否需要设置超时时间?
    讨论(Q&A)
        1.防止用户占用 token ,而不完成后续流程,释放 token?

    服务降级

    * 故障降级
        - 数据托底:非实时性查询接口,数据静态化。web 容器崩溃仍可访问内容
    * 限流降级
        - Nginx 接口限速(某个接口服务 QPS 超多阈值,直接报自定义异常)
    * 应用降级
        - 内部接口服务,时间窗口内失败次数到达一定的阈值,则自动降级

    链路监控

    * 涉及活动的所有步骤监控
        - 网络流量带宽
        - 接口请求 QPS
        - 接口请求耗时
        - 接口访问次数、成功率、失败率
        - 在线总人数、活动区域房间人数
        - 消息堆积长度
    序号 场景类型 场景名称 活动目标或者对应的前端场景 峰值tps
    1 入口场景 在线选座 1小时、1000 个座位 2000
    2 入口场景 用户登录 1小时、20000 会员 2000
    3 入口场景 新注册用户 1小时、2000 会员 2000
    4 非入口场景 活动页 场景描述 2000
    5 非入口场景 选座页 2000
    6 非入口场景 选座数据查询 2000
    7 非入口场景 临时锁座接口 2000
    8 非入口场景 最终锁座接口 2000
    9 非入口场景 订单预处理接口 2000
    10 非入口场景 订单接口 2000
    11 非入口场景 促销接口 2000
    12 非入口场景 支付接口 2000
    13 非入口场景 支付回调接口 2000

    总结

    生产环境下的高并发、高流量活动真的没有那么简单。

    * 需要对活动涉及的业务架构进行梳理,确认整套活动业务架构都由哪些场景组成,各场景的操作流程是什么样的,哪些是入口场景,哪些是后续的场景,场景之间的交易路径和关联关系是什么
    * 需要对活动目标进行分析,从而预估出每个场景具体的业务峰值
    * 输出整个系统业务模型,包括所有的场景,及对应的目标峰值

    具体的改造过程也是一个成长的过程,希望大家一起努力吧~

    相关参考

    Tomcat 调优测试 - https://juejin.im/entry/57f47f660bd1d000589d8114
    大麦网技术二三事 - https://juejin.im/post/59ed9b44f265da43133c50b6


    如果你喜欢本文,请分享到朋友圈。
    想要获得更多信息,请关注我。

    版权属于:jcore.cn

    原文地址:http://www.jcore.cn/2017/11/01/architect-e-commerce

    除非注明,文章均为原创,转载时必须以链接形式注明原始出处。

    分享文章到:

    热门推荐文章