暂无搜索历史
一句话总结:限流管 “多不多”,熔断管 “好不好”。流量再大只要依赖正常,限流只拦截超额部分;依赖一旦出故障,哪怕流量很小,熔断也会直接切断整条链路。
对于 RPC 调用,我们可以做统一的限流防护。但数据库、Redis 这类中间件,不能直接照搬 RPC 的接入思路。 核心矛盾在于:防护粒度如何选择?是单条 SQ...
本篇・限流(上):Sentinel 流量防护:限流的意义、选型、底层原理、框架集成与 Dashboard 改造核心定位:超时解决「慢请求如何快速失败释放资源」;...
在微服务线上问题排查中,Broken pipe 是高频常见异常。多数开发人员的惯性排查思路,是优先定位下游服务的网络、代码或容器问题。但在实际生产场景中,大批量...
谁能想到,一套经过线上多轮验证、自带双层优雅下线 + 120s 流量缓冲窗口的微服务销毁方案,会在一次常规节点缩容中彻底失效。线上检索服务大批量商品索引重建任务...
做后端稳定性治理的同学,大概率都遇到过 too many open files 故障。以往碰到文件句柄飙升,第一反应都是查代码:文件流、网络连接、临时文件有没有...
本文是整套 K8s OOM 故障治理系列的收官终篇。在此之前,本系列已全面覆盖堆内存泄漏、堆外内存溢出、线程池耗尽、连接池泄漏等绝大多数线上OOM场景,支撑公司...
基于300+线上项目实战,本专栏全覆盖K8s环境Java OOM故障,补齐Page Cache隐形OOM排查盲区,提供标准化、可直接落地的全链路治理方案。
同步 HTTP 接口有网关、RPC 客户端双层超时兜底,卡住请求会快速释放 Tomcat 线程;但 MQ 消费、异步任务、定时任务属于常驻后台线程模型,线程不依...
在 Spring Cloud 的世界里,配置优先级似乎是一个"常识"级别的问题。随便搜一下,你会看到无数文章告诉你类似这样的结论:
线上 AI 业务服务频繁发生容器重启,研发团队反复重启实例无法根治,排查陷入困境。排查首先要区分是java本身的oom还是容器的oom。确认这一点以后才能进行下...
微服务架构下,OpenFeign、gRPC 是跨服务远程调用最核心的两类 RPC 组件,几乎所有业务请求都会经过远程调用环节。如果 RPC 调用缺少合理超时控制...
Redis 作为分布式缓存、分布式锁核心组件,线上线程阻塞、数据脏写、死锁故障大多源于不合理超时、不了解底层重试黑白名单、锁编码不规范。本文结合团队线上固化基线...
在分布式系统开发中,跨进程、跨网络、跨组件的远程调用是常态:数据库访问、HTTP 微服务调用、RPC 通信、Redis 缓存、消息队列收发、异步任务、分布式锁争...
核心统一设计准则:服务端幂等声明 + 调用方动态配置双条件校验,Feign/gRPC 两套 RPC 保持安全、自愈、流量防护标准完全一致。
上一篇《超时基础理论与通用设计规范》统一了全链路超时的定义、分层规范与落地红线,明确所有跨进程数据库访问必须配置多层超时兜底。MySQL 作为业务最核心的存储层...
暂未填写公司和职称
暂未填写技能专长
暂未填写学校和专业
暂未填写个人网址