zoukankan      html  css  js  c++  java
  • 实际项目中如何应对高并发等场景

    一、高并发

    1. 高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。

    高并发相关常用的一些指标有响应时间(Response Time),吞吐量(Throughput),每秒查询率QPS(Query Per Second),并发用户数等。

    响应时间:系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms,这个200ms就是系统的响应时间。

    吞吐量:单位时间内处理的请求数量。

    QPS:每秒响应请求数。在互联网领域,这个指标和吞吐量区分的没有这么明显。

    并发用户数:同时承载正常使用系统功能的用户数量。例如一个即时通讯系统,同时在线量一定程度上代表了系统的并发用户数。

    2.如何处理应对高并发场景?

    1.前端处理

    1. 采用前后端分离的模式,前端项目单独部署到服务器上面

    2. 前端对请求接口进行置灰操作,等到这个时间点再开启点击

    3. 前端加入CDN 加速服务

    4. 前端引入Nginx,如果不够,加入集群Nginx,还不行,直接上LVS

    5. 前端对访问的URL 进行特殊处理,MD5加密请求后台,或加入特殊的字符去请求后台,后台识别到进行访问,否则直接返回null

    6. 前端限流:这个很简单,一般秒杀不会让你一直点的,一般都是点击一下或者两下然后几秒之后才可以继续点击,这也是保护服务器的一种手段

    2.后端处理

    1. 服务单一原则,秒杀就是秒杀服务,商品就是商品服务,一个服务挂了,不至于把其他服务搞崩溃

    2. Redis做集群,读多写少,Redis集群主从同步读写分离 还搞点哨兵,开启持久化直接无敌高可用!

    3. Nginx大家想必都不陌生了吧,这玩意是高性能的web服务器,并发也随便顶几万不是梦,但是我们的Tomcat只能顶几百的并发呀,那简单呀负载均衡嘛,一台服务几百,那就多搞点,在秒杀的时候多租点流量机

    4. 秒杀的时候肯定是涉及到后续的订单生成和支付等操作,但是都只是成功的幸运儿才会走到那一步,那一旦100个产品卖光了,return了一个false,前端直接秒杀结束,然后你后端也关闭后续无效请求的介入了。

    5. 库存预热, 秒杀前你通过定时任务或者运维同学提前把商品的库存加载到Redis中去,让整个流程都在Redis里面去做,然后等秒杀介绍了,再异步的去修改库存就好了。

    6.削峰填谷MQ你可以把它放消息队列,然后一点点消费去改库存就好了嘛,不过单个商品其实一次修改就够了,我这里说的是某个点多个商品一起秒杀的场景

    7. 加入分布式锁,多个请求来的时候,可以防止超卖问题

    8. 限流&降级&熔断&隔离,

    原文入口

    一个小小后端的爬行痕迹
  • 相关阅读:
    [BZOJ2212][POI2011]Tree Rotations(线段树合并)
    [BZOJ3569]DZY Loves Chinese II(随机化+线性基)
    [BZOJ3237][AHOI2013]连通图(分治并查集)
    [BZOJ4945][NOI2017]游戏(2-SAT)
    [BZOJ4568][SCOI2016]幸运数字(倍增LCA,点分治+线性基)
    [BZOJ2460][BJOI2011]元素(线性基)
    [BZOJ4942][NOI2017]整数(线段树+压位)
    [P2023][AHOI2009]维护序列(线段树)
    [HDU4336]Card Collector(min-max容斥,最值反演)
    [COGS2426][HZOI 2016]几何
  • 原文地址:https://www.cnblogs.com/heikedeblack/p/14373658.html
Copyright © 2011-2022 走看看