电商平台常常举行一些秒杀场景的活动来对商品进行促销,来带动整个企业的影响力;而秒杀活动通常是在特定的时间、特定的商品进行限量的销售抢购,这样会吸引大量的用户进行抢购,并在活动约定的时间点同时的进行秒杀抢购;这样也就造成以下特色:html
1)大量用户同一时间同时进行抢购,网站瞬时访问流量激增。前端
2)访问请求数量远远大于库存数量,只有少部分用户可以秒杀成功。nginx
3)购物车直接下单减库存。golang
4)秒杀商品下单减库存。redis
从上面的背景中咱们须要面对的问题就是,针对于电商平台如何让它能够在这种高并发、大流量的请求下让其可以平稳、满负荷的运转。因此这就须要引入流量监控平台,它可以实时了解各个服务器的运做参数、各个业务单元的请求数量;随时为决策者提供清晰的数据参考,以备调度。算法
流量监控,又能够理解为一种流量整形,是一个计算机网络的网络交通管理技术,从而延缓部分或全部数据包,使之符合人们所需的网络交通规则,速率限制的其中一种主要形式。shell
网络流量控制是用来优化或保证性能,改善延迟,和/或增长某些类型的数据包延迟知足某些条件下的可用带宽。若是某一个环节趋于饱和点,网络延迟可能大幅上升。所以,网络流量控制能够利用以防止这种状况发生,并保持延迟性检查。数据库
网络流量控制提供了一种手段来控制在指定时间内(带宽限制),被发送到网络中的数据量,或者是最大速率的数据流量发送。这种控制能够实现的途径有不少,可是一般状况下,网络流量控制老是利用拖延发包来实现的,通常应用在网络边缘,以控制进入网络的流量,但也可直接应用于数据源(例如,计算机或网卡),或是网络中的一个元素。api
限流算法主要为:漏桶、令牌桶、计数器缓存
一个固定容量的漏桶,按照常量固定速率流出水滴。
令牌桶算法是一个存放固定容量令牌的桶,按照固定速率往桶里添加令牌。
有时候咱们还使用计数器来进行限流,主要用来限制总并发数,好比数据库链接池、线程池、秒杀的并发数;只要全局总请求数或者必定时间段的总请求数设定的阀值则进行限流,是简单粗暴的总数量限流,而不是平均速率限流。
如下针对于国内比较大型的互联网企业针对于流量监控架构方面的信息搜集
没有找到相关的技术资料,只是找到2016年分享的 “阿里管控系统靠什么扛住全球最大规模的流量洪峰?”的文章,文章中提到了其不一样场景采用的算法和限流框架。
用户洪峰
考虑的因素是:
a) 容许访问的速率
b) 系统承受的最大洪峰
c) 洪峰爆发的间隔时间
处理方式: 令牌桶限流
回调洪峰
除了0点0分的这种流量洪峰,还有系统之间的回调引发的洪峰。想象一下这样的场景,物流系统为了处理发货信息,会隔一段时间调用交易系统来获取交易信息。为了提升效率,它每次批量查询交易系统的数据。这样,对交易系统也带来了流量的冲击。若是对这种回调不加以限制,那么可能交易系统忙于处理这种回调洪峰,对用户洪峰会疏于处理。
对于这种洪峰,有三种特点:
a) 有间隔频率
b) 每次调用量大
c) 容许有延迟
处理方式:漏桶算法
限流框架分为:监控模块、决策模块、规则变动模块、限流模块。
腾讯采用一种轻量级流控方案,方案以下:
一、计数器的key能“计时“
首先选择使用ckv做为计数器存储,相比redis开发会更熟悉,同时维护也更容易,固然该方案也能够选择redis做为计数器存储。
优点:方案用简单的方式将全局流控服务作成原子化(计数和计时原子化),开发门槛低。
二、请求统计用拉取的方式替换上报
对于请求的统计方式,通常全量上报不可行,全部业务的请求量至少1:1上报到ckv,ckv的容量和是个问题,单key也容易成为热点。定时或者定量批量上报,都没法保证明时流控,特别是请求量大的时候,流控延迟的问题会被放大。
优点:方案减小ckv的访问量,同时保证流控的准确性。
三、部署不须要agent
为了作更轻量的方案,咱们考虑agent的必要性,分析发现,agent要完成的功能比较简单,主要功能托管到业务流控api。
优点:方案不采用agent的方式,部署维护更简单。
四、全局及单机流控同时启用
方案对容灾作了充分的考虑,主要解决方式是全局及单机流控同时启用,即基于ckv的全局流控和基于单机共享内存的单机流控都同时工做。
优点:方案有很好的容灾能力,容灾方式简单有效。
五、解决ckv性能瓶颈,流控性能达百万/s
因为使用ckv的incr以及配额拉取的实现方式,全局流控接入服务请求的能力获得成本增加。
目前方案单独申请了一块ckv,容量为6G,使用incr的方式,压测性能达到9w+/s。
对业务空接口(Appplatform框架)作流控压测,使用30台v6虚拟机,单机50进程,压测性能达到50w+/s。
单接口50w/s的请求的服务接入,一样也能知足多接口整体服务请求量50w+/s的全局流控需求。
上述的压测瓶颈主要是Appplatform框架的性能缘由,因为拉取配额值是根据流控阈值设定(通常>10),50w+的请求量只有不到5w的ckv访问量,ckv没到瓶颈。
优点:方案使用同等的资源(单独一块6G的ckv),能知足业务的请求量更高,性能达百万/s。
六、支持扩容和动态流控升级
支持平行扩展流控能力,一套全局流控部署能知足流控的服务请求量是达百万/s,更大的服务请求量须要部署多套全局流控。
支持升级到动态流控能力,ckv写入的流控阈值是经过定时管理器完成,目前业务已经作了健康度上报,定时管理器只须要对接健康度数据,分析接口当前请求状况,动态调整流控阈值便可达到动态流控能力。
优点:方案总体简单轻量,扩容和升级都很容易。
关键流程图
京东10亿调用量的高可用网关系统所涉及的技术栈:
接入层 Nginx+lua 技术。
NIO+Serviet3 异步技术。
分离技术。
降级限流。
熔断技术。
缓存,哪些地方该加缓存,哪些地方能够直接读库。
异构数据。
快速失败。
监控统计,这是整个高可用网关系统里很是重要的一部分。
小米抢购限流峰值系统针对于小米商城秒杀抢购的实现及技术架构
大秒系统的架构设计
大秒系统主要由以下几个模块构成
限流集群 HTTP 服务放号策略集群 Middle 服务监控数据中心 Dcacenter监控管理体系 Master准实时防刷模块 antiblack基础存储与日志队列服务: Redis 集群、Kafka 集群等
整个大秒体系中大秒前端模块 (HTTP/middle/antiblack) 和监控数据中心使用 golang 开发,大秒监控管理体系使用 Python + golang 开发。
大秒的前端架构设计
大秒前端的架构设计从三个系统展开
限流集群 HTTP 服务
策略集群 Middle 服务
准实时反做弊 antiblack 服务
基于SOA架构理念,下降系统耦合性,接口定义清晰明确,保证独立子系统的健壮性高,下降故障跨系统扩散风险,从而将伸缩性的困难逐步分解到各个系统。
对系统进行分级,集中力量,突出重点系统。当当网从卖场到交易流程均属于一级系统,这部分系统直接关乎用户体验和订单量。在系统稳定性和可靠性等指标上,设计标准高于后台系统。
优先考虑用异步处理代替同步处理,作好系统异常的降级方案,保证有限的合格服务。
经过资料的收集,参考各大互联网企业的流量监控平台的架构搭建方案,大概了解涉及的系统模块组成、限流算法、限流方式和原理。
综合各方资料整理得出简要的流量监控方案,流量监控能够分为多个系统组成来完成其职责,这个平台主要的组成部分是:流量上报、限流、策略、调度。
主要用于采集系统的请求数据、状态和系统运行情况。有了这些运行数据,才能对外或对内进行决策处理;
1)对外和对外
对外用户请求
对内各个系统之间的回调请求
2)上报数据格式标准化
上报数据制定标准的
3)数据质量
4)实时和延时上报
5)硬件监控,如服务器的CPU、内存、网卡
6)心跳监控,时刻了解每个机器的运行状态
7)业务层监控,涉及JVM,Nginx的链接数
1)、采用开源与shell脚本搭建监控平台
2)、自行研发监控平台
主要是根据流量上报的数据结合策略、调度来 进行对超出预期请求的处理方式,好比限流、排队等措施;
根据不一样场景采用不一样的限流算法,能够借鉴阿里针对于用户访问、物流、交易的处理方式。
1)用户访问:采用令牌桶方式;
2)物流、交易:采用漏桶方式,平滑削峰处理;
3)购物车:采用分块网格化,单元处理
主要是经过提早设置的系统、业务场景参数,来用于决定什么场景用什么限流方式;相对的风险的应对,也是策略的重要之处;在活动进行时,根据监控上报的流量数据,动态灵活的调整策略也是很是重要的;经过整理的资料提成一下策略方案:
1)水平扩展
针对不一样服务器的压力进行增减服务器个数以实现服务的压力负载均衡,这样的话对于系统刚刚开始的伸缩性设计要求比较高,可以很是灵活的添加机器,来应对流量的变化。
2)系统分组
系统服务的业务不一样,有优先级高的,有优先级低的,那就让不一样的业务调用提早分组好的机器,这样的话在关键时刻,能够保核心业务。
3)业务降级
在一个用户请求,涉及到多个逻辑处理,其中有的是能够没有的,能够在高并发的状况下,能够经过开关设置,来对非主要逻辑出来进行关闭其请求,以提高了系统的主业务能力。
4)开关设置
对于每个系统业务请求,都增减相应的开关设置,能够实时应对高并发状况下,根据场景实现动态调度的做用。
提供给决策者相应的调度数据,实时展示系统运行状态,并在决策者下达决策指令后迅速执行策略;如何来实现大概的方案以下:
一、创建中心数据可视化平台
二、策略规则能够动态配置
三、各个业务线开关集中管理
四、自动化的脚本执行
五、运维服务的动态化管理
六、命令执行的分发协议和协同管理
流量监控为电商平台提供高效稳定的运行环境的基石,它是无时不刻的监控整个平台的运行状态、并为决策者提供实时数据以供参考;流量监控平台中的限流只是一种保护机制,如何承载高并发、大流量的用户请求,仍是须要与其余平台协做,以达到给用户极致的用户体验。
腾讯轻量级全局流控方案详解
当当网系统分级与海量信息动态发布实践
http://www.csdn.net/article/2014-11-07/2822541
https://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=402182304&idx=1&sn=1bd68d72e6676ff782e92b0df8b07d35&scene=1&srcid=12045k1zDgO7DLlMLwimBKjC&from=groupmessage&isappinstalled=0#wechat_redirect