常见技术类缺陷及解决方案

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
简介: 常见技术类缺陷及解决方案

好久没写技术类的文章了,整理下最近发现的一些非功能需求类的缺陷及对应的解决方案,仅供参考,技术类的缺陷与技术架构是强相关的,切勿生搬硬套。


01


第一类:接口超时问题。


不论是通过F12分析页面请求,还是查看Skywalking做链路分析,经常会发现接口超时的问题。简单地调用流程图如下:



 

针对这类问题,需要区分不同的业务诉求来做处理,主要分成两类。


源系统对结果实时性要求高的,可以做以下优化手段:

  1. 目标系统要做分页请求拦截,每页在10~200条之间;
  2. 目标系统尽可能避免多层循环嵌套,在循环中避免对数据库批量请求操作;
  3. 目标系统尽可能采用一些缓存机制来确保业务逻辑加速处理;

 

源系统对结果实时性要求低的,可以做以下优化手段:

  1. 通过MQ消息队列进行解耦处理;
  2. 采用异步机制来提升接口的性能和MQ的吞吐量


02


第二类:数据库死锁问题。


在多并发的情况下,由于锁的使用不当,或者事务过大,都会造成数据库锁的问题,进而引发性能问题,常见的大事务引发的问题如:


 

如何定位数据库是否有死锁,如果是Mysql数据库,可通过“show engine innodb status" SQL来查看(需要较大的数据库权限),如果出现如下信息,则说明有锁存在,具体的分析过程请自行查阅相关资料。


解决方案通常有两种:利用好Spring的事务传播机制,共7种,了解它们的使用场景及用法,全局自动提交/回滚事务。

 

另一种是利用java finally块代码执行机制,在代码异常块中手动回滚事务,要注意必须在finally中作处理,如下图;



03


第三类:数据丢失问题。


数据丢失或者变异通常发生在异步处理的场景中,同步场景中几乎不会发生,简单的调用关系如下:



主要有三类情况会发生数据丢失的问题。


源系统调用接口或发送消息时数据丢失,造成这类问题的原因,包含但不限于以下情况:

(1)MQ服务器磁盘空间不足、宕机等;

(2)断网、网络波动等;


常用的解决方案(适用于断网、网络波动、目标系统服务异常时的场景):

(1)源系统调用接口或发送消息时,记录日志到ELK--以后排查问题的时候用

(2)源系统接口调用/发送失败时消息时:如果首次执行失败,每隔10s,再次调用/发送,直到调用/发送成功;连续3次调用/发送失败,将接口调用/发送消息存入本地消息表,通过定时任务补偿机制,在业务空闲时重试;重试执行成功后,维护更新本地消息表中执行状态或清除本地消息表中的数据;

 

数据传输过程中数据丢失造成这类问题的原因,包含但不限于以下情况:

(1)单次调用接口请求/发送消息 数据量过大;

(2)MQ服务器磁盘空间不足、宕机等;

(3)断网、网络波动等;

(4)黑客、软件劫持网络;

上述 2、3、4 为小概率事件,一般情况,主要精力还是投放在程序代码上面。


常用的解决方案:

(1)请求数据分页,每页不超过200条(网络、服务器较差的环境,分页需要拆的更小);

(2)对MQ服务器进行监控;

(3)通过架设高可用的网络,来提高网络质量;

(4)防火墙、WAF等安全设备;

 

目标系统接收到数据,处理过程中丢失数据(重点关注)造成这类问题的原因,包含但不限于以下情况:

(1)目标系统接收数据后急于直接进行业务逻辑处理;

(2)目标系统大事务;

(3)目标系统数据库死锁;

(4)目标系统接口性能问题;

……


常用的解决方案

(1)目标系统收到数据后,记录日志到ELK--以后排查问题的时用

(2)目标系统收到数据后:第一步:将数据落入本地消息表;第二步:然后直接返回源系统已收到数据的请求;第三步:异步处理收到的数据;第四步:调用源系统补偿机制接口告诉数据处理结果;--需要源系统配合提供补偿机制接口,第五步:异步维护本地消息表中的数据处理状态


04


第四类:数据重复问题。


在高并发或者用户快速点击页面的情况下,有时候会造成数据的重复提交,特别是在新增事务的场景中,比如基础数据重复提交、订单重复提交、扫描枪快速多次扫描上报数据等。

 

解决这类问题,可参考秒杀系统设计原理,作如下处理:

1、按钮置灰,禁止用户重复提交请求;

2、TF技术:通过JS在一定时间内只能提交一次请求;

3、Redis标志位策略:首次请求时,在Redis中创建一个标志位,然后执行业务代码;

再次请求时,到Redis上查看这个标志位是否存在,如果存在,拒绝请求;如果业务代码执行完毕,删除Redis中的标志位;

4、 关注接口的幂等性验证测试;


05


相对于功能测试,技术类的缺陷需要测试人员关注业务的技术实现,因为这些问题比较难直观地反馈到页面上,但是出了问题,影响范围又相对会比较广。所以需要测试人员具备一定的技术视野,去了解研发实现,从技术层面提出相对应的测试策略,提升自己的价值。

 

你,平时会注意到这些问题吗?

 

PS:因为涉及保密问题,所以本文所提到的场景均没有给出案例,但思路和解决方案都是可落地的,仅供参考。


共勉。


相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
4月前
|
测试技术 UED
质量标准化实践问题之测试策略的本质如何解决
质量标准化实践问题之测试策略的本质如何解决
29 2
|
5月前
软件复用问题之如果无法进行定量分析,评估系统的复用性要如何解决
软件复用问题之如果无法进行定量分析,评估系统的复用性要如何解决
|
7月前
|
安全 数据管理 测试技术
网络安全与信息安全:防范漏洞、加强加密与提升安全意识深入探索自动化测试框架的设计原则与实践应用化测试解决方案。文章不仅涵盖了框架选择的标准,还详细阐述了如何根据项目需求定制测试流程,以及如何利用持续集成工具实现测试的自动触发和结果反馈。最后,文中还将讨论测试数据管理、测试用例优化及团队协作等关键问题,为读者提供全面的自动化测试框架设计与实施指南。
【5月更文挑战第27天】 在数字化时代,网络安全与信息安全已成为维护国家安全、企业利益和个人隐私的重要环节。本文旨在分享关于网络安全漏洞的识别与防范、加密技术的应用以及提升安全意识的重要性。通过对这些方面的深入探讨,我们希望能为读者提供一些实用的建议和策略,以应对日益严峻的网络安全挑战。 【5月更文挑战第27天】 在软件开发周期中,自动化测试作为保障软件质量的关键步骤,其重要性日益凸显。本文旨在剖析自动化测试框架设计的核心原则,并结合具体案例探讨其在实际应用中的执行策略。通过对比分析不同测试框架的优缺点,我们提出一套高效、可扩展且易于维护的自动
|
7月前
|
程序员 测试技术
程序员难以一次性写好代码并持续修复Bug,主要源于软件的高复杂性、需求不确定性、测试局限性和技术能力限制。
【5月更文挑战第11天】程序员难以一次性写好代码并持续修复Bug,主要源于软件的高复杂性、需求不确定性、测试局限性和技术能力限制。复杂的系统易产生意外问题,需求变化导致初始设计难完备,测试无法覆盖所有情况,而技术更新和个体能力差异也会引入错误。因此,持续调试和优化是保证软件质量的关键步骤。
73 0
|
7月前
|
项目管理 数据库
简述软件质量的概念及质量保障体系,简述SQA的基本目标,简述CMM的分级结构及其主要特征,简述软件质量标准等级及适用范围
简述软件质量的概念及质量保障体系,简述SQA的基本目标,简述CMM的分级结构及其主要特征,简述软件质量标准等级及适用范围
239 0
|
JavaScript 前端开发 架构师
大型网站重构指南 第1部分:定目标、代码评估
大型网站重构指南 第1部分:定目标、代码评估
578 0
|
设计模式
重构·改善既有代码的设计.03之重构手法(上)
之前的重构系列中,介绍了书中提到的重构基础,以及识别代码的坏味道。今天继续第三更,讲述那些重构手法(上)。看看哪些手法对你的项目能有所帮助......
19266 1
重构·改善既有代码的设计.03之重构手法(上)
|
设计模式 IDE Java
【Java设计模式 规范与重构】 四 小型重构的手段:规范的十五条军规
【Java设计模式 规范与重构】 四 小型重构的手段:规范的十五条军规
137 0
|
设计模式 测试技术
「业务架构」需求工程——捕获与分析(第二部分)
「业务架构」需求工程——捕获与分析(第二部分)