消息队列测试场景和redis测试场景

在这里插入图片描述


一、消息队列测试场景

1、什么是消息队列。你是怎么测试的?

解题思路:
什么是消息队列。
消息队列应用场景。
消息队列测试点列举。

2、什么是消息队列

Broker:消息服务器,提供消息核心服务
Producer:消息生产者,业务的发起方,负责生产消息传输给 broker。
Consumer:消息消费者,业务的处理方,负责从 broker 获取消息并进行业务逻辑处理。

在这里插入图片描述

3、消息队列的应用场景

异步通信
流量削峰
应用解耦
负载均衡
数据同步

4、消息队列的测试点

所属类型 注意点 测试点
生产者 时序 不同时序推送消息,先后顺序是否和预期一致
数据正确性 内容是否完整
内容是否满足需求
推送 推送失败是否有重试
消费者 正确性 正常消费信息
消息被消费后是否清除
消费者接收到的信息和生产者一致
消费者堵塞,如何处理
幂等(接收到重复消息)

二、redis测试场景

1、Redis 简介

读写性能优异。
数据类型丰富。
Redis 支持数据的备份。
数据自动过期。
发布订阅。
分布式。

2、Redis 的应用场景

读多写少,并发强的场景。(秒杀、微博热搜)
有时间性的业务场景。(短信验证码)
对有序集合数据类型排序。 (排行榜)
对于时效性要求不高。(计数器)
Session 会话缓存。
消息系统。
单线程的特点可以天然用作分布式锁。

3、后端服务和数据库的交互过程(无redis)

在这里插入图片描述

4、后端服务和数据库的交互过程(redis)

在这里插入图片描述

4、Redis 的测试场景与面试题

a、你们的 Redis 使用的是淘汰缓存还是更新缓存,这两者有什么区别?请详细说明。

解题思路:
前提条件:了解缓存的读写流程。

缓存操作流程-读

扫描二维码关注公众号,回复: 15194304 查看本文章

缓存中有数据。
缓存中没有数据。

在这里插入图片描述

缓存操作流程-写(淘汰缓存)

优点: 操作简单,性能比较好。
缺点:至少会出现一个 cache miss。(当大量的请求访问数据库时,数据库压力很很大)

在这里插入图片描述

缓存操作流程-写(更新缓存)

优点: 基本不会出现cache miss的情况。
缺点: 每次更新数据库都更新缓存,比较影响性能。

在这里插入图片描述

淘汰缓存与更新缓存区别
淘汰缓存:性能较好,至少会出现一个 cache miss(用的多)
更新缓存:性能较差,基本不会出现cache miss

b、Redis 缓存失效问题:怎么定位 Redis 缓存失效问题(缓存坏了)?以及如何解决缓存失效问题?

解题思路:
缓存失效是什么?
缓存不可用之后,大量并发到数据库。

在这里插入图片描述

缓存失效的原因是什么?
缓存过期。
Redis 异常。
网络异常。
缓存更新

在这里插入图片描述

缓存失效研发应该如何处理,测试如何测试?
降级: 禁用部分接口,开放核心接口。
熔断: 禁用部分服务,开放核心服务。

缓存失效相关测试方法

梳理系统中的核心服务列表(通常直接让研发给出对应列表)。
梳理服务中核心接口列表(通常直接让研发给出对应列表)。
模拟 Redis 失效,验证核心服务和核心接口是否还能正常运行。

c、Redis 击穿、穿透区别

Redis 击穿、穿透区别,如何设计用例以及完成测试?

解题思路:
击穿的概念,如何设计测试用例。
穿透的概念,如何设计测试用例。

在这里插入图片描述
击穿的场景的测试用例步骤
获取热 key 的列表(与运维沟通后获取)。
模拟热 key 失效的场景(比如登陆 Redis,直接将热 key 删除)。
查看研发是否有对应的容错机制,保证服务正常运行。

在这里插入图片描述
在这里插入图片描述
穿透的场景的测试用例步骤
不停访问对应服务的接口,传递一个不存在的数据的查询请求。
查看研发是否有对应的容错机制,保证服务正常运行。

击穿与穿透总结

类型 穿透 击穿
测试目标 查看研发是否有对应的容错机制,保证服务正常运行。 查看研发是否有对应的容错机制,保证服务正常运行。
测试方法 不停访问对应服务的接口,传递一个不存在的数据的查询请求。 模拟热 key 失效的场景(比如登陆 Redis,直接将热 key 删除)。

猜你喜欢

转载自blog.csdn.net/YZL40514131/article/details/130610167