Redis p99问题

最新推荐文章于 2025-02-25 15:08:07 发布
最新推荐文章于 2025-02-25 15:08:07 发布
阅读量1.9k 收藏
点赞数
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u012817635/article/details/80855870
版权

看到了一个新名词，p99，记录一下，帮助后来者少走坑


百度和Google了一下 Redis p99，结果出来的是手枪。。。谷歌也差不到啥



后来问前辈，这个p99的意思是 percent99的意思，就是百分之99。

百分之99以上的情况，取数据的毫秒数，就是 Redis p99

metrics 指标分析——你不在意的p99和p999
持之以恒
09-27 2万+
http://www.strolling.cn/category/metrics/ metrics 统计值。
Redis延时高问题排查与总结
Code365
07-03 842
20230308 在某地域进行了线上压测, 发现接口RT频繁超时, 性能下降严重, P50 400ms+, P90 1200ms+, P99 2000ms+。简直是amazing, 完结撒花!作为高性能爱好者, 榨干CPU的每一分价值是我们的宗旨, 是可忍孰不可忍, 怎么能光空转, 不干活呢?我们把问题简化为如下序列, 即可发现问题所在. 在T2~T3内, 84个对象创建, 84个对象销毁. 造成了极大的损耗。如下, 请求远远没有达到机器带宽, 不是瓶颈. 另外单独看了网卡重传率等指标, 也都正常。
不同 Redis 持久化方案在库存场景的性能评测
maomeimeimao的博客
01-23 71
用户也可以自由控制 EloqKV 内存层和底层 KV 存储的交互频率，可以每 10 秒做一次 checkpoint，也可以每分钟做一次，所有的 checkpoint 都是增量的，只有变化的数据需要写入 KV 存储，如果同一个 Key 在 checkpoint 周期被更改了多次，只有最后一次需要写入到 KV 存储。从结果可以看出，EloqKV 在处理大规模并发下的库存增删操作时，性能显著优于 Pika，尤其在长尾延迟 (P999) 方面，EloqKV 的表现更加稳定，在高吞吐的同时仍保持较低的延迟。
redis规范
kkkkm1的博客
02-25 726
建议根据业务只将高频热数据存储到Redis中【QPS大于5000】，对于低频冷数据可以使用MySQL/ElasticSearch/MongoDB等基于磁盘的存储方式，不仅节省内存成本，而且数据量小在操作时速度更快、效率更高。Redis主要用于缓存处理，加快读取效率，但在使用过程中需要注意合理的使用，一般存储全局配置数据和一些访问非常频繁的较为静态的数据，另外注意过期时间控制，减少资源的不必要消耗。并发量：如果你的应用程序具有高并发的特点，可以增加连接数的值，以确保有足够的连接可供同时使用。
接口的 p99 p99.9 是什么意思
艾斯比
01-09 5573
背景 想要了解 p99 概念, 我们先了解平均响应时间 接口平均响应时间很好理解 平均耗时 = 每次接口的耗时求和 / 接口请求次数 平均耗时容易计算, 但是会掩盖事实. 举个栗子, 我和 pony 马和 jack 马的平均资产可以撼动整个亚洲. P99 p99 表示按照响应时间从小到大排序, 排名在 99% 的接口响应时间即为 P99 的时间, 即 99% 的接口请求都小于等于该时间, 1% 的接口请求都大于该时间 P99 可以看出接口的 99% 的请求都在某个时间内, 更真实客观地反应接口的响应时间的
什么是p99
weixin_42656794的博客
07-19 3429
p99表示过去10s内最慢的1%请求的平均延迟
p95、p99、p999 什么意思
热门推荐
云淡风轻
03-17 1万+
下面是个摘录的压测结果 单位是µs 这里的p是percent(百分比) HAProxy这行的p99.9代表99.9%的请求响应时间不大于269µs 参考 https://github.com/artilleryio/artillery/issues/91 https://medium.com/star-gazers/benchmarking-low-level-i-o-c-c-rust-golang-java-python-9a0d505f85f7 https://blog.csdn.net/Rylan
什么事P95、P99
Crecendow
08-09 1601
前段时间，在对系统进行改版后，经常会有用户投诉说页面响应较慢，我们看了看监控数据，发现从接口响应时间的平均值来看在500ms左右，也算符合要求，不至于像用户说的那么慢，岁很费解，后来观察其它的一些指标发现确实是有问题，这个指标就是P95,P99.9，我们发现虽然平均响应时间并不高，但P95和P99.9却达到了2s以上，说明我们的接口确实存在慢查询。于是捞取了一些慢查询的请求日志终于发现问题。那么P95、P99又代表什么意思呢？
redis内存占用率持续飙升问题处理
will的成长之路
02-21 4969
生产环境的问题：春节前后，redis内存占用率持续飙升 延展问题： Redis里面如果有大量的key，怎样才能高效的找出过期的key并将其删除呢，难道是遍历每一个key吗（keys命令确实能触发内存释放）？假如同一时期过期的key非常多，Redis会不会因为一直处理过期事件，而导致读写指令的卡顿？ 答： keys *命令确实会阻塞其他命令的执行，导致慢查询。 那Redis是怎么解决的呢？ Redis4.0新增了lazy free特性，从根本上解决Big Key(主要指定元素较多集合.
Redis 下载安装
qq_33753147的博客
10-18 9293
Redis 下载安装
GaussDB(for Redis)与原生Redis的性能对比
GaussDB数据库
08-24 548
说明 本文以原生Redis5.0为例，分析其与GaussDB（for Redis）(下文简称高斯 Redis)的性能、成本比拼。 对比 成本比拼 原生Redis的数据存放在内存中，高斯 Redis的数据存放在磁盘中，我们比较相同数据容量（192G）的成本开销。 即使不考虑原生Redis的内存利用率打折，也可以得出，高斯 Redis的成本是原生Redis的1/3。 压缩比拼 采用Redis社区开源的压测工具memtier_benchmark写入相同的数据量，比较在两种数据库的空间占用： 即用户写入数据量
memtier-benchmark redis 性能测试
蜜獾互联网
01-07 1098
是一种高吞吐量的性能基准测试工具，主要用于Redis和Memcached。它是Redis开发团队开发的，旨在生成各种流量模式，以便测试和优化这些数据库的性能。以下是。
p99延迟是什么
weixin_34032779的博客
03-23 1万+
最近看到一个p99不知道代表什么,通过查询得知:p99.9p99p95p90 过去10秒内最慢的x%的请求的平均延迟.其中X是数字与100的差.例如:p99 1.403 表示过去的10秒内最慢的1%请求的平均延时为1.403秒p95 过去的10秒内最慢的5%的请求平均延时. 转载于:https://blog.51cto.com/8745668/2367868...
p99 寻找多数元素
binyanye1的专栏
09-28 761
寻找多数元素// 寻找多数元素.cpp : Defines the entry point for the console application.//#include "stdafx.h"#includeusing namespace std;int candidate(int m,int n,int A[]){ int j=m, c=A[m],count=1;
谷粒商城-基础篇-仓储服务（P95-P99）
ljn1046016768的博客
05-25 1103
谷粒商城 库存系统 微服务
【Sanic】Prometheus监控接入（QPS、P99等）
u011590738的博客
07-05 4486
【Prometheus】常见监控指标代码
《Java程序员面试宝典》P99例题3的一个问题分析
z421745963的专栏
04-11 1138
在java程序员面试宝典中有这样一道题 面试例题3：The code output（下列代码输出结果是什么？） import java.util.*; public class Test{ private String value = null; public Test(String v){ value = v; } public boolean equals(T
说下什么是p90，p95，P99？
weixin_51291483的博客
01-16 890
表示90%的数据点小于或等于该值，剩下的10%的数据点大于这个值。比如在性能测试中，如果系统的响应时间的P90是500室秒，那么意味着90%的请求响应时间小于或等于500室秒，只有10%的请求响应时间超过500室秒。百分位数表示一个数值在一组数据中的相对位置。例如，第X百分位数(P X)指的是一组数据中有X%的数据点小于或等于该数值，剩下的(100-X%的数据点大于该数值。：表示95%的数据点小于或等于该值，剩下的5%大于该值。：表示99%的数据点小于或等于该值，剩下的1%大于该值。
redis一级缓存 jvm二级缓存
最新发布
03-26
<think>嗯，用户问的是Redis作为一级缓存，JVM作为二级缓存的介绍。首先，我需要确定这两个概念在缓存系统中的作用和位置。通常，一级缓存（L1）是离应用最近的，速度最快，但容量较小；二级缓存（L2）则更大但稍慢一些。不过这里用户提到的是一级用Redis，二级用JVM，这似乎和常见的JVM一级、Redis二级的结构相反，可能用户有特殊需求或者配置，我需要先确认这点是否正确。 接下来，我需要解释这两个缓存的角色。Redis作为内存数据库，通常作为分布式缓存使用，适合做二级缓存，而JVM缓存如Ehcache或Caffeine作为一级，因为它们在应用进程内，访问更快。但用户的情况反过来，可能需要说明这种架构的适用场景，比如可能考虑到网络延迟或其他因素，将Redis作为更接近数据源的一级，而JVM作为二级补充？ 然后要分析两者的优缺点。Redis作为一级，优点是分布式、一致性好，但网络延迟可能影响速度。JVM作为二级，访问速度快，但容量有限，数据不一致风险。需要比较两者的读写策略，比如如何保持同步，常见的策略如写穿透、写回等。 还要考虑数据同步机制，比如如何确保Redis和JVM缓存的一致性，可能使用消息队列或者发布订阅机制来通知缓存失效。此外，适用场景方面，这种架构可能用于需要快速访问但又能容忍一定程度数据延迟的应用，或者作为多级缓存的优化策略。 需要注意用户可能的混淆，是否将一级和二级的顺序搞反了，但按照问题描述，还是按用户说的来回答。同时，检查是否有误，比如Redis作为一级是否合理，或者是否有其他考虑因素，比如网络架构使得Redis更接近应用，成为一级缓存。 最后，总结这种架构的优缺点和使用场景，帮助用户理解何时选择这样的方案，以及需要注意的问题，比如数据一致性、缓存击穿、雪崩等常见问题，以及如何通过TTL、熔断机制等来缓解。</think>好的，我将分步骤为您解释“Redis一级缓存 + JVM二级缓存”的架构设计及其工作原理： 1. **基础概念** - **一级缓存（Redis）**：位于应用层外部，基于分布式内存数据库的缓存，所有服务实例共享同一份缓存数据。 - **二级缓存（JVM）**：位于应用进程内部（如堆内存），通过HashMap、Ehcache、Caffeine等实现，仅当前实例可见。 2. **数据访问流程** ``` 请求 → 检查JVM缓存 → 命中则返回 ↓ 未命中 检查Redis缓存 → 命中则返回并写入JVM ↓ 未命中 查询数据库 → 写入Redis → 写入JVM → 返回 ``` 3. **核心优势对比** | 特性 | Redis一级缓存 | JVM二级缓存 | |---------------|----------------------------------|----------------------------| | 数据一致性 | 全局一致 | 单机一致，集群可能不一致 | | 访问速度 | 微秒级（网络IO开销） | 纳秒级（内存直接访问） | | 容量 | 十GB~百GB级 | MB~GB级（受堆内存限制） | | 数据共享 | 跨进程、跨机器共享 | 仅进程内有效 | 4. **同步策略设计** - **写操作处理**： ```java public void updateData(Data newData) { // 先更新数据库 db.update(newData); // 删除两级缓存（保证后续读取加载最新值） redis.delete(key); localCache.invalidate(key); } ``` - **过期控制**： - Redis设置TTL（如30分钟） - JVM设置更短的TTL（如10分钟）避免长期脏数据 5. **性能优化技巧** - **JVM缓存预热**：服务启动时批量加载热点数据 - **Redis布隆过滤器**：防止缓存穿透 - **分级TTL策略**： $$ TTL_{JVM} = \alpha \cdot TTL_{Redis} \quad (0 < \alpha < 1) $$ - 异步刷新：后台线程主动更新临近过期的热点数据 6. **典型应用场景** - 高并发读（>10k QPS）且数据变更频率较低的场景 - 电商商品详情页 - 新闻类内容展示 - 地理位置信息查询 7. **风险控制措施** - **熔断机制**：Redis故障时自动降级为纯JVM缓存 - **限流策略**：使用令牌桶控制数据库访问量 - **监控指标**： ```mermaid graph TD A[缓存命中率] --> B(Redis命中率>85%) A --> C(JVM命中率>95%) D[延迟分布] --> E(Redis P99<2ms) D --> F(JVM P99<100μs) ``` 8. **数据一致性保障** - 最终一致性模型： 1. 数据库更新成功后 2. 通过Redis Pub/Sub广播失效指令 3. 各节点监听通道并清除本地JVM缓存 $$ \text{不一致时间窗口} \leq T_{pub/sub} + T_{network} $$ 这种多级缓存架构需要根据业务特征进行参数调优，建议通过压力测试确定最佳TTL值和缓存容量比例。当数据更新频繁（如库存秒杀场景）时，需谨慎评估使用此模式。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值