万万没 想到,Redis性能测试还能这样做

在这里插入描述

01 服务器环境

在这里插入图片描述

Redis之redis-benchmark

redis 提供了 redis-benchmark 工具便于我们做性能测试,可以使用 redis-benchmark- h 查看参数。

在这里插入图片描述

01 Docker Redis测试

单并发测试

测试命令:

./redis-benchmark -c 1 -n 20000 -d 30720 -t set,get

测试结果每秒是 8000+的QPS

多并发测试

====== SET ======

  20000 requests completed in 1.06 seconds
  10 parallel clients
  30720 bytes payload
  keep alive: 1
  host configuration "save": 900 1 300 10 60 10000
  host configuration "appendonly": no
  multi-thread: no
18903.59 requests per second
====== GET ======
  20000 requests completed in 1.30 seconds
  10 parallel clients
  30720 bytes payload
  keep alive: 1
  host configuration "save": 900 1 300 10 60 10000
  host configuration "appendonly": no
  multi-thread: no
15360.98 requests per second

测试 -P 命令

====== SET ======
  20007 requests completed in 0.47 seconds
  50 parallel clients
  30720 bytes payload
  keep alive: 1
  host configuration "save": 900 1 300 10 60 10000
  host configuration "appendonly": no
  multi-thread: no
42933.48 requests per second
====== GET ======
  20002 requests completed in 0.44 seconds
  50 parallel clients
  30720 bytes payload
  keep alive: 1
  host configuration "save": 900 1 300 10 60 10000
  host configuration "appendonly": no
  multi-thread: no
45253.39 requests per second

02 redis6 安装版测试

单并发测试

 SET ======

  200000 requests completed in 20.20 seconds
  1 parallel clients  3 bytes payload
  keep alive: 1
  host configuration "save": 900 1 300 10 60 10000
  host configuration "appendonly": no
  multi-thread: no
9900.01 requests per second
====== GET ======
  200000 requests completed in 20.01 seconds
  1 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 900 1 300 10 60 10000
  host configuration "appendonly": no
  multi-thread: no
9995.50 requests per second

多并发测试

====== SET ======
  200000 requests completed in 3.00 seconds
  10 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 900 1 300 10 60 10000
  host configuration "appendonly": no
  multi-thread: no
66622.25 requests per second
====== GET ======
  200000 requests completed in 3.02 seconds
  10 parallel clients
  3 bytes payload
  keep alive:1
  host configuration "save": 900 1 300 10 60 10000
  host configuration "appendonly": no
  multi-thread: no
66137.57 requests per second

03 -P 测试

单并发测试

====== SET ======

  200000 requests completed in 2.20 seconds
  1 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 900 1 300 10 60 10000
  host configuration "appendonly": no  
multi-thread: no
90991.81 requests per second
====== GET ======
  200000 requests completed in 2.15 seconds
  1 parallel clients  3 bytes payload
  keep alive: 1
  host configuration "save": 900 1 300 10 60 10000
  host configuration "appendonly": no  
multi-thread: no
92980.01 requests per second

多并发测试

====== SET ======

  200010 requests completed in 0.42 seconds
  10 parallel clients  3 bytes payload
  keep alive: 1
  host configuration "save": 900 1 300 10 60 10000
  host configuration "appendonly": no
  multi-thread: no
480793.25 requests per second
====== GET ======
  200000 requests completed in 0.34 seconds
  10 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 900 1 300 10 60 10000
  host configuration "appendonly": no
  multi-thread: no
586510.25 requests per second

下面是一份配套资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!
在这里插入图片描述
这些都可以以在公众号:伤心的辣条 ! 免费领取,还有一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享!,其中资料包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

学习不要孤军奋战,最好是能抱团取暖,相互成就一起成长,群众效应的效果是非常强大的,大家一起学习,一起打卡,会更有学习动力,也更能坚持下去。你可以加入我们的测试技术交流扣扣群:914172719(里面有各种软件测试资源和技术讨论)

喜欢软件测试的小伙伴们,如果我的博客对你有帮助、如果你喜欢我的博客内容,请 “点赞” “评论” “收藏” 一键三连哦!


好文推荐

转行面试,跳槽面试,软件测试人员都必须知道的这几种面试技巧!

面试经:一线城市搬砖!又面软件测试岗,5000就知足了…

面试官:工作三年,还来面初级测试?恐怕你的软件测试工程师的头衔要加双引号…

什么样的人适合从事软件测试工作?

那个准点下班的人,比我先升职了…

测试岗反复跳槽,跳着跳着就跳没了…

<think> 嗯,用户这次聚焦在Redis Cluster集群的备份必要性上,看来是在生产环境遇到了实际运维决策。之前讨论普通Redis缓存备份时用户应该已经理解基础逻辑,现在需要更针对集群架构的特性分析。 用户提供的引用材料很有价值,尤其引用[4]提到Redis Cluster的异步复制特性——这直接关系到灾备设计。需要特别注意:即使集群有主从复制,异步机制仍可能导致写入丢失(master写入成功但未同步到slave时宕机)。用户可能担心单纯依赖集群内复制是否足够。 从运维角度看(引用[3]),用户所在团队似乎正在推进缓存系统统一化,这种标准化过程中备份策略必须纳入考量。引用[2]的集群升级示例也暗示了槽位信息记录的重要性,这其实属于备份范畴——不仅要备数据,还要备元数据。 用户明说但可能纠结的点在于:Cluster本身有高可用机制(slave自动切换),是否还需额外备份?这里要分两层回应: 1)硬件或地域故障层面:单机房集群的所有节点可能同时失效; 2)数据逻辑层面:误操作删除或程序bug污染数据时,集群复制只会同步错误数据。 想到个典型案例:某电商大促前误执行`FLUSHALL`,如果有离线备份,即使集群所有节点健在,数据也瞬间归零。 回复时需要强调三个关键动作: - 定期远程备份RDB(尽管Cluster分散数据,但redis-cli --cluster backup可整合) - 验证备份文件可恢复性(模拟slot分配) - 和业务方确认数据再生成本(有些推荐模型生成耗时数小时) 最后补充的运维建议要实用,比如备份文件命名规则最好包含槽位分布版本号(参考引用[2]的槽位记录要求)。 </think> Redis Cluster缓存集群**必须进行备份**,即使它作为缓存层使用。以下是核心分析及解决方案: --- ### 一、必须备份的关键原因 1. **数据不可再生风险** - 部分缓存数据(如实时计算的聚合结果、用户会话)丢失后无法从数据库直接重建,需耗时重新计算[^4]。 - **场景示例**:推荐系统缓存丢失,导致瞬时计算压力击垮服务。 2. **集群高可用≠数据安全** - Redis Cluster的主从切换(Failover)仅解决节点故障,无法防御: - 误操作(如`FLUSHALL`) - 程序Bug导致数据污染 - 物理灾难(机房火灾)[^1][^3] - 异步复制下,写入成功的请求仍可能丢失(引用[4]明确说明) 3. **持久化机制局限性** - RDB快照默认间隔5分钟,期间数据可能丢失。 - AOF日志文件可能损坏(如磁盘故障)。 4. **集群升级/扩容风险** - 引用[2]证明:集群升级需记录槽位分布,无备份则无法恢复数据一致性。 --- ### 二、Redis Cluster备份方案 #### 1. **自动化RDB快照备份** ```bash # 每6小时备份一次,保存到异地存储 0 */6 * * * redis-cli -h <cluster-node> --rdb /backup/redis-$(date +\%s).rdb \ && aws s3 cp /backup/*.rdb s3://backup-bucket/ ``` - **优势**:兼容Cluster架构,文件小(压缩二进制) - **注意**:需轮询所有主节点备份(16384个槽需全覆盖) #### 2. **AOF持久化+日志同步** ```redis # redis.conf配置 appendonly yes appendfsync everysec # 平衡性能与安全 ``` - **操作**:用`rsync`实时同步AOF文件至异地服务器 - **恢复**:用`redis-check-aof`修复文件后加载 #### 3. **混合灾备架构** ```mermaid graph LR A[Redis Cluster] --> B(主节点RDB备份) A --> C(Slave节点AOF同步) B --> D[云存储(S3/OSS)] C --> E[异地日志服务器] D & E --> F[定期恢复验证] ``` --- ### 三、决策建议表 | **场景** | **备份策略** | 关键动作 | |--------------------------|----------------------------------|------------------------------------------| | 容忍分钟级数据丢失 | RDB快照 + 跨区域存储 | 每日验证备份文件可恢复性 | | 零数据丢失需求 | AOF实时同步 + RDB增量备份 | 部署日志审计追踪写入操作 | | 防御地域灾难 | 跨云厂商备份 + 只读副本集群 | 季度灾备演练 | | 大规模集群(TB级) | 分片备份 + 槽位元数据保存 | 记录`CLUSTER SLOTS`输出[^2] | > **关键结论**:Redis Cluster的分布式特性不替代备份!异步复制和持久化间隔仍存在数据丢失窗口,备份是最后防线。 --- ### 四、运维最佳实践 1. **验证备份有效性** ```bash # 恢复测试(需隔离环境) redis-server --port 6380 --dbfilename backup.rdb redis-cli -p 6380 CLUSTER ADDSLOTS {0..5500} # 按原槽位分配 ``` 2. **监控备份完整性** - 指标:`last_save_time`,`aof_current_size` - 告警规则:超过2小时无新备份则触发 3. **元数据保护** - 定期保存集群节点拓扑:`redis-cli -c CLUSTER NODES > cluster_topology.txt` ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值