企业网站优秀案例,优化近义词,网站系统应怎么做会计分录,制作网站报价单大家好#xff0c;我是Z哥。最近正好在编写一套新的面试题#xff0c;其中有一道是与高并发相关的。出题的目的是想了解一下候选人面对大流量场景下的优化思路。在出这道题的过程中#xff0c;我自己也梳理了一下自己对这个问题的思路。然后之所以想在这里分享出来#xff… 大家好我是Z哥。最近正好在编写一套新的面试题其中有一道是与高并发相关的。出题的目的是想了解一下候选人面对大流量场景下的优化思路。在出这道题的过程中我自己也梳理了一下自己对这个问题的思路。然后之所以想在这里分享出来是因为这是我这些年经过实战所得出的躺着“血汗”的经验所以我觉得这可能对很多读者都有所帮助。不过丑话说在前面我的思路并不是完美的毕竟条条大路通罗马解决「高并发」的思路也有很多种。所以欢迎大家在评论区分享你的看法。/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 目标也可以适当降低了。以下就是我综合复杂度和成本所排列的具体方案从简单到复杂。先在代码层面做优化比如代码性能多线程请求合并池化连接池、线程池、对象池等等。能升级硬件的就升级硬件。能用缓存解决的坚决不做系统拆分。并且缓存尽可能做到上游。比如 cdn 页面 api service 。如果在数据处理上产生瓶颈那么优先考虑业务上是否接受异步如果接受那么用 MQ 来削峰填谷。或者限流降级。如果 MQ 也不顶用是整体吞吐量上的瓶颈的话只要不是写数据的瓶颈尽量通过程序拆分而不是数据库拆分来解决问题。此时需要引入服务治理另外会存在一致性问题数据合并问题要解决非得动到数据层面的话优先考虑数据库读写分离而不是直接拆分数据。实在迫不得已需要拆分数据优先考虑根据业务垂直拆分而不是水平拆分。水平拆分的数据合并代价会比垂直拆分更大最后才是数据库水平拆分支持无限扩容一劳永逸。你看虽然方案有很多但是你也能观察到一些规律越在上游解决问题成本越低。所以以漏斗思维来做全局的考虑是最适合不过的。从客户端请求到接入层到逻辑层到 DB 层层层递减过滤掉请求哪怕是出现异常也要 Fail Fast要失败也要尽早返回。/03 落地/真正落地的时候涉及到的具体技术细节就多了负载均衡啊、缓存啊、消息队列啊、分库分表啊等等。我这里就不展开了每一点展开都要写好多。有兴趣的小伙伴可以移步我之前写的分布式系统系列文章——《8个月打磨一份送给程序员的「分布式系统」合集》其实真正要把高并发当作一个系统化的事情来看待视野不能仅仅局限在「性能」这一个维度上还至少需要考虑「可用性」和「扩展性」这两个方面。可用性就是系统可以正常服务的时间。一个虽然访问速度没那么快但是全年不停机、无故障另一个虽然访问速度很快但是隔三差五出现上事故、宕机用户肯定选择前者。扩展性表示系统的快速扩展能力当遇到突发的大流量冲击时能否在短时间内完成扩容以承接这部分流量。比如双11活动、明星热搜等场景。毕竟我们不可能准确地预测未来的流量一定在什么范围内也更加不可能随时为它准备着大量冗余的资源。所以这三个目标是需要通盘考虑的因为它们互相关联、甚至相互影响。比如当你考虑系统扩展能力的时候你会将服务设计成无状态的这种设计其实不但提高了可扩展性其实也间接提升了系统的性能和可用性因为你可以随时横向扩展。再比如为了提高可用性通常会对服务接口进行超时设置以防大量线程阻塞在慢请求上造成系统雪崩。具体超时时间的设置成多少参考的就是 API 的性能表现。好了总结一下。这篇呢Z哥和你分享了我对高并发问题的处理思路。按照以下三个步骤进行。梳理请求流转链路确定目标制定具体的优化方案其中的第2和3点在文中给了很多实操细节这里就不一一罗列了。希望对你有所帮助。业务都是从0到1做起来的在业务量逐渐变成原来的10倍、100倍的过程中你是否用到了高并发的处理思路去演进你的系统从架构设计、编码实现、甚至产品方案等维度去预防和解决高并发的问题推荐阅读8个月打磨一份送给程序员的「分布式系统」合集我在职场经历的四个阶段原创不易如果你觉得这篇文章还不错就「点赞」或者「在看」一下吧鼓励我的创作 也可以分享我的公众号名片给有需要的朋友们。如果你有关于软件架构、分布式系统、产品、运营的困惑可以试试点击「阅读原文」
