在网站推广活动之前,业务方根据经验评估出的系统访问量PV,然后根据各个系统所占的流量比例,计算出每个子系统的访问量,比如商品列表1000万,商品详情1500万,下单500万等,然后根据每个系统和数据库的交互次数,来算出数据库的访问量,比如访问量巨大的首页,我们一般存放到CDN缓存中,并且将页面进行静态化,动态数据通过异步获取,通过CDN系统的智能路由,能够将用户的请求路由到离他最近的CDN缓存机器上获取页面;系统峰值评估时,会遵循一个原则:80%的访问请求将在20%的时间内到达,则峰值qps= (总PV*80%)/(60*60*24*20%),所需要的机器数 = 峰值qps /单台机器所能承受的最高qps,可以通过访问日志分析(下回讲解),在高流量时期,实时计算出当前系统的qps值,绘出水位图:当前水位= 当前总qps/(单台机器极限qps*机器数)*100%,从而来达到监控流量的目的;
既然我们已经知道如何监控流量,那如何来控制流量,不让流量超出它的系统最高水位呢?方法有:对系统的总并发请求书进行限制,限制单位时间内的请求次数,通过白名单机制来限制每一个接入系统调用的频率等,如果限制总并发请求,那超出来的部分浏览应该如何处理?最简单的方式直接返回,其中java中采用的信号量机制,但是这样会带来糟糕的用户体验,
当然直接返回的方式太粗暴,我们可以通过单机内存队列来进行有限的等待,可以提升用户体验和提高资源利用率,同样采取的还是java信号量机制;
还有可以采取分布式消息队列来将用户的请求异步化,其中用到的工具就是ActiveMQ消息中间件,用户的请求直接提交给分布式请求处理队列,提交成功则视为处理成功,系统返回,后端通过不断的读取请求队列中的数据,来进行业务逻辑处理,,这样,请求的接收与业务逻辑就实现了解耦,当请求多时,则请求进入请求处理队列排队,这样做的好处是:解耦,前端客户能及时得到响应,后端也可以以固定的频率来处理业务,不至于被过大流量击垮,当然,这样也是存在问题的,存在的问题:队列的容量有限,如果有大量请求且持续时间很长,会导致消息积压,并且以异步的方式提交,对于队列系统的可靠性也是一大考验,而且有的业务必须保证消息成功投递,就需要使用到事务消息,对于重复投递的消息,也需要有去重机制来保障,否则消息被重复处理会导致数据紊乱;