数据概览
0
粉丝
2
关注
4
获赞
0
被收藏
0
被评论
300
浏览
0
回答
0
被采纳
0.0%
采纳率
5
信誉
110
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
高山仰止
已解锁
内容被他人引用 1 次
高并发场景下Redis缓存击穿与解决方案实战 一、现象与背景：缓存击穿导致服务雪崩 我们遇到了一个典型的高并发场景：某个热门商品页面的缓存突然失效，导致大量请求直接打到数据库。例如，商品ID为1001的商品，缓存失效后，10秒内有2000次
Kafka 消费者组 Rebalance 风暴：如何在不改业务代码的前提下实现『检测 → 告警 → 自愈』闭环？ 一、现象与背景 Kafka 消费者组的 Rebalance 风暴是高并发场景中常见的痛点，尤其是在消费者数量较多、消息吞吐量大
【背景】 Kafka 消费者组的 Rebalance 风暴是高并发场景中常见的痛点，尤其是在消费者数量较多、消息吞吐量大的情况下，Rebalance 可能导致服务抖动甚至短暂不可用。 【常见分歧或几种做法】 1. 被动监控 + 人工干预：通
Flink checkpoint 对齐把反压放大 3 倍：一次 checkpoint 耗时从 800ms 飙到 22s 的根因、unaligned 开关与它的 3 个隐性坑 一、现象与背景 先给数字。我们一条实时风控特征管道：Flink 1
背景 做数据工程 5 年，我几乎每个月都要和"倾斜"打交道：Flink 的 keyBy 热 key 让某个 subtask 的 RocksDB 写入 QPS 飙到均值的 30 倍、Kafka 消费组里某个分区被一条大商家消息拖到 5 分钟才