（二）redis怎么测试

一、redis是什么？

redis 是一个key-value类型的高速存储数据库

redis常被用做 缓存 队列 发布 订阅等

二、redis怎么测试其实就是缓存怎么测试？

2.1 缓存的分类

文件缓存  数据库缓存  内存缓存 浏览器缓存

场景1：用户->访问浏览器页面->读取缓存文件

  • 【浏览器缓存】css js等资源文件下载一次后缓存一段时间，直到缓存失败或请求明确告知需要更新
  • 【文件缓存】后台编辑的文章和分类页面，更新缓存立即生成多个文件，前台访问的都是缓存文件，加快访问速度，减少服务器和数据库压力，通过后端语言直接渲染smarty等模板渲染方式输出界面的 一般会选文件类型缓存

场景2：用户->访问浏览器页面->加载前端资源->调用后端接口->读取缓存

  • 【数据库缓存】前后端分离，对后端接口响应时间要求更高，这时候使用数据库缓存，常用redis和memcached，都属于分布式key-value高速缓存系统

场景3：用户->访问浏览器页面->加载前端资源->调用后端接口->读取内存缓存->读取redis缓存->读取db数据

  • 【内存缓存】内存缓存比数据库缓存更快，但是内存有限易出现内存泄露问题，且技术栈有限，实际使用中，java会把高频数据塞到内存缓存中作为一级缓存，次高频放redis做二级缓存，最后才从db中去查询数据

2.2 缓存的作用

(快) 加快访问速度，从内存取出很快

(省) 节省数据处理流程和服务器的资源消耗，减少服务器和db压力

2.3缓存的使用场景

  • 用在什么地方
    • 缓存、数据共享分布式、分布式锁、全局 ID、计数器、限流、购物车、消息队列、抽奖、点赞、签到、打卡、排行榜、电商销售排行等场景。
  • 什么时候使用
    • qps较高、对RT响应速度有要求、服务器性能差、db性能较差——用来提升性能

场景1  微信我的状态：app中有缓存 调用app缓存，否则调用接口，接口调用内存缓存 ，不在内存缓存则读取redis缓存，再没有再查询数据库

 

场景2 服务器、db压力不大的不需要使用缓存

小型电商的商品管理后台列表页面，访问人数不多，sku改动频次很低，可能3天才被访问几十次。
这种场景一不需要使用缓存，二在商品信息被更新之后需要立即看到更新后的数据，不适合使用缓存，所以不建议使用缓存。

同样的电商管理后台，这次是一个统计页面，统计昨天/今天/近一周的商品销售情况。
这个场景可以分情况来看，有多种不同的解决方案。
（我们抛开大数据统计的各类技术方案，简单实现一个系统的统计功能）
a. 不需要实时统计，只需要定时统计一次即可，比如只看昨天一天统计数据：可以由定时脚本统计之后直接存储在db，需要查看统计数据时直接查询db即可
b. 需要查询实时统计数据，但需要查询的各个统计sql执行效率满足预期：每次查看数据直接查询db即可，此时db压力不大

2.4 缓存的生成方式

这是一个典型的MVC，由Controller接收和处理请求数据，由Service处理Model中获取的数据，再由View输出。

【外缓存】接口过滤，缓存有效时间设置短

针对请求参数多变，返回的数据如果跟请求参数强相关，适合在 请求参数过滤 之后，缓存查询到的数据。

这类数据一般缓存时间短，比如缓存5分钟。主要应对相同请求参数在短时间内的重复请求。

如果遇到请求攻击，即使这个缓存有效期只有1秒，也是很有效的，能挡住大量的请求。

 

 

 

【内缓存】 缓存有效时间可设置很长

针对请求参数变化不大, 返回的数据跟db中存储的数据很接近的情况, 适合在“里面”缓存数据, 也就是在更新db的同时更新缓存, 这种情况最优的状态下, 只需要读缓存就够了, 不需要跟db直接交互, 能大大缓解db压力。

 

 

 获取和过滤请求参数这边异步代码处理多用户处理需要加互斥锁 否则会出现数据覆盖

2.5 缓存的更新方式

  1. 过期后自动更新：这是最懒的更新方式。通过设置缓存有效期，让缓存失效后通过新的请求自动创建新的缓存。
  2. 删除缓存：在更新db数据后，直接删除缓存，通过新的请求自动创建新的缓存。
  3. 重新设置缓存：在更新db数据后，直接重新设置缓存。

三、如何测试Redis缓存，redis缓存的测试点

我们在测试 Redis 缓存时，测试思路跟测试业务功能类似，主要从评审、测试、监控三个方面来进行设计。

 

下面是一些思路。

3.1 评审设计的合理性

  • 确认缓存的应用场景：

    • 评估业务场景 是否 真的需要 使用 缓存；

    • 评估 Redis 与 DB 数据短暂 不一致 对业务的影响。

  • 规范键值对的设计：

    • key：

      • 一般使用业务名或数据库名作为前缀，以冒号(:)分隔来构造 key 名，不使用含义不清的 key 或特别长的 key；

      • 命名中只能出现小写字母、数字、点(.)和冒号(:)。不要包含特殊字符，如下划线、空格、换行、单双引号以及其他转义字符；

    • value：

      • 禁止超过 10KB 的 String 类型的大 key，防止网卡流量、慢查询。

      • 非 String 类型的大 key，不要使用 del 删除，要使用 hscan、sscan、zscan 方式渐进删除。

  • 选择合适的缓存模式：

    • 旁路缓存模式/读写穿透模式/异步缓存写入

  • 确认缓存的更新策略：

    • 1. 先更新数据库，再更新缓存；

    • 2. 先更新缓存，再更新数据库；

    • 3. 先淘汰缓存，再更新数据库；

    • 4. 先更新数据库，再淘汰缓存。（推荐）

  • 确认缓存的过期机制：

    • 主动的定期删除/被动的惰性删除

  • 是否有缓存预热机制：

    • 数据量不大的时候可以不进行缓存预热，或者可以在项目启动的时候自动进行加载。

    • 数据量很大的时候，一定要保证热点数据提前加载到缓存。

  • 确认缓存的淘汰策略：

    • 淘汰最久没有使用的数据：LRU（Least Recently Used）

    • 淘汰最不频繁使用的数据：LFU（Least Frequently Used）

    • 淘汰最先放入缓存的数据：FIFO (first in first out)

  • 评估业务所需缓存空间大小

  • 缓存时间设置合理性：

    • 缓存时间太长会导致用户访问到的数据一直是老的，缓存设置时间太短对数据库访问会比较频繁，所以要设置合理，最好清楚实际数据更新的频次后再设置。

 

3.2 校验缓存的正确性

验证基本功能

  • 缓存增加：

    • 增加缓存，校验功能和数据是否正确，DB 中的数据跟 Redis 是否一致，缓存过期时间与设计是否一致；

  • 缓存更新：

    • 更新缓存，校验功能和数据是否正确，DB 中的数据跟 Redis 是否一致；缓存过期时间与设计是否一致；

    • 对同一条数据并发执行更新和查询操作，校验功能和数据是否正确，DB 中的数据跟 Redis 是否一致；缓存过期时间与设计是否一致；

  • 缓存删除：

    • 删除缓存，校验功能和数据是否正确，再次请求，缓存是否被正确写入，DB 中的数据跟 Redis 是否一致；

  • 缓存过期：

    • 设置 Redis 过期时间，校验缓存是否正常过期失效。再次写入缓存，缓存过期时间被更新。（可通过修改服务器时间或手动修改缓存的 TTL）

  • 缓存读取：

    • 校验数据在缓存和 DB 中都存在时，系统功能是否正常；

    • 校验数据在 DB 存在，但缓存中不存在时，系统功能是否正常；

    • 校验数据在缓存和 DB 中都不存在时，系统功能是否正常；

    • 验证 DB 返回的数据异常时，没有去缓存；

验证特殊场景

  • 缓存超时：

    • 校验缓存查询达到超时时间后，未返回指定的数据，对系统的影响。

  • 缓存穿透：

    • 不断查询一个 DB 和缓存中一定不存在的数据，验证返回数据为空。

  • 缓存雪崩：

    • 校验缓存是否采用了相同的过期时间。如果缓存大指量同时失效，验证系统功能是否正常，性能指标是否正常。

  • 缓存击穿：

    • 缓存中的数据没有人查询过 ，第一次就大并发的访问；

    • 缓存中的某条数据刚好失效后，就进行大并发访问，校验功能是否正常，各项性能指标是否正常。

  • 缓存预热：

    • 大批量缓存在同一时间点过期，验证缓存预热耗时及预热时机。

    • 在缓存预热期间请求更新接口和查询接口，验证返回数据的正确性。

  • 缓存上限：

    • 校验缓存淘汰参数配置与预期一致：增加缓存至达到 maxmemory 限制时（可修改 redis.conf 配置文件中配置的最大可用内存值），再次请求查询，数据返回正确，且缓存淘汰正确。

  • 缓存停服：

    • 校验关闭缓存服务后，系统功能和性能的运行情况。

    • 验证重启 Redis 服务后，请求查询返回的数据正确，DB 中的数据跟 Redis 一致。

  • 测试并发：

    • 并发请求缓存中有的数据，校验返回数据是否正确，各项性能指标是否正常。

    • 并发请求缓存中没有但 DB 中有的数据，校验返回数据是否正确，各项性能指标是否正常。

    • 并发请求缓存中没有 DB 中也没有的数据，校验返回数据是否为空，各项性能指标是否正常。

  • 性能测试：一般用 redis-benchmark 测试一些场景的性能基准，比如：

    • 对比单机和集群 Redis 吞吐量；

    • 评估不同类型的存储性能；

    • 对比开启和关闭持久化的吞吐量；

    • 对比调优前后的吞吐量；

    • 对比不同版本的 Redis 的吞吐量；

3.3监控线上的稳定性

  • 监控缓存的命中率：评估缓存的设计是否达到预期；

  • 监控中间件：CPU、内存是否异常；

  • 监控是否有某个 key 过大；

  • 监控是否存在缓存的频繁更新。

 

思维导图如下所示：

 

 

 

四、Redis 管理工具有哪些？

为了更好的测试 Redis，我们需要一些好用的管理工具，下面推荐 4 款免费开源的。

4.1 AnotherRedisDesktopManager

Another Redis Desktop Manager 是一款非常好用的 Redis 可视化管理工具，开源免费，兼容 Windows、macOS 和 Linux，性能出众。

开源地址：https://github.com/qishibo/AnotherRedisDesktopManager/

 

 

4.2 QuickRedis

QuickRedis 是也是一款非常好用的 Redis 可视化管理工具。开源免费，兼容 Windows、macOS 和 Linux。它支持直连、哨兵、集群模式，支持亿万数量级的 key。

开源地址：https://github.com/quick123official/quick_redis_blog

 

 

4.3 IRedis

IRedis 是一个支持自动补全和语法高亮 的 Redis 命令行工具，可用来替代 redis-cli。使用 IRedis 可以流畅地输入 Redis 命令，显示结果也非常友好。

开源地址：https://github.com/laixintao/iredis

 

 

4.4 Redis Commander

Redis Commander 是一款用 node.js 编写的 Redis 网页管理工具。

开源地址：https://github.com/joeferner/redis-commander

 

 

 

 

posted @ 2022-09-27 21:09  陈晓猛  阅读(1863)  评论(0)  编辑  收藏  举报