高并发高性能高可用的问题分析及处理方式

Posted 2023-03-31 剑飞的编程思维

寄语

作者对于技术学习是希望大家是以思考的方式去探索学习，然后形成自己的能力思维。我相信所有的事物的发展必然是一步步演进的，只有真正能了解这个过程才算是掌握了知识。

三高架构        

        什么是三高架构？所谓三高，就是高并发，高可用，高性能。这是互联网行业内人都了解得。三高问题的产生是从何而来？自从有了微服务诞生，分布式服务的架构的诞生，互联网用户的急剧的增加，带来了用户的访问需求，从而就引起三高问题。场景是：

• 高并发：在较小的一段时间内，较多的用户发起访问请求
• 高可用：在任何情况下，用户发起访问请求的成功率要尽可能达到100%
• 高性能：用户发起访问请求之后，在较小的时间内用户能接收到响应

        这三种情况下，用户访问量达到多少才算高并发？请求成功率达到多少才算高可用？响应请求时间达到多少才算是高性能？先不讨论解决方案，先抛出这些过程中可能会出现的问题。三高问题一般情况都不是单独产生的。

        对于系统而言三高是系统的非功能性需求，这就会出现在很多时候系统上线初期没有问题，如果你没有去监控治理系统的话，很可能某一天突然就会出现问题。这个时候三个问题产生不会独立出现，比如可用性出了问题，肯定伴随有性能问题产生；并发量上升了之后，会带来稳定性和性能上的问题。

问题场景

代码问题

        代码问题主要是影响性能，主要体现在IO的使用，对象的创建，逻辑的冗余，算法等等。这个就纯粹是基础知识问题。如果要避免这些问题除了要看经验外，其次就是基础知识点要扎实。但是我们可以在开发过程中有几类影响性能问题的一些点注意下：

1.  IO数据读取，这个在程序中不管用什么工具中间件都是最消耗性能的，所以一定要控制IO次数
2. 交互逻辑和计算逻辑，在程序运行时计算的速度，也就是常用算法编写也是会影响应能。
3. 网络问题，当需要传输的数据增加了，所需要网络带宽也要考虑，数据冗余不要过多

 常见解决方法： 批量IO操作，SQL优化，简化响应数据，多线程处理任务，异步处理等。核心方案就是掌握好基本知识点，学会应用。

请求性能问题

        这个主要体现在有些请求的性能有问题，处理起来比较消耗资源(CPU,带宽)。当并发量不高的情况下这些请求看起性能还可以，响应时间也较短。但是当请求量并发较高之后，资源的消耗就会呈直线上升，很快就会导致CPU资源不足，性能就会变差。如果没有及时处理，就会引起恶行循环。会导致服务不可用。直观现象就是可以支持的并发量不足。出现这种问题的原因首先是代码问题引起的，还有也有可能资源配置不足(JVM的参数配置)，也有可能是数据交互量过大。

请求处理速度问题

        请求处理的速度直接关系可以支撑并发量的大小。这种典型的问题就是在一定时间内大量请求需要处理，然后需要处理这些请求需要分配资源。服务器的资源是有限的，当已经分配的资源还在处理请求未完成时，还有不断的请求进来，这时候就没有资源可用，新进来的请求就没有办法处理，请求和就会失败。同事当资源不足时候，大概率会导致性能也有问题，请求响应也会不及时，然后甚至引起服务不可用。

服务宕机问题

        宕机是我们大家所熟知的，就由于资源不足，程序死循环，死锁等都可能会引起服务宕机。这个从理论上来讲，宕机是不可避免的问题。但是在互联网时代，服务宕机，停止服务是完全不可接受的，对于高用户量访问来说，宕机几分钟，损失就不可估计。所以针对宕机的情况，我们要只允许服务部分宕机，不能是全部宕机停止服务。

以上三类问题分别代表了高并发，高性能，高可用典型的问题。

三高解决方案

         解决三高问题有多个角度去思考，首先可以从架构层面去考虑思考，其次也需要从技术层面去思考。然后随着技术的更替和需求的迭代升级， 应用一些新技术也是需要持续去跟进的。通过以上分析三高问题，都是属于量变引起质变的问题。上面的问题分析其实也基本解释了引起了什么样的质变。根本型要解决就是资源的竞争问题，不管是请求多了，还是宕机，都是资源的竞争使用问题，那么我们的核心思路就是考虑怎么去扩展我们的资源。

架构层面

 集群部署

        集群就是把我们提供服务的组件部署多分，可以在不同的区域(跨域)，每个区域部署个节点提供服务。提供服务的节点多了，所支撑的并发量可以多了，那么可用性也会大大提高。比如某一台机器或者某一个区域的机器宕机（停电）依然可以通过这个集群提供服务。另外根据用户分布的不同的区域，可以动态让用户请求到离他比较近的区域服务器，同样可以提高性能，就比如抢红包，如果发红包的人距离你比较远，在同等网速下，那你肯定就比离他近的人满一点点，就会抢不到。

        有了集群后，那么这些集群是否提供服务，给谁提供服务，哪些地区的机器可以提供服务就需要注册中心这个组件来完成这个功能，同时注册中心它本身也是需要集群部署。

核心关键： 集群方案(主从模式,一主多从,选主)，注册中心(Zookeeper,Nacos,Redis,Eureka,Etcd)

网关服务

        什么是网关？字面意思就是网络关口，就是服务的大门，所有的用户请求都需要经过。所以大部分的服务要实现三高，必然会有一个网关层面来进行全局控制。它可以控制请求的并发量，可以做监控，也可以进行流量的分发，服务集群部署后，每个区域所支撑的量会有不同，那么流量怎么分发也需要网关层面来做。比如限流(令牌桶，漏通)，熔断等算法。

核心技术：SpringCloud-Gateway(路由，断言，过滤器)

容器化部署

        容器化，云原生等技术越来越多会被提到。因为这个技术越来越成为三高架构实现成本最低，效率最高的技术。容器化部署可以达到很高效的伸缩和扩展。当前发现服务已经满足不了并发请求之后可以动态的增加部署服务。当并发下降之后再停止这些服务。

核心技术：K8S(etcd,apiserver,kubernetes),Docker,OpenStacks

技术层面

缓存的使用

        用户请求要提高并发量，首先就是要降低请求的响应时间，最直接方案就是降低再请求过程中请求各种资源的时间消耗(前端静态资源(CDN),页面缓存,页面压缩,减少cookie传输,后端的接口数据缓存)。

负载均衡

        当我们的服务部署成集群之后，每一个区域内的请求的分布是需要可以控制的，比如正常的我们主要的机器是32G的机器，然后为了提升提高并发，不可能直接复制，在搞一台32G的机器，那么资源很浪费，这时候就需要最好能搞一台8G的作为一个缓冲，这个时候就需要通过负载均衡来保证资源利用率较高

异步处理

        有时候针对一些复杂的请求我们如果采用同步的话是肯定会有阻塞请求处理的，那么这时候如果有阻塞很容易就造成资源的竞争加剧，也会导致资源的利用率降低，倒是浪费，这时候就需要考虑使用多线程，或者使用MQ来进行异步处理。

约定处理

        微服务是多维度，多层次的，多组件的系统。那么这些组件之间的信息交互就会频繁。有时候为了减少服务之前频繁交互信息，可能会去采用约定去处理，就是大家统一遵守一套规范，当出现了一些问题之后，都按照约定的规范方案去做处理，这样既可以避免信息数据交互，同时也提升了性能。比如JSON协议，RAFT协议，ZAB协议。配置中心。外部配置化等都是以约定的方式作为解决方案。

另外可能还有一些由于分布式服务中为了确保业务的准确性，有一些技术，比如分布式锁，分布式事务等技术，虽然这些锁的使用降低了三高性能，但是在三高上面也有一定的要求。所以实现上也是有差别。

总结

以上是三高架构的一些思考，三高要求随着技术更新，三高的方案也会更新，但是思考解决方案的方向应该是不会变的。

三高架构的核心技术会网关，注册中心，监控，集群化，容器化 等会在后面的博客中介绍。

通过性能测试发现存储高可用切换问题及分析优化 | 运维进阶

【摘要】 本文介绍在有业务压力下的存储高可用切换测试，从中发现的影响切换时间的问题，以及对问题的分析。

一般情况下，我们压力测试关注的都是交易系统吞吐量、业务的响应时间，批处理系统的处理时间，但是我们很少关注某一个计算机部件的故障而导致的高可用切换过程的业务中断时间，以及切换过程中的性能表现。这其实也是我们性能测试所关注的，因为在有压力和没有压力的情况下，这个业务中断的时间是不一样的；切换过程和正常处理过程中系统性能的表现也是不一样的。

本文介绍在有业务压力下的存储高可用切换测试，从中发现的影响切换时间的问题，以及对问题的分析。

一、 存储服务器高可用的类型

存储的高可用类型很多，先来介绍一种存储的高可用类型 GAD

连接备存储也类似，但不论应用指向主存储还是备存储，先落盘的都是主存储。然而这些不是本文的关键。

二、 单台故障后会发生什么？

当主存储故障，备存储会自动切换为主存储（改变了身份），并且应用会通过多路径软件识别出主存储故障（当到达超时时间），切换到备存储。

当备存储故障，应用也会通过多路径软件识别出备存储故障，把 IO 路径切换到主存储。

三、 测试结果

下面是带着压力，存储高可用切换过程中的 CPU 利用率的图。

在主存储故障后大约 40 多秒后，似乎应用发现了主存储故障，之后切到备存储做业务，但似乎直到 3 分钟之后，业务量才完全起来，中间 40 秒 ~3 分钟的过程中，有毛刺状 CPU 。但即使是吞吐量恢复之后，仍然偶尔有吞吐量突然下降的情况。

四、 问题分析

一般来说，存储高可用的过程 40 秒就足够了，我们做了 LVM 模式高可用的测试，的确在 40 秒完成存储切换，那么：

1. 为什么 GAD 切换时间比 LVM 长？

首先从原理上讲， LVM 模式是这样的

都是主存储，一个存储坏了，只要应用自己发现了，多路径软件直接切到另一个存储就大功告成了。

而 GAD 的主存储出了故障，不但应用要把路径切换到备存储，并且，存储本身要做调整。即备存储要把自己的身份变成主存储。为什么要变身份呢？因为，在一个存储故障的情况下，写 IO 的逻辑也和平时不一样。仲裁要告诉备存储，你现在变成主了，而且是没有备机的主机。

这么一来，就会多一些时间上的耽搁。当然，这个耽搁也本不该这么长（ 2 分钟）

2. 为什么有 CPU 的毛刺， 3 分钟之后才完全恢复

这是这个 CPU 图中的疑点。明明故障发生 40 秒之后，已经在备存储上看到了有 IO 读写，并且，业务系统也开始做业务了，为什么 CPU 忽高忽低呢？业务的吞吐量也没有完全起来，直到 3 分钟以后。

那么，我们做个推理：

1） CPU 高的时候，是有业务做成功，即可以做写 IO ，而 CPU 低的时候，没有业务做成功，即不能做写 IO 。

2） 那么为什么有时候能写 IO ，有时不能写呢？

是不是因为业务系统中用到了多个 LUN ，这些 LUN 并不是同一时间在备存储启动的，而是一个一个慢慢启动的？

这个推理其实很好理解，因为，我们在 Windows 开机的时候，很早就可以看到 Windows 的桌面了，但这时候开启应用可能失败。因为 Windows 为了让用户体验更高，采用了先展示桌面，后面慢慢启动那些服务的策略。那么存储系统是不是也是这样的呢？

我们做一个小实验，把业务系统写日志的那个盘（ LV ），在建盘的时候，把它条带化（打散）到 3 个 LUN 上面。写日志时候，在 LUN1 写 4M 数据（举例），之后就切到 LUN2 上写数据，写满 4M 之后，又去 LUN3 上面写。

注：应用的逻辑是，业务完成的标志是写日志完成，如果写不了日志，这个业务就 Hang 住。

这个图就完美的验证了上面的猜想。

1. CPU 明显的忽高忽低就是业务量时而有，时而没有，对应的就是日志一会儿可以写，一会儿不能写。

2. 为什么时而不能写呢？因为写完 LUN1 ，要切换到 LUN2 上面写，而 LUN2 这时候还没有在存储层面完成主备切换，应用在下 IO 的时候，存储才意识到自己这个 LUN 应该做切换了，而且应该尽快切换（有点像催单的意思），之后 LUN2 优先完成启动，继续做业务。以此类推， LUN3 也是一样。

五、 调优

基于上述猜想，如何做调优呢？

1） 多路径软件（ HDLM ）探测存储是否活着，有一个超时时间的设置。把这个超时时间缩短，可以尽早发现存储的故障。

2） 让存储自己尽早发现自己的故障。多路径软件中有一个 HealthCheck 的选项，大概的意思是每隔多久去看一看自己的 LUN 是不是还活着。如果不活着就在另一台存储上把对应的备份激活。把这个 HealthCheck 的时间缩短，从默认的 60 分钟改为 1 分钟。那么存储在发生故障最多一分钟之后，将获得消息，并把故障的 LUN 在另一台存储上拉起。

六、 调优后的结果

完美的验证。

中断时间只有不到一分钟，恢复之后也没有出现吞吐量突然下降的情况。

七、 后续

事实上，这其实是 GAD 在某个 AIX 版本上的 bug ，但通过这样的性能测试，我们不但发现了 bug ，还通过外部的参数优化了切换的效果。

原题：性能测试中的存储高可用切换

如有任何问题，可点击文末 阅读原文 ，到社区原文下评论交流

觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到