Redis 测试的关键要点涵盖功能正确性、性能稳定性、高可用可靠性及数据安全性四大维度，需覆盖单机、主从、哨兵、集群等部署形态。性能优化方面，应选择合适数据结构，避免 BigKey，使用 Pipeline 批量操作，合理设置过期策略及内存淘汰机制。保证数据一致性需依赖持久化策略（RDB/AOF）、事务机制（MULTI/EXEC）、Lua 脚本原子性操作以及合理的客户端重试与补偿机制，同时警惕慢查询与网络延迟影响，确保在高并发场景下数据不丢失且服务可用。
Redis 的测试要点和测试方法
Redis 测试核心是验证功能正确性、性能稳定性、高可用可靠性、数据安全性四大维度，覆盖单机、主从、哨兵、集群等部署形态。以下是完整测试要点、方法与工具指南。一、功能测试 (核心基础) 目标：确保所有命令、数据结构、特性符合预期，无逻辑错误。1. 基础数据结构操作 字符串 (String):SET/GET/SETEX/INCR/DEL 等，验证值读写、过期、计数。哈希 (Hash):HSET/HGET/HMSET/HDEL/HKEYS 等，验证字段增删改查。列表 (List):LPUSH/RPUSH/LPOP/RPOP/LRANGE 等，验证队列 / 栈行为。集合 (Set):SADD/SMEMBERS/SREM/SINTER 等，验证去重、交集、并集。有序集合 (ZSet):ZADD/ZRANGE/ZREM/ZRANK 等，验证排序与分数计算。位图 (Bitmap)、地理 (GEO)、流 (Stream):专项命令验证。2. 高级特性 事务:MULTI/EXEC/DISCARD/WATCH，验证原子性与回滚。发布订阅:PUBLISH/SUBSCRIBE，验证消息实时可达。过期键:SETEX/PEXPIRE/TTL，验证到期自动删除、惰性 / 定期清理。Lua 脚本:SCRIPT LOAD/EVAL，验证脚本执行与原子性。管道 (Pipeline):批量命令合并发送，验证吞吐量与结果正确性。3. 测试方法 手工验证:redis-cli 直接执行命令，比对返回值。单元/ 集成测试:python 运行 # pytest+redis-py 示例 deftest_hset_hget(redis_client): redis_client.hset("user:1", mapping={"name":"Bob","age":20}) assert redis_client.hget("user:1","name")==b"Bob" assert int(redis_client.hget("user:1","age"))==20 一键获取完整项目代码 二、性能测试 (高并发压测) 目标：评估 QPS、延迟、并发、内存、带宽，定位瓶颈。1. 关键指标 吞吐量:QPS(每秒请求数) 延迟:Avg/P50/P95/P99 响应时间 资源:CPU、内存、网络 I/O、连接数 命中率：缓存 key 命中率 (info stats) 2.测试工具与方法 官方基准 (redis-benchmark) bash 运行 #100 并发、10 万请求、SET/GET、1KB 值、随机 key redis-benchmark -h127.0.0.1-p6379-c100-n100000-tset,get-d1024-r10000-q 一键获取完整项目代码 参数:-c 并发、-n 总请求、-t 命令、-d 字节、-r 随机 key、-P 管道 压测工具 JMeter:装 Redis 插件，模拟业务并发、监控聚合报告 memtier_benchmark:更真实流量、多命令混合、集群压测 Locust:Python 分布式压测，自定义业务场景 3. 专项场景 大 Key 测试:>1MB 值，验证读写延迟与带宽占用 热点 Key:单 key 超高并发，验证热点竞争与性能衰减 持久化开启:RDB/AOF 时性能影响
《吐血整理》Redis 性能优化的 13 条军规！史上最全
Redis 是基于单线程模型实现的，也就是 Redis 是使用一个线程来处理所有的客户端请求的，尽管 Redis 使用了非阻塞式 IO，并且对各种命令都做了优化 (大部分命令操作时间复杂度都是 O(1)),但由于 Redis 是单线程执行的特点，因此它对性能的要求更加苛刻，本文我们将通过一些优化手段，让 Redis 更加高效的运行。本文我们将使用以下手段，来提升 Redis 的运行速度：缩短键值对的存储长度;使用 lazy free(延迟删除) 特性;设置键值的过期时间;禁用长耗时的查询命令;使用 slowlog 优化耗时命令;使用 Pipeline 批量操作数据;避免大量数据同时失效;客户端使用优化;使用物理机而非虚拟机安装 Redis 服务;检查数据持久化策略;禁用 THP 特性;1.缩短键值对的存储长度 键值对的长度是和性能成反比的，比如我们来做一组写入数据的性能测试，执行结果如下：从以上数据可以看出，在 key 不变的情况下，value 值越大操作效率越慢，因为 Redis 对于同一种数据类型会使用不同的内部编码进行存储，比如字符串的内部编码就有三种:int(整数编码)、raw(优化内存分配的字符串编码)、embstr(动态字符串编码),这是因为 Redis 的作者是想通过不同编码实现效率和空间的平衡，然而数据量越大使用的内部编码就越复杂，而越是复杂的内部编码存储的性能就越低。这还只是写入时的速度，当键值对内容较大时，还会带来另外几个问题：内容越大需要的持久化时间就越长，需要挂起的时间越长，Redis 的性能就会越低;内容越大在网络上传输的内容就越多，需要的时间就越长，整体的运行速度就越低;内容越大占用的内存就越多，就会更频繁的触发内存淘汰机制，从而给 Redis 带来了更多的运行负担。因此在保证完整语义的同时，我们要尽量的缩短键值对的存储长度，必要时要对数据进行序列化和压缩再存储，以 Java 为例，序列化我们可以使用 protostuff 或 kryo，压缩我们可以使用 snappy。2.使用 lazy free 特性 lazy free 特性是 Redis 4.0 新增的一个非常使用的功能，它可以理解为惰性删除或延迟删除。意思是在删除的时候提供异步延时释放键值的功能，把键值释放操作放在 BIO(Background I/O) 单独的子线程处理中，以减少删除删除对 Redis 主线程的阻塞，可以有效地避免删除 big key 时带来的性能和可用性问题。
面试必备：一线大厂 Redis 设计规范与性能优化
一、Redis Key-Value 设计规范&性能优化 1. key 名设计规范 (1)【建议】: 可读性和可管理性 以业务名 (或数据库名) 为前缀 (防止 key 冲突),用冒号分隔，比如业务名：表名:id (2)【建议】:简洁性 保证语义的前提下，控制 key 的长度，当 key 较多时，内存占用也不容忽视，例如：(3)【强制】:不要包含特殊字符 反例：包含空格、换行、单双引号以及其他转义字符 2. Value 设计规范 (1)【强制】:拒绝 bigkey(防止网卡流量、慢查询) 在 Redis 中，一个字符串最大 512MB，一个二级数据结构 (例如 hash、list、set、zset) 可以存储大约 40 亿个 (2^32-1) 个元素，但实际中如果下面两种情况，我就会认为它是 bigkey。字符串类型：它的 big 体现在单个 value 值很大，一般认为超过 10KB 就是 bigkey。非字符串类型：哈希、列表、集合、有序集合，它们的 big 体现在元素个数太多。一般来说，string 类型控制在 10KB 以内;hash、list、set、zset 元素个数不要超过 5000。反例：一个包含 200 万个元素的 list。3. bigkey 性能优化 bigkey 的危害：导致 redis 阻塞 网络拥塞 bigkey 也就意味着每次获取要产生的网络流量较大;假设一个 bigkey 为 1MB，客户端每秒访问量为 1000，那么每秒产生 1000MB 的流量，对于普通的千兆网卡 (按照字节算是 128MB/s) 的服务器来说简直是灭顶之灾，而且一般服务器会采用单机多实例的方式来部署，也就是说一个 bigkey 可能会对其他实例也造成影响，其后果不堪设想。过期删除 有个 bigkey，它安分守己 (只执行简单的命令，例如 hget、lpop、zscore 等),但它设置了过期时间，当它过期后，会被删除，如果没有使用 Redis 4.0 的过期异步删除 (lazyfree-lazy- expire yes),就会存在阻塞 Redis 的可能性。bigkey 的产生：一般来说，bigkey 的产生都是由于程序设计不当，或者对于数据规模预料不清楚造成的，来看几个例子：社交类：粉丝列表，如果某些明星或者大 v 不精心设计下，必是 bigkey。统计类：例如按天存储某项功能或者网站的用户集合，除非没几个人用，否则必是 bigkey。缓存类：将数据从数据库 load 出来序列化放到 Redis 里，这个方式非常常用，但有两个地方需要注意，第一，是不是有必要把所有字段都缓存;第二，有没有相关关联的数据，有的同学为了图方便把相关数据都存一个 key 下，产生 bigkey。
分布式缓存服务 Redis
(一) 优化网络延时 Redis 客户端和服务器的通讯一般使用 TCP 长链接，这会导致客户端在发送请求后需要等待 Redis 返回结果再发送下一个指令，从而产生网络传输时间。为了优化网络延时，可以使用多种方法。如果是单机部署，可以使用 Unix 进程间通信。对于 multi-key 指令，可以将多个请求合并为一个，例如两个 GET key 可以用 MGET key1 key2 合并，减少请求数，降低延时。MULTI/EXEC 和 script 方法可以将多个指令合并为一个具有原子性的执行过程，减少网络传输时间，但要求涉及的 key 在同一个 node 上。pipeline 可以合并多个 responses，减少回复所用的网络传输时间，但不具有原子性，在 cluster 集群上更有可能实现。(二) 警惕执行时间长的操作 在大数据量的情况下，应避免使用复杂度过高的命令，如 KEYS *、LRANGE 等，这些命令的算法复杂度为 O (n),执行时间相对较长 (华为云禁用指令，详情请参考文档 Redis 5.0 支持及禁用的命令_分布式缓存服务 DCS_华为云)。transaction 和 script 虽然可以合并多个 commands 为一个具有原子性的执行过程，但也可能占用 Redis 很长时间，需要注意。可以使用 SLOWLOG GET count 查找慢指令，通过在 redis.conf 中设置 slowlog-log-slower-than 来定义多长时间算长。对于慢指令 DEL，可以使用异步版本 UNLINK 替代，后者会启动一个新的 thread 来删除目标 key，不阻塞原来的线程。此外，要警惕 EXPIREAT 指令，因为它更容易产生 keys 同时过期的现象，可以给 keys 的过期时间设置一个随机波动量，或者在 redis.conf 中设置 lazyfree-lazy-expire yes，将 keys 的过期删除操作变为异步。(三) 避免操作 bigkey Redis bigkey 即数据量大的 Key，容易造成内存不均、超时阻塞、网络流量拥塞等问题。内存不均会导致集群内不同节点内存分布不均，不利于集群统一管理;超时阻塞是因为 Redis 单线程模型，操作 bigkey 耗时较长，容易阻塞 Redis;网络流量拥塞则是如果 bigkey 正好又是 hot key，容易产生大量网络流量。可以使用 redis-cli --bigkeys -i 1 扫描 bigkey，其中 -i 1 表示每隔 1 秒扫描一次，降低对 Redis 的影响。还可以使用第三方工具 redis-rdb-tools 分析 Redis 的 rdb 快照文件，找出 bigkey。删除 bigkey 时，可以使用 SCAN 命令组渐进式删除，对于不同类型的 bigkey，可以使用不同的方法，如删除 big string 可以直接用 DEL，删除 big hash key 可以使用 HSCAN 和 HDEL 结合 pipeline 批量删除，此外可使用华为云大 key 分析功能查找 Redis 实例大 Key 和热
FAQ
Redis 性能测试主要关注哪些指标？
主要关注吞吐量 (QPS)、延迟 (Avg/P50/P95/P99 响应时间)、资源使用 (CPU、内存、网络 I/O、连接数) 以及缓存 key 命中率。
如何避免 Redis 中的 BigKey 问题？
控制 string 类型在 10KB 以内，hash/list/set/zset 元素个数不超过 5000；使用 redis-cli --bigkeys 扫描；删除时使用异步删除或渐进式删除。
Redis 如何保证数据一致性？
通过持久化策略 (RDB/AOF)、事务机制 (MULTI/EXEC)、Lua 脚本原子性操作，以及合理设置过期时间避免同时失效，配合客户端重试机制。