一、为什么要测试Redis？
Redis作为高性能缓存数据库，在生产环境中承担着至关重要的角色。上线前的充分测试，是保障其稳定运行的必经之路。本文将系统介绍Redis测试的三大维度：冒烟测试、压力测试和稳定性测试。
二、第一板斧：冒烟测试（连通性测试）
冒烟测试的目的是验证Redis服务是否正常启动、网络是否连通、认证是否通过。
2.1 使用redis-cli进行连通性测试
最简单的做法是使用Redis自带的命令行工具redis-cli：
bash
# 连接Redis
redis-cli -h 127.0.0.1 -p 6379
# 执行PING命令
127.0.0.1:6379> PING
PONG如果返回PONG，说明连接正常。如果设置了密码，需要先认证：
bash
redis-cli -h 127.0.0.1 -p 6379 -a your_password
127.0.0.1:6379> PING
PONG2.2 基本读写测试
连通之后，还需要验证基本的读写功能是否正常：
bash
127.0.0.1:6379> SET test_key "hello"
OK
127.0.0.1:6379> GET test_key
"hello"
127.0.0.1:6379> DEL test_key
(integer) 1能存能取，说明基础功能正常。测试完成后记得删除测试key，避免污染生产数据。
三、第二板斧：压力测试（性能基准测试）
压力测试的目的是评估Redis在不同负载下的吞吐量（QPS）和延迟表现。Redis官方提供了强大的基准测试工具------redis-benchmark。
3.1 redis-benchmark常用参数
| 参数 | 说明 | 默认值 |
|---|---|---|
-h |
服务器主机名 | 127.0.0.1 |
-p |
服务器端口 | 6379 |
-c |
并发连接数 | 50 |
-n |
总请求数 | 100000 |
-d |
SET/GET值的数据大小（字节） | 2 |
-t |
指定测试的命令列表 | 所有命令 |
-q |
安静模式，仅显示QPS值 | - |
-l |
循环测试，永久执行 | - |
3.2 基础压测示例
快速测试SET和GET命令：
bash
redis-benchmark -t set,get -n 100000 -q输出示例：
text
SET: 143678.16 requests per second
GET: 145560.41 requests per second模拟100个并发客户端，发送10万个请求：
bash
redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 1000003.3 高级压测场景
1. 使用随机Key模拟真实缓存场景：
bash
redis-benchmark -t set,get -n 100000 -r 1000000 -q-r 1000000表示使用最多100万个不同的随机Key。
2. 测试大Value场景：
bash
redis-benchmark -t set,get -d 1024 -n 100000 -q-d 1024表示测试1KB大小的数据。
3. 长时间稳定性压测（循环执行）：
bash
redis-benchmark -l -c 50 -n 100000使用-l参数可以让测试永久执行，适合做长时间稳定性观察。
3.4 压测注意事项
-
不要在同一台机器上既当服务端又当客户端，否则CPU会被打满导致数据不准。
-
压测前确保Redis实例已启动，且网络延迟尽可能低。
-
关注P99延迟（最慢的1%请求的耗时），这比平均值更能反映真实体验。
四、第三板斧：稳定性测试（故障模拟）
稳定性测试的目的是验证Redis在极端情况下的表现，包括内存溢出时的淘汰策略、主从切换时的故障转移等。
4.1 内存淘汰策略测试
当Redis内存达到上限时，需要验证它是否会按照配置的淘汰策略自动删除旧数据，而不是直接崩溃报OOM错误。
测试步骤：
- 设置maxmemory和淘汰策略：
bash
redis-cli CONFIG SET maxmemory 100mb
redis-cli CONFIG SET maxmemory-policy allkeys-lru- 持续写入数据直到内存达到上限，可以使用压测工具持续写入：
bash
redis-benchmark -t set -n 1000000 -d 1024- 监控淘汰情况：
bash
redis-cli INFO stats | grep evicted_keys如果evicted_keys在增长，说明淘汰策略正在生效。
- 验证写入是否正常：内存满后继续写入，观察是正常淘汰旧数据还是返回OOM错误。
注意 ：
maxmemory-policy默认为noeviction，此时内存满后写入会直接报错。生产环境推荐使用allkeys-lru或volatile-lru。
4.2 主从切换测试
对于使用Sentinel或Cluster模式的高可用架构，需要验证主节点故障时从节点能否自动接管。
测试步骤：
-
搭建一主一从+Sentinel环境。
-
确认主从同步正常：
-
在Master写入测试Key，在Slave上验证是否同步
-
使用
INFO keyspace检查主从各DB的Key数量是否一致
-
-
模拟主节点故障：直接杀掉Master进程。
bash
# 找到Redis主进程PID
ps -ef | grep redis-server
# 杀掉主节点进程
kill -9 <master_pid>-
观察故障转移：
-
Sentinel集群是否在几秒内选举出新的Master
-
客户端是否有自动重连和切换机制
-
-
验证数据完整性：在新Master上检查数据是否完整。
-
恢复原主节点：重启后观察它是否自动成为新Master的Slave。
五、总结
Redis测试的三大维度可以概括为：
| 测试类型 | 核心目的 | 关键工具/命令 |
|---|---|---|
| 冒烟测试 | 验证连通性和基本功能 | redis-cli PING、SET/GET |
| 压力测试 | 评估吞吐量和延迟 | redis-benchmark |
| 稳定性测试 | 验证淘汰策略和故障转移 | CONFIG SET、模拟杀进程 |
一句总结：能连上、跑分达标、杀主节点不丢数据且能自动切，Redis就算测过关了。