随笔分类 -  测试中常见问题和场景

• 性能jmeter常用注意事项
  摘要：jmeter容易混淆的概念： 线程组并不是并发数量： 1.线程组不是并发数量，这个一定要知道，是代表用户数量。 2.100个线程组，Ramp-up时间和性能结果没有关系，这个也要清楚100以内可以设置为1秒。这个和并发数量没有关系，不要搞混淆。这个是表示多长时间内，用户集合起，例如右上角有个"10/ 阅读全文
  posted @ 2025-12-07 23:04 cherry小樱桃 阅读(15) 评论(0) 推荐(0)
• 网站运行的原理
  摘要：要明白网站的运行原理：先明白网站常用的术语： 网站常用的术语： 1.客户端：连接互联网的应用程序，比如浏览器。 2.服务器：能上网的计算机，用接受和处理请求 3.IP地址：互联网协议地址，TPC/IP网络设备的数字标识符，用于识别通信，IPv4，ipv6域名，用于标识一个或多个IP地址。 4.DNS 阅读全文
  posted @ 2025-11-18 22:31 cherry小樱桃 阅读(28) 评论(0) 推荐(0)
• 线程池的概念如何设置
  摘要：线程池的概念： 首先从理论到实践： 为什么要用线程池-到怎么用线程池： 1.为什么用？ “池”的概念：频繁创建、销毁线程开销，这种大道你无法想象。 线程是操作系统的资源，创建线程需要分配内存，初始化栈的空间，销毁线程需要回收资源，若果每次处理一个任务：new Thread(),任务执行完就销毁，在高 阅读全文
  posted @ 2025-11-17 22:56 cherry小樱桃 阅读(23) 评论(0) 推荐(0)
• 重复提交问题处理
  摘要：电商注册表单：用户连续点击导致重复注册： 问题：网络较差的时候用户重复点击，会导致重复提交注册。 token令牌：核心逻辑就每次提交给他发“一次性门票”用了就失效； 用户进入注册的时候：后端生成绑定用户设备的token（uuid）,存放在redis中（15分钟过期），前端提交的时候带着token，后 阅读全文
  posted @ 2025-11-12 00:13 cherry小樱桃 阅读(12) 评论(0) 推荐(0)
• 如何计算并发及机器
  摘要：首先要知道整个系统需要多少个线程干活： 系统总并发数计算： 线程数据=QPS*平均响应时间； 这是总资源目标，接下来我们把总的线程数分配到每台机器上。 设计单机线程池： 线程池：参数里面：分为“核心线程池”和最大线程池。两者的逻辑完全不同 1.核心线程池：设置（和cpu的核数保持一致） 核心线程池： 阅读全文
  posted @ 2025-11-11 23:39 cherry小樱桃 阅读(60) 评论(0) 推荐(0)
• mysql数据库自增ID为int类型超过范围
  摘要：mysql数据的自增加的id（int）类型，超过范围： 数据自增加ID，为int类型，超过范围，就插入数据库失败； 怎么解决？ 由于数据比较大， 1.第一个简单粗暴：把int变为（BIGINT）不用迁移数据库，但是这种会全程锁表。按照数据量评估 2.分布式ID，需要重新设计表，需要把数据迁移到新表， 阅读全文
  posted @ 2025-09-21 21:17 cherry小樱桃 阅读(15) 评论(0) 推荐(0)
• 商品搜索如何考虑
  摘要：每秒钟100万次的商品搜索，响应时间在200ms内。同时应对商品数量超过10亿。你怎么考虑 1.不能使用mysql的like： 商品数量超过10亿不能使用mysq的like，like无法触发索引“%keywords”无法利用索引，触发全表扫描，10亿数量单词查询可能耗时是：数秒。 2.不支持分词搜索 阅读全文
  posted @ 2025-09-03 21:45 cherry小樱桃 阅读(28) 评论(0) 推荐(0)
• null常见问题
  摘要：null的场景问题 用户是“null”字符串 如果：代码判断if （username==null）,抛出异常， 和代码里面username="null",是不一样的，后者是用户取名就是“null”，不是Java里面的null，不是SQL里面NULL，而是一个字符串，日志打印的时候显示：当前用户是：n 阅读全文
  posted @ 2025-09-03 21:19 cherry小樱桃 阅读(28) 评论(0) 推荐(0)
• 系统阻塞常见问题
  摘要：系统阻塞场景问题 1.前端无限制的请求 2.大文件上传，导出 3.线程池耗尽 4.内存泄漏，溢出 5.代码逻辑错误，比如死循环。 6.数据库连接池沾满 7.数据库慢查询（索引不生效，在刷脏数据） 8.下游接口无响应，但是又没有设置超时时间。 9.缓存，消息队列故障。 前端无限制的并发请求 导致线程池 阅读全文
  posted @ 2025-08-26 22:32 cherry小樱桃 阅读(30) 评论(0) 推荐(0)
• 分布是ID生成的方案
  摘要：在我们的开发过程中，都会用到分布式ID，比如：分布式锁，幂等，数据库的唯一主键，都需要分布式ID。 1.数据库的自增ID： 利用数据库的auto_increment.生成唯一ID。 优点：简单，ID有序，索引效率高。 缺点：单点故障，扩展性差（分库分表困难） 适用场景：单机或者简单的主从架构系统。 阅读全文
  posted @ 2025-08-21 22:22 cherry小樱桃 阅读(11) 评论(0) 推荐(0)
• Redis大key问题
  摘要：Redis经常因为各种大key/hot key的问题未及时处理导致服务器的性能下降： 什么是大key 大key的具体表现是：redis的key对应的value很大，占用Redis的空间比较大，本质上是大Value的问题。 1.对于String，value超过10M，（数据值太大） 2.set、lis 阅读全文
  posted @ 2025-08-20 20:45 cherry小樱桃 阅读(58) 评论(0) 推荐(0)
• 数据库查询时间飙升和CPU飙升问题
  摘要：告警中发现接口响应时间从200ms变为12秒，CPU达到90% 问题产生的原因竟然是：分页查询导致的。 这里产生的原因竟然是：MYSQ深度分页的典型问题，--数据越往后，速度越让人抓狂。 本质原因就是：传统的分页机制，在数据洪流下的失效。 limit 100000 ，10，这样的查询会让数据库像逐页 阅读全文
  posted @ 2025-08-19 20:56 cherry小樱桃 阅读(20) 评论(0) 推荐(0)
• 千万大表如何删除数据
  摘要：大表数据如何删除 思考： 1.一次行删除可能存在的问题 2.删除条件是否加索引 3.删除方案 4.删除后一些后置处理 一次性删除存在的问题 1.1锁表卡死业务： 因为删除会长时间锁表，（尤其是大事务），其他查询和写入操作被阻塞。 影响：业务接口超时，页面卡死。 删除一千万条数据，耗时间是2个小时，在 阅读全文
  posted @ 2025-08-17 21:15 cherry小樱桃 阅读(94) 评论(0) 推荐(0)
• MQ消息堆积
  摘要：问题：当消费速度跟不上服务端的发送速度的时候，消息就会堆积 问题 1：业务系统上下游的能力不匹配，造成堆积。 2.业务系统对消息的实时性要求高，短暂的堆积也无法接受。 阶段1：拉去消息： 1.客户端通过轮询从broker里面获取消息，放到本地缓存队列，这个阶段一般不会有性能问题 2.客户端把消息给业 阅读全文
  posted @ 2025-08-15 20:30 cherry小樱桃 阅读(24) 评论(0) 推荐(0)
• 排行榜的了解学习
  摘要：排行榜的思考： 遇到排行榜，大家就想到数据库的orderby 比如：微信运动 这个实现是没有问题的，如果表的数据量少的话，推荐使用 大量数据的排行榜：如果在亿级别的数据，同时很多并发的情况下，怎么办？ 使用上述的方法：磁盘扛不住，排序算不动，并发撑不起来： 当数据量较大：并且实时更新&&频繁查询的时 阅读全文
  posted @ 2025-08-14 21:32 cherry小樱桃 阅读(23) 评论(0) 推荐(0)
• 大表如何扩字段
  摘要：对于亿级别的表：如何扩字段，不是简简单单的ALTER...TABLE这么简单呢。 锁表风险，页分裂，索引性能衰减少，每一个问题都可能引发线上的事故，如何在不影响业务的情况，只是简单的配置，就可以实现字段的动态扩展？ 对于大表不能随意的加字段 在加字段过程中，锁表问题，后续随着字段的和数据的不断增多， 阅读全文
  posted @ 2025-08-13 21:21 cherry小樱桃 阅读(35) 评论(0) 推荐(0)
• 异步处理
  摘要：HTTP请求：servlet3.0之前是一个线程从头处理到尾 servlet3.0之后，提供了异步处理； 可以选择容器分配给请求的线程与相关资源，减轻系统负担，从而增加吞吐量 其实服务端的异步还是同步处理对于客户端而言是不可见的，不会因为使用了异步接口的返回就不一样了，另外对于：单个请求而言，使用异 阅读全文
  posted @ 2025-08-13 20:24 cherry小樱桃 阅读(8) 评论(0) 推荐(0)
• webSocket了解
  摘要：websocket应用场景 在实际的生活中我们经常会遇到：服务端会主动推送给客户端数据的业务场景，比如数据大屏的实时数据，比如消息中心的未读消息，比如聊天功能。 常用的服务端向客户端推送数据的实现方案，有哪几种？ 1.轮询 2.webSocket 3.SSE 轮询： 轮询的实际也是客户端向服务端发送 阅读全文
  posted @ 2025-08-13 19:58 cherry小樱桃 阅读(24) 评论(0) 推荐(0)
• 重复下单：一锁二判三更新
  摘要：后端并发问题，或者重复下单问题，可以采取：一锁二判三更新： 一锁：表示先获取锁，保证同一个时间只有一个操作能执行 二判：检查数据的状态是否符合预期，防止脏更新。 三更新：确认无误后执行更新操作。 比如：扣库存的场景： 为什么要这么做呢？ 1.两个用户同时给同一个商品下单，而商品仅剩最后一件库存，如果 阅读全文
  posted @ 2025-08-13 19:31 cherry小樱桃 阅读(46) 评论(0) 推荐(0)
• 常见SQL性能问题
  摘要：limit问题： 分页查询是常用的场景之一，但也是通常最容易出问题的地方，比如下边的SQL “select * from tab where type='1'and name ='abc' orderby created_date limit 1000,10” 但是当limit 1000变为limi 阅读全文
  posted @ 2025-08-12 21:35 cherry小樱桃 阅读(9) 评论(0) 推荐(0)