服务端测试面试题集锦

对redis的理解

• Redis（内存数据库，高频用于缓存 / 计数）
  • 本质：基于内存的键值（Key-Value）数据库，读写速度极快（单机 TPS 可达 10 万 +），支持字符串、哈希、列表等多种数据结构，还能做分布式锁、缓存、计数器。
  • 业务场景（结合你的经验）：
    • 缓存 Win 端高频访问数据：
      比如 Win 端的 “专属配置参数”（如加密插件路径、权限列表），不用每次从 MySQL 查，缓存到 Redis 后，Win 端接口响应时间从 500ms 降到 50ms；
    • 分布式锁：
      做 “捆包自动化” 时，若多台机器同时触发捆包，可用 Redis 的SETNX（不存在则设置）实现锁，避免重复捆包；
    • 计数器：统计 Win 端版本的 “实时下载次数”，每下载一次用 Redis 的INCR命令累加，比 MySQL 的update count=count+1高效。

redis的击穿、穿透

【redis 的击穿和穿透】

• 击穿：一个高频访问的key，key过期的瞬间，对底层数据库造成了高并发的压力，这就是击穿

  • 解决方案：
    • ①redis分布式锁setex，只允许一个请求访问底层数据库。
    • ②缓存永不过期

• 穿透：用户请求一个数据，redis中没有该key，底层数据库也没有该key；那么频繁的这个空值访问就会导致缓存穿透

  • 解决方案：
    • ①缓存空值，设置过期时间 注意可能由一段时间的数据不一致的问题；
    • ②加一层布隆控制器，过滤请求参数，控制合理的请求。

• 雪崩：像淘宝双十一，这种大量数据访问，redis如果抗不住，直接就是对底层数据库的冲击。

  • 解决档案：
    • ①部分业务停服，保证主流程的通顺
    • ②数据预热，提前对可能高频访问的数据手动触发加入到缓存。

redis的测试点梳理

【redis在测试中什么地方会用到，redis的测试点除了数据一致性】
①高可用测试：redis主从切换：主节点宕机后 从节点是否切换成主节点；哨兵模式：哨兵是否能监控到主节点的宕机
②性能测试：redis-benchmark /jmeter+redis插件，单key的读写TPS；批量操作性能（MSET/MGET）;不同数据结构的性能（哈希/set）
③异常场景：缓存过期、redis内存到上限是否删除旧key
④功能正确性：内存数据库能正确存储字符串、列表、哈希、；命令正确性（使用redis-cli 或python中的redis-py库）
⑤安全性测试：密码验证，开启密码后无密码请求拒绝；命令限制比如FLUSHDB FLUSHALL避免误删。

数据一致性测试相关：

一、一个系统的数据传输链路是怎样的
①用户（web\app\pc）->②网络传输（HTTP/HTTPS，看请求头、请求体）->③API网关（如nginx,网关做路由转发、权限校验、限流等）->④应用服务层（缓存redis->底层数据库然后回写redis）
->⑤数据存储层–>⑥响应（配置服务->API网关->客户端->页面），可以抓包看响应体。
以 “用户下单” 为例，链路如下：

• 前端发起请求：APP / 网页通过 HTTP/HTTPS 发送订单信息到后端。
• 负载均衡转发：请求到 Nginx，分配到后端某一订单服务节点。
• 服务处理：订单服务校验参数（如库存），调用支付、库存等服务。
• 中间件交互：异步任务（如订单通知）发往 Kafka，热点数据写入 Redis。
• 数据库存储：订单数据写入 MySQL 完成持久化。
• 响应返回：处理结果（如 “下单成功”）沿原链路返回前端。

二、数据一致性怎么测
数据一致性常见场景（缓存与 DB / 分布式事务 / 跨系统）对应测试方法 核心是 “对比预期与实际数据”，分场景设计用例：

1. 缓存与数据库一致性
   操作后校验：更新 DB 后查缓存，确认同步；删除 DB 后确认缓存删除 / 过期。
   并发校验：100 个并发请求更新 DB 并刷新缓存，核对两者数据一致。
2. 分布式事务一致性
   场景：下单时扣减库存（库存服务）+ 创建订单（订单服务）。
   测试：正常场景下两服务数据正确；异常场景（订单成、库存未扣）验证回滚。
3. 跨系统数据一致性
   场景：电商与物流系统同步订单物流信息。
   测试：电商更新物流状态后，查物流系统确认状态、时间戳一致；模拟同步失败验证重试机制。

redis缓存命中率：

• 缓存命中次数/(缓存命中次数+缓存未命中次数)，统计指标验证业务合理性。
• 使用redis命令：info stats 查看keyspace_hits 和 keyspace_misses 计算命中率
• 【eg】模拟真实业务请求，统计不同场景下的命中率，验证是否合理
  • 模拟1000次终端数据查询，其中800次是已缓存的规则配置数据，200次是未缓存的规则外的数据
  • 执行info stats 查看hists值和misses值，计算命中率约等于80%–符合预期
  • 普罗米修斯＋grafana看板验证redis命中率，设置命中率小于70%告警。

性能调优的链路

【讲到性能瓶颈后后端进行优化、后端除了优化代码外，还可以从哪方面进行性能调优？】
①架构层：增加服务或节点。比如将不同业务分发到不同的服务上，以免高并发互相影响。—>测试拆分后的接口并发性能是否由提升
②缓存层：增加缓存或者优化缓存策略。比如历史数据版本查询慢—发现全表扫描，可以增加redis做热门业务的版本数据缓存。—看耗时从800ms将到100ms
③数据库层：索引/分库分表/SQL优化。单表数据量大->按时间分表；高频查询字段加索引；或者优化SQL语句。
④资源层：服务器CPU 升级CPU核心数；调整JVM参数如增大堆内存，避免频繁GC导致服务卡顿；监控服务器的CPU和内存使用率。
⑤网络层：减少请求次数/压缩数据。比如原来业务要调多个业务，研发改为一个聚合接口请求次数减少；比如响应体可以用Gzip压缩，可以抓包验证压缩效果。
⑥流程层：异步/限流降级。接口加限流设置，超限返回请稍后尝试–jmeter和loadrunner用过嘛

kafka

【KAFKA】

• 本质：高吞吐、高可靠的分布式消息队列，核心是 “生产者（发消息）→ Broker（存消息）→ 消费者（读消息）” 架构，支持消息持久化、分区并行处理。
• 业务场景：
  • 收集 Win 端日志：安全云 Win 端的 “进程错误日志”“捆包操作日志”，不用直接写数据库（避免高并发写压力），先发送到 Kafka，消费者再异步写入 ES（日志检索系统），你测试时可通过 Kafka 查看日志是否完整收集；
  • 异步处理耗时操作：比如 Win 端用户提交 “版本更新申请”，不用等 “更新包生成”（耗时 30 秒）完成再返回，可通过 Kafka 发消息，后端异步处理，用户端先收到 “申请已受理”，测试时需验证异步流程的最终一致性（申请后 30 秒内更新包是否生成）。

【kafka\rabbitmq\rocketmq】
都是常用的消息中间件，不过他们的设计理念和应用场景不一样

• kafka:更适用高吞吐场景，比如日志采集、大数据、实时流处理。采用分布式架构，消息存储在磁盘中，天然支持可扩展。吞吐量高，但消息延迟比rabbitmq高，消息可靠性也依赖配置，比如副本机制。
  基于顺序写磁盘和零拷贝机制，同时分布式架构让并行度高。
  消息可能丢失或重复消费：配置多副本+ACK机制，消费端做好幂等处理。
• rabbitmq:更注重可靠性，适用对可靠和一致性要求高的场景，但吞吐量比Kafka低一些。实现了AMQP协议，支持丰富的路由模式，比如直播、广播、主题路由 延迟非常低。
  实现了AMQP协议，支持可靠传递、确认机制和复杂路由，保证消息不丢失，所以适合金融场景。
  高并发场景容易堆积：增加消费者并行度，同时考虑迁移Kafka或rocketmq
• rocketmq:阿里开源的，同时兼顾高吞吐和高可靠，还支持分布式事务消息，这是Kafka和rabbitmq没有的，适合电商、交易系统需要可靠一致性 又要高并发的场景。
  支持原生的事务消息和定时消息，kafka不支持。

【kafka测试】：
核心是 数据不丢不重-高吞吐-高可用（确认业务允许少量的数据丢失）
功能测试：
①消息的发送和接收：用kafka-console-producer.sh发1000条数据，用kafka-console-consumer.sh订阅主题，验证1000条日志全量接收，无丢失、无乱码。验证数据的生产-》broker->消费
②验证消息的持久化：发100条消息后，停掉brocker重启后用消费者订阅，验证100条消息仍能正常接收（kafka将消息存在磁盘，重启不丢失
③消费分区与消费组：创建2个分区的主题，启动2个消费组（在同一分组，分区均匀分），发100条消息，验证每个消费组各消费50条；若启动3各消费组，验证1各消费者空闲

性能测试：
①TPS：kafka-producer-perf-test.sh 自带的压测工具 执行–topic safeyun --num-records 1000000 --throughput -1发100万消息不限速，验证TPS》5w/s
②消息延迟：记录生产者的发送时间t1 记录消费组的接收时间t2 计算延迟t2-t1 验证平均延迟≤100ms,若实时业务需≤50ms
高可用测试：
①broker宕机：kafka集群3各broker中停掉一个broker 生产者继续发1000条消息，验证消费组全量接收
②zookeeper宕机：停掉1各zk节点，验证卡夫卡能正常收发消息；停掉2个验证无法创建新topic 但存量topic仍能接收
可靠性测试：（数据不重不丢）
①生产者重试机制：
模拟broker临时不可用比如停10s后恢复，生产者开启重试retries=3 发100条消息，验证恢复后100条消息全接收
②消费者重复消费：（消费者offset设置、幂等性校验 比如通过唯一ID去重）
消费者消费数据开启自动提交offset，验证重启服务后，从offset+1开始消费
消费者消费数据后未提交offset 验证重启后 从第1条开始消费。
需求要求是不允许重复的话，那么消费者就需要设置自动提交offset。