Go篇｜三高指标

这是我参与更文挑战的第16天，活动详情查看： 更文挑战

碎碎言

本项目是重学Go语言后的实战项目，主要目的是加深Go学习，并经过此学习，对系统的高可用，高并发，高性能可以进一步的学习。

一我的走的很快，一群人走的更远，欢迎留言点评提出大家的问题和建议。将来的日子里，一块儿成长，加油！！！

时间计划：6月13日-6月30日

日期：2021年6月16日

今日内容：高可用、高性能、高并发的指标

前面咱们将功能性的需求几乎都已经都陈列出来，这些几乎是从外部因素考虑的。但对于运行系统的环境，以及系统的并发能力也是咱们须要考虑的，这部分可称为非功能需求。

非功能性需求包括：可用性、并发能力、性能、安全防御能力、水平扩容缩容能力、运维/运营成本等

好比：一个系统的可用性达到99.99%。并发能力达到100万QPS，请求延迟低于500ms，能防范跨站脚本攻击，1分钟快速扩容，总成本控制在10万元每个月等等，这些都是非功能需求要知足的。

因此，系统须要知足非功能需求的一些指标，以防止系统在运行时出现重大的故障。

秒杀系统的核心非功能需求主要有：高可用指标、高性能指标、高并发指标

高可用指标

• MTBF(Mean Time Between Failure 平都可用时长) ：系统正常、稳定运行的平均时长
• MTTR（Mean Time to Repair 平均修复时长）：系统从失效后到恢复正常所耗时的平均时间
• SLA（Service-Level Agreement 服务等级协议）：用于评估服务可用性等级，公式是SLA=MTBF/(MTBF+MTTR)。可用性高于99.99%，是指SLA高于99.99%

系统高可用的指标是SLA来判断

系统P 是由四个子系统a、b、c、d构成。那么，系统P的SLA是低于其余四个子系统；下游系统的SLA一般须要高于上游SLA，这样才能保证上游系统的稳定

高并发指标

QPS（Queries Per Second 每秒查询率）是衡量系统的承载能力。

不一样的业务对并发能力要求不一致，用户量小的系统对并发要求相对比较低，用户量大的就要求比较高。

评估高并发指标，一般须要从用户增加、用户习惯、业务形态、系统承载能力等方面分析。就好比，秒杀系统，用户量确定远大于库存量，库存一旦为0则活动就结束。

系统资源在设计上保留10%～20%的余量，以便应对突发流量

评估用户增加状况，须要月/日活用户的量，再加上因推广过程带来的用户增加来预估一个当日活动可能达到一个用户量。而后在业务系统设计上保留余量。

好比评估业务承载最高270万QPS，底层Redis承载能力1万QPS。实际设计中，业务承载服务300万，要高些以防突发突增流量，底层Redis资源8000QPS，低一些，由于底层资源比较固定不容易扩容，须要限制QPS不要超出其最大承载能力

高性能指标

对于电商平台若是访问请求超过2s影响用户体验，超出5s有可能致使流失用户，形成损失。如下因素将会影响性能指标：

• 用户网络环境
• 请求/返回数据大小
• 业务系统CPU、内存、磁盘等性能
• 下游资源的性能
• 算法实现是否高效
• 请求链路长短

为确保知足性能要求，咱们对这边流量比较大的系统通常须要作大量的性能测试和性能调优。

场景：用户请求系统的网络环境延迟100ms，请求/返回数据处理为10ms，业务内部磁盘操做30ms，请求下游资源10ms，算法计算5ms。那么，整个请求共耗时将超过155ms。

若是超过155ms对公司形成必定损失，那么咱们还须要继续优化性能。固然，优化过程也须要考虑成本等各类问题，并不是指标越高越好。