读书笔记-超时重试、回滚与压测

最新推荐文章于 2024-07-24 11:05:01 发布

6点A君

最新推荐文章于 2024-07-24 11:05:01 发布

阅读量487

点赞数

分类专栏：读书笔记文章标签：超时与重试回滚压测高并发

本文链接：https://blog.csdn.net/anla_/article/details/88372616

版权

读书笔记专栏收录该内容

13 篇文章 1 订阅

订阅专栏

超时与重试

在开发中，很多故障都是没有设置超时时间导致的，可能会导致请求慢，连锁反映，甚至是雪崩。
超时与重试可分为以下几个方面：

代理层超时与重试：入Haproxy，Nginx，Twemproxy，这些组件可实现代理功能，入Haproxy和Nginx可以实现请求的负载均衡，而Twemproxy可以实现Redis的分片代理。需要设置代理与后端真实服务器之间的网络连接/读/写。
Web容器超时：入Tomcat，Jetty等，提供Http服务运行环境，需要设置客户端与容器之间的网络连接/读/写超时事件，和在此容器默认Socket网络连接/读/写超时事件
中间件客户端超时与重试：入JSF，Dubbo，JMQ，CXF，HttpClient等，需要设置网络连接/读/写/超时与失败重试
数据库客户端超时：入MySQL，Oracle，需要分别设置JDBC Connection、Statement的网络连接与超时，事务超时事件，获取连接池等待时间。
NoSQL：如Mongo、Redis，需要设置其网络连接/读/写时间，获取连接池等待时间
业务超时：
前端Ajax超时。

超时之后应该有相应的策略来处理，常见的模式有重试（等一会再试，尝试其他分组服务，尝试其他机房服务，重试算法可考虑如使用指数退避算法）、摘掉不存活节点（负载均衡/分布式场景下）、托底（返回历史数据/静态数据/缓存数据）、等待页或者错误页。

回滚

回滚是只当程序或数据出错时，将程序或者数据恢复到最近的一个正确版本行为，常见的回滚如事务回滚、代码库回滚、部署版本回滚、数据库版本回滚、静态资源回滚

事务回滚

对于单库事务回滚直接使用相关SQL即可。
如果设计分布式数据库，则要考虑使用分布式事务，最常见的两阶段提交和三阶段提交协议，这种方式实现食物回滚难度较低，但是对性能影响较大，因为在大多数场景中需要是最终一致性，而不是强一致性。
因此，可以考虑如事物表、消息队列、补偿机制（执行/回滚）、TCC模式（预占/确认/取消）\Sagas模式（拆分食物+补偿机制）等实现最终一致性。
比如：在电商系统中，会进行扣减优惠券、预占库存等操作，这设计非常多子系统，因此，很难使用分布式食物保证强一致性，我们只能保证最终一致性即可。

部署版本回滚

部署版本化：每次部署时，应该将上一般本的包记录到部署系统中，在发布时应该采用全量发布，避免增量发布
小班本增量发布：比如修复bug，添加一些简单业务逻辑，这些我们叫做小版本。增量发布意思比如有100台服务器，先发布一台验证，如果没问题，再发发布10台，再全部。
打扮本灰度发布：页面改版、添加新功能时需要进行灰度发布，一般是两个版本并行跑一段时间，一些用户访问老版本，一些用户访问新版本，功能验证成功或者新版本不错，在全量发布。（例如可以使用带版本号的url进行区分）
架构升级并发布版本：新老版本同时存在一段事件，然后等流量增量迁移到新版本后，老版本集群就可以下线了。

静态资源回滚

在前端开发中，静态资源版本也是经常会变更的，入JS/CSS，每次变更时，生成一个全量新版本到项目的deploy目录中（如：1.3.x专门目录下），从而版本可追溯，出现问题即使回滚。
另一方面，当发布新版本后，可直接更改版本号，不需要清理CDN，不需要清理浏览器缓存。

压测

压测一般指性能压力测试，用来评估系统稳定性和性能。
压测之前要有压测方案[如压测接口、并发量、压测策略（突发、逐步加压、并发量）、压测指标（机器负载、QPS/TPS、响应时间）]，之后要产出压测报告[压测方案、机器负载、QPS/TPS、响应时间（平均、最大、最小）、成功率、相关参数（JVM参数、压缩参数）等]，最后根据压测报告分析的结果进行系统优化。

线下压测

通过JMeter、Apache ab压测系统对某个接口进行测试，或者数据库连接池测试，然后进行调优。
线下压测的环境（比如，服务器、网络、数据量等）和线上完全不一样，很难全链路压测，适合组件级压测，数据只能作为参考。

线上压测

按不同维度，测试也不同，按读写维度，有读压测，写压测，混合压测。
按数据仿真度可分为：仿真压测和引流压测

在实际压测时，应该进行全链路压测，因为可能存在一个非核心系统服务调用问题，造成整个交易链路出现问题，或者链路中的各个系统存在竞争资源情况，而导致一些不可余件bug。

系统优化和容灾

在有了压测报告后，需要对压测报告进行分析，并进行针对性改变，例如硬件升级、系统扩容、参数调优、代码优化（同步改异步）等。

应急预案

在系统压测后，会发现一些系统瓶颈，在系统优化之后会提升系统吞吐量，并降低相应时间，容灾之后系统可用性得以保障，但是还会存在一些风险，例如网络抖动、某台机器负载过高、某个服务变慢、数据库load值过高等，为了防止因为这些问题而出现系统雪崩，需要针对这些情况指定应急预案，从而在突发情况时，有相应措施来解决。
可以进行以下几步：进行系统升级，然后进行全链路分析，配置监控报警，最后指定应急预案。