偶尔看到公司内部的监控系统,挺感兴趣的,就看了看,大概看明白了,主要是一些关于程序监控指标的,经过一堆乱七八糟的查询,先记下来,欢迎各位看官评论。
背景
我们在编码过程中经常会遇到一些熟悉的,高大上的词汇,比如:高并发,高可用;一般都是用来吓唬小孩的,我看了一个小时的网文,结合了一些监控指标来给大家描述一下,由于没有正统的文章书籍,如果有不对的地方还请大家指导。
监控指标
PV
PV:page view
页面浏览的次数,这个多好理解,当你打开一个网页,那么这个页面的pv+1;
一般情况下,我们可以得出维持日常情况下的服务器总数量
服务器数量= ceil(每天总的pv数量/单台服务器的pv数量)
QPS
QPS:queries per second
每秒响应的请求的数量,也有一种说法是指每秒响应的查询次数,这两者区别还是蛮大的,主要在于他们的范围大小不一样,其实我比较偏向于后者,因为他的英文释义翻译过来就是每秒查询数的意思,但是公司的监控指标是按照前者分析的,所以文章里面我就按照前者分析了。
拿一个图片举例子
这个图片表达的意思是指,在10点54分本机器(单机qps图)响应的查询次数是1.433(应该是一分钟之内的每秒平均值)。
QPS的计算方法:
QPS= 总请求数/(进程总数*请求时间)
由于大部分系统在一天的工作实践中,不同时间段会有不同的请求量,所以一般还需要引进峰值QPS的概念。
峰值QPS:
指的是高峰时间内的每秒查询
eg:
某一个系统每天有90%的访问量集中在20%的时间内,那么20%的时间就叫做峰值时间。
峰值QPS = (总PV数量 x 90%)/(一天的时间 x 20%)
抗高并发的机器数量= 峰值QPS/ QPS
----假设某网页一天负载与一台服务器上的的访问量是30w,那么
QPS = (300000 x 90%)/ (86400 x 20%) = 16
此时,为了满足业务4的QPS,就需要4台服务器来抗。
TPS
TPS:transactions per second
是每秒内的事务数,比如执行了dml操作,那么相应的tps会增加;
RPS
RPS=requests per second
并发数/平均响应时间(这个和我们使用的QPS是一个意思)
TP99(TP90、TP999、TP50)
以上都是一个意思,拿TP90进行描述,指的是90%的请求得到服务的最长时间。
实现逻辑,将所有的请求按照请求消耗时间进行升序排序,第90%的请求时间就是TP90的数据值
环比与同比
以上的指标都是在一期监控报告中所展示的监控内容
为了系统的横向比较,有同比概念引入,而为了纵向判断一个系统使用率的情况,会有环比概念
环比增长率=(本期数-上期数)/上期数×100%
同比增长率=(本期数-同期数)/同期数×100%
高并发
一定要知道的是,只说高并发,不说高可用,都是流氓,这是一篇文章里说的,我觉得很对。我想加两句,只说并发效率,不说业务指标,都是扯淡。只说相应速度,不说硬件条件,都是放屁。
我所认为的高并发,是在特定的服务集群下,特定的业务指标上,可以实现高可用的系统才有资格讨论高并发。
目前来说,高并发这种高大上的东西,很多老师比我要懂得太多了,经验也老道。我就单纯引用理解就够我摸索了。一下内容来源于网文,我觉得蛮有道理的。
首先是无状态前端机器不足以承载请求流量,需要进行水平扩展(加机器容灾并发数),一般QPS是千级。
然后是关系型数据库无法承载读取或写入峰值,需要数据库横向扩展或引入nosql(加缓存,提高读写能力),一般是千到万级。
之后是单机nosql无法承载,需要nosql横向扩展(增加缓存设备),一般是十万到百万QPS。
最后是难以单纯横向扩展nosql(纵向扩展缓存,多级缓存增加),比如微博就引入多级缓存架构,这种架构一般可以应对百万到千万对nosql的访问QPS。 当然面向用户的接口请求一般到不了这个量级,QPS递增大多是由于读放大造成的压力,单纯属于高并发架构考虑的范畴。
据说!!!!
微博每天1亿多pv的系统一般也就1500QPS,5000QPS峰值。
也有人说有人说:
2C4G机器单机一般1000QPS。
8C8G机器单机可承受7000QPS。
具体如何去处理,主要根据业务要求来判断具体的效率,和判断一个业务的效率高低就需要以下步骤:
1、首先需要明确现状
明确硬件标准
明确优化指标
明确请求耗时
这些东西就需要用到我刚刚说到的监控指标。
而监控维度大到一个集群的指标,小到sql的指标。我觉得一般应该分为
集群,单机,系统进程,接口,sql
这样定位问题才准确
2、明确了现状尽可以根据问题的出处来进行优化,是sql优化,还是接口优化,是负载不合理,还是需要更多服务器,是需要加入纵向缓存,还是加入横向缓存。
如果有其他意见或者补充,还请同学评论添加。