本篇内容介绍了“应对高并发的方法有哪些”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
/01 高并发的定义/
首先，高并发的定义是什么?
高并发意味着大流量，需要运用技术手段抵抗流量的冲击。这些手段的效果好比你可以操纵流量，让流量可以乖乖地按照你的期望、更平稳地被系统所处理，带给用户更好的体验。对，就和大禹治水那样。
我想，几乎每个程序员心里都有过一个疑问，达到多少qps或者tps才算是高并发?
其实，这个问题无法单纯地通过一个统一标准的数字来判断。因为不同的业务所对应的复杂度不同，不能一概而论。
我自己用的评判标准是，当一个运行正常的系统在没有刻意优化性能的情况下，出现了性能问题，说明他开始进入到高并发的范围了。
对，就是这么简单粗暴，没有具体的数字。
但是在高并发是常态的场景中，一般都会有一个监控系统，会持续观察至少以下这几个指标是否正常。
-
tps。每秒事务处理量，这里的事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。(以客户端为视角)
-
qps。每秒查询率，可以通过并发量 / 平均响应时间计算得出。(以服务端为视角，一个tps可能会对应多个qps)
-
并发用户数。系统可以同时承载的正常使用系统功能的用户的数量。
-
响应时间。很多时候也叫rt，是指系统对请求作出响应的时间。
-
带宽。如果是一个数据传输量比较大的业务，还需要考虑带宽问题，比如视频、音频类应用程序。
如果你连这些指标的含义都不是很清楚，那就多读几遍，先搞清楚它们，否则你的高并发是闭着眼睛在做。
/02 应对高并发的思路/
很多缺乏经验的小伙伴，遇到高并发问题，不管三七二十一，上来就怼缓存。
用缓存是没错的，但是缓存也不是灵丹妙药，在哪里都适合。毕竟，缓存是「有状态」的，在软件开发中，处理「有状态」的东西总是比「无状态」的麻烦得多，因为存在数据一致性的问题需要考虑。
我建议你按照以下三个步骤来考虑这个问题。
01 梳理请求流转链路
梳理好了请求流转的链路，就好比你手里有了一张“作战地图”，你可以更加直观、准确地进行排兵布阵。
毕竟软件开发本身就是一个工程的问题，我们不能凭感觉，拍脑袋去做事。解决高并发问题自然也不例外。
02 确定目标
有一句话说得好，“没有最好，只有更好”。如果不先确定目标，这件事将会变成对性能无止境地追求。而过度的高性能，不但不会产生额外的收益，反而是对投入成本的浪费，毕竟资源是有代价的，而且是有限的。
我建议你将具体的数值目标细化到每一个 api 上。比如我一般会先确定整个业务线的 tps 要达到多少。例如，下单的 tps 要达到100。
接下来，我会根据前面梳理好的链路图，得到其中会涉及到哪些 service ，哪些 api ，有哪些 api 还会被不同的 service 多次调用的。
然后会根据链路中 api 被调用的先后顺序(一般越上游的 api 定的数值要适当放大)以及会被重复调用的次数，得到每个 api 的 qps 目标。比如，
-
获取购物车列表，存在两次调用，qps = 200。
-
批量获取商品库存，存在三次调用，qps = 300。
-
获取会员信息，存在一次调用，qps = 100。
-
……
照着这个思路，把所有业务线中会涉及到的 api 的 qps 都确定好，然后将相同 api 的 qps 数值相加，就能得到在整个系统层面每个 api 的理想 qps 数值(相当于是在各条业务线都达到预估峰值的情况下)。比如，
-
获取购物车列表，出现在三个业务线，qps = 200 500 100 = 800。
-
批量获取商品库存，出现在两个业务线，qps = 300 200 = 500。
-
获取会员信息，出现在两个业务线，qps = 100 200 = 300。
-
……
当然了，实际制定的目标除了 qps 以外，还有其它指标，上面只是举个例子。
另外，需要额外注意的是，要关注 tp90、tp99 的「响应时间」。因为就算平均响应时间达标了，也不代表整个系统很稳定。因为可能存在80%的请求响应速度特别快，把平均值拉低了，但是同时还存在大量的耗时特别严重的请求。我惯用的经验是，如果tp99超过了平均值的一倍，就需要引起重视了，因为这意味着某个地方存在着明显的性能瓶颈。
03 制定具体的优化方案
其实具体的优化方案有很多种，要根据实际的情况来选择。不过具体怎么选择，还是需要你有全局视野。因为整个系统是一体的，通过相互配合形成合力，可以大大降低优化的难度。比如，选择某个优化方案后，上游的 api 能扛掉90%的流量不往下游请求，那么下游 api 的 qps 目标也可以适当降低了。
以下就是我综合复杂度和成本所排列的具体方案，从简单到复杂。
-
鸿蒙官方战略合作共建——harmonyos技术社区
-
先在代码层面做优化，比如代码性能，多线程，请求合并，池化(连接池、线程池、对象池等等)。
-
能升级硬件的就升级硬件。
-
能用缓存解决的坚决不做系统拆分。并且，缓存尽可能做到上游。比如， cdn >页面> api > service 。
-
如果在数据处理上产生瓶颈，那么优先考虑业务上是否接受异步，如果接受，那么用 mq 来削峰填谷。或者限流降级。
-
如果 mq 也不顶用，是整体吞吐量上的瓶颈的话，只要不是写数据的瓶颈，尽量通过程序拆分而不是数据库拆分来解决问题。(此时需要引入服务治理，另外，会存在一致性问题，数据合并问题要解决)
-
非得动到数据层面的话，优先考虑数据库读写分离，而不是直接拆分数据。
-
实在迫不得已需要拆分数据，优先考虑根据业务垂直拆分，而不是水平拆分。(水平拆分的数据合并代价会比垂直拆分更大)
-
最后才是数据库水平拆分，支持无限扩容，一劳永逸。
你看，虽然方案有很多，但是你也能观察到一些规律：越在上游解决问题，成本越低。所以，以漏斗思维来做全局的考虑是最适合不过的。从客户端请求到接入层，到逻辑层，到 db 层，层层递减，过滤掉请求，哪怕是出现异常也要 fail fast(要失败也要尽早返回)。
/03 落地/
真正落地的时候，涉及到的具体技术细节就多了，负载均衡啊、缓存啊、消息队列啊、分库分表啊等等。我这里就不展开了，每一点展开都要写好多。有兴趣的小伙伴可以移步我之前写的分布式系统系列文章——《8个月打磨，一份送给程序员的「分布式系统」合集》
其实，真正要把高并发当作一个系统化的事情来看待，视野不能仅仅局限在「性能」这一个维度上，还至少需要考虑「可用性」和「扩展性」这两个方面。
可用性就是系统可以正常服务的时间。一个虽然访问速度没那么快，但是全年不停机、无故障;另一个虽然访问速度很快，但是隔三差五出现上事故、宕机，用户肯定选择前者。
扩展性表示系统的快速扩展能力，当遇到突发的大流量冲击时，能否在短时间内完成扩容，以承接这部分流量。比如，双11活动、明星热搜等场景。毕竟，我们不可能准确地预测未来的流量一定在什么范围内，也更加不可能随时为它准备着大量冗余的资源。
所以，这三个目标是需要通盘考虑的，因为它们互相关联、甚至相互影响。
比如，当你考虑系统扩展能力的时候，你会将服务设计成无状态的，这种设计其实不但提高了可扩展性，其实也间接提升了系统的性能和可用性，因为你可以随时横向扩展。
再比如，为了提高可用性，通常会对服务接口进行超时设置，以防大量线程阻塞在慢请求上造成系统雪崩。具体超时时间的设置成多少，参考的就是 api 的性能表现。
“应对高并发的方法有哪些”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注本站网站，小编将为大家输出更多高质量的实用文章！
