企业级应用高性能可扩展架构设计
前言
马上又要618了，每年到了这个时候，商家就开始促销，价格低会吸引来超多用户，对系统来说就是更多的流量，技术上如何确保网站稳定运行，且不被超卖，同时还要让用户有个良好的购物体验。
12306网站在最开始的时候，经常出现系统瘫痪，而如今也已经能够支持同时上千万人同时抢票且不受影响。
这些都离不开高并发技术，以及根据业务进行架构设计，应对流量的冲击。
今天我们一起来谈谈这些与架构设计有关的技术
文章目录
- 前言
- 一. 高并发
-
- 1.1 什么是高并发
- 1.2 高并发有什么关键指标
- 二. 高可用
-
- 2.1 高可用的衡量指标
- 2.2 服务器的可用性数字化的衡量指标
- 总结
个人主页：我是沐风晓月
个人简介：大家好，我是沐风晓月，阿里云社区博客专家
座右铭： 先努力成长自己，再帮助更多的人 ，一起加油进步
欢迎大家：这里是CSDN，我总结知识的地方，喜欢的话请三连，有问题请私信
一. 高并发
1.1 什么是高并发
高并发，通常是指通过设计保证系统能够同时处理很多请求，也就是在同一个时间点，有很多请求同时访问同一个接口。
高并发是一种系统在运行过程中遭受的“短时间内大流量冲击” 的情况，如果处理不好，就很容易造成系统吞吐量下降，响应变慢，从而影响用户体验，甚至可能造成系统无法提供服务的情况。
这时候我们通常需要优化系统，硬件，网络，应用，数据库等来达到高并发要求。
1.2 高并发有什么关键指标
-
响应时间
响应时间是衡量系统性能的重要指标之一，它表示系统从接收请求到向用户返回响应所需要的时间。
响应时间是用户感知系统性能的关键因素之一，因为它直接影响到用户满意度和用户转化率。当一个用户发出请求时，如果系统不能在很短的时间内提供响应，则用户可能会感到不耐烦，并可能在等待时间过长后离开网站、应用或服务
从用户角度来说，响应时间越长，用户体验感越差，响应时间越短，用户体验越好，留存率也越好。
从系统角度来说： 响应时间决定着系统的性能，响应时间越短，系统性能越高，也就能更好的处理业务。
- 吞吐量
吞吐量是单位时间内系统所处理的用户请求数。
对互联网应用来说，吞吐量能够反映系统的负载能力。
公式1： 吞吐量=并发数/平均响应时间
公式2： 吞吐量=请求总数/总时长
- 每秒钟请求数（QPS)
QPS指的是服务器在一秒内共处理了多少个请求，主要用来表示读的请求。
依据二八原则，80%的流量是在20%的时间里产生的，比如现在有 5000000 个请求，预估白天的QPS=（5000000 0.8）/ 1260600.2 =462
然后分析业务得到最高QPS可能是平均的两倍，当前的系统峰值就是462*2=924
预估出QPS后，再根据峰值 QPS/单台机器可承受的qps， 算出需要多少台服务器。
机器数== 峰值QPS/ 单台机器最高可承受的QPS
- 每秒事务数TPS
举例来说，如果你在银行办理转账业务，每一次的转账都是一个事务，那么银行的TPS就是指每秒内可以处理多少笔转账业务。
TPS通常用于评估系统的性能和负载能力，同样适用于高负载场景下的互联网服务提供商。例如，电商平台可以通过监控TPS来判断系统的稳定性和用户满意度。
值得注意的是，虽然QPS和TPS都是用来衡量系统的吞吐能力，但由于事务通常比请求需要处理更多数据，并且需要更长的处理时间，因此，在大多数情况下，TPS 的值要比 QPS 小。
TPS主要包含以下三个过程：
- 客户端请求服务器端
- 在服务器端内部进行业务逻辑处理
- 服务器端响应客户端。
当一个用户访问一个完整页面时，请求+响应的整个过程就是一个TPS。
这一次完整的请求可能产生多次对服务器的请求，这些请求计入QPS
假设访问一个页面时候会请求服务器3次，这样的一次访问会产生1个TPS和3个QPS
-
访问量PV
pv是页面浏览量，用户每对网站中的一个网页访问1次均被记录1次，用户对同一个页面的多次访问被累计记录，PV是评价网站流量的最常用指标。 -
独立访客 UV
独立访客数记录标准一般为"一天"，即一天内如果某访客从同一个IP地址来访问某网站n次的话，访问次数计作n, 独立访客数则计作1。
同一天内同一个IP多次访问同一个网站只记为1个。
二. 高可用
高可用性是指一个系统经过专门的设计后具备的减少停工时间并保持提供服务的高度可用性。该特性是衡量系统提供服务能力的一个特征，也是对系统进行设计时需要考虑的一个重要因素。
对于分布式数据库系统而言，“三高一易”（高可用、高可靠、高性能、易用性）几乎囊括了所有重要的特性。而随着互联网需求和技术的发展，高可用性被提到一个新的高度。CAP理论认为，A（可用性）应当被更加重视
2.1 高可用的衡量指标
- 可用性：系统必须能够在任何时候都处于正常运行状态，即便是在故障发生的情况下也应如此。
- 可靠性：系统必须能够保证每个用户请求都能够得到可靠的响应，而不是出现错误或系统崩溃等异常情况。
- 可恢复性：系统必须能够快速恢复到正常运行状态，以最小化业务中断和数据损失。
- 可扩展性：系统必须能够快速、有效地适应业务增长和变化，以满足不断变化的需求。
- 负载均衡：系统必须具备负载均衡的能力，能够平衡工作负载，充分利用所有可用资源，确保高性能和稳定性。
- 安全性：系统必须能够通过强大的身份验证、访问控制和数据加密等多重安全措施，保护数据和应用程序免受恶意攻击和数据泄露。
- 性能：系统必须能够处理和响应大量的用户请求，保持高性能和低延迟。
2.2 服务器的可用性数字化的衡量指标
- SLA（Service Level Agreement）：服务等级协议是指服务提供商与客户之间达成的关于服务水平的约定，通常包括服务的可用性、响应时间、故障修复时间等。
- SLO（service level objective）服务等级目标，指的是设计可用性，其意思即为设计该产品时期望达到的可用性目标。
- MTBF（Mean Time Between Failures）：平均故障间隔时间，是指系统正常工作期间，平均多长时间才会发生一次故障。
- MTTR（Mean Time To Repair）：平均修复时间，是指当系统出现故障时，平均需要多长时间才能进行修复。
- MTTF（Mean Time To Failure）：平均失效时间，是指系统平均能够稳定运行的时间，即从系统启动或上次故障发生以来到下一次故障发生之间的时间。
- Uptime：系统正常运行时间的百分比，可以通过系统日志或监控工具来计算。
- Response Time：服务响应时间，是指从用户发出请求到系统返回响应之间所需的时间。该指标是用户感受服务性能的重要指标，对于一些需要低延迟响应的应用程序而言尤为重要。
- TPS（Transactions Per Second）：每秒事务处理数，是指系统在每秒钟内能够处理的事务数量。该指标通常被用于衡量系统的处理能力和负载能力。
上述指标可以帮助服务提供商评估其服务的可用性和性能，便于提高服务质量和满足客户需求。
我们平常经常看到互联网公司喊口号，我们今年一定要做到3个9、4个9，即99.9%、99.99%，甚至还有5个9，即99.999%。 这些就是服务器的可用性数字化的衡量指标的SLA 服务等级协议。
这么多9是怎么计算的呢？
全年拿365天做计算吧，看看几个9要停机多久时间做能才能达到！
1年 = 365天 = 8760小时
99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时
99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟
从以上看来，全年停机5.26分钟才能做到99.999%，即5个9。依此类推，要达到6个9及更多9，可以说非常难了。
总结
本文主要介绍了高性能架构的理论基础，后续再讲解架构的设计案例。
好啦，这就是今天要分享给大家的全部内容了，我们下期再见！✨ ✨ ✨
如果你喜欢的话，就不要吝惜你的一键三连了~