寒蝉 Hancic
从真实业务场景看缓存的代价
我见过不少系统加缓存，动机主要有两个："别人都在加"和"它能让我系统变快"。 缓存的价值我不否认：避免重复操作，节省带宽和计算资源。缓存有很多层——本地内存缓存、分布式缓存（Redis）、文件缓存、CDN——每层解决的问题不同，付出的代价也不同。本地内存快，但每个实例各持一份；Redis 共享，但多
标签：架构
因子引擎：先定契约，再谈依赖图
因子引擎的设计稿画了四件事：注册表、依赖图、版本化缓存、失败隔离。实装只落了两件。为什么输出定死成三列长表、为什么依赖写在函数里、为什么版本号只当可复现锚点不当缓存 key：先说契约，再谈依赖图。
脑裂：分布式系统里最危险的故障
脑裂：集群分区后两个子集各自选出主节点，并行写入导致数据分叉。根因不是节点真挂了，而是看起来挂了——网络分区、心跳超时、VM暂停都会触发。防护靠 quorum + fencing token + 租约三层。Raft/Paxos 防选主脑裂，但 fencing 仍需存储层配合。
重试与退避：失败之后怎么办
朴素重试（失败立刻重试）在大规模下会引发重试风暴和级联放大。正确策略四件套：指数退避（给下游恢复时间）+抖动（打破同步）+重试预算（限制总重试流量）+只重试瞬时故障且幂等的操作。再配熔断器兜底——重试失败到阈值就停止，别一直试一个挂掉的服务。重试不是"再试一次"，是需要设计的工程。
幂等性：分布式系统里"做两次"为什么不等于"做一次"
幂等性（Idempotency）= 同一操作执行一次和多次产生相同结果。分布式环境下网络超时、消息重投、自动重试逼着操作必须幂等。实现靠"记住做过没有"：request_id 去重表、唯一约束、状态机、乐观锁。幂等和并发安全是两件事——前者管重复不出错，后者管同时不出错。
Profiling 方法论与实战：Python + Rust 双视角
从大盘指标定位维度，到采样定位函数，再到行级追踪——从大到小看，每一步基于上一步的证据。火焰图看平顶不看宽度。Rust 瓶颈往往在算法，Python 在解释器和进程开销。改完用数字确认，P99 达标就停。
技术债务：复杂度的复利
技术债不是因为决策做错了，是条件变了之后当初合理的决策不再合理。不是所有债都该还——利息高的该还，利息低的该背，架构级的才值得专门花时间。没有专职管理员，靠写代码的人顺手还、技术负责人盯大债。
认证与鉴权选择指南：JWT、OAuth 2.0、RBAC、ABAC、Keycloak 各自该出现的地方
一个服务刚上线，没用户，没登录。调用方都是内部系统，相互信任——IP 白名单就够了。 后来用户来了。要区分谁是谁。再后来有管理员、有普通用户、有只读用户。角色一多，权限判断就散在代码里——if user.role == 'admin' 写了二十遍，改一次要改二十个文件。 这时候你才开始看认证鉴权方案
压缩算法选择指南：LZ4、Snappy、gzip、Brotli、Zstd
一个服务每天往外吐几十 G 日志。你第一反应不是「换个压缩算法」，是「太大了，压一下」。 gzip -9 access.log，跑完一看，体积缩到十分之一。满意了。 后来日志量翻倍，gzip 跑一次要二十分钟。你开始想：能不能快点。 再后来上了 Kafka，消息要实时传。压缩不是在磁盘上慢慢压——每
分区：分而治之
复制是同一份数据放多份，分区是把不同数据放不同地方。数据量超过单机磁盘时，只能切开。
