摘要： 这篇文章面向已经会写 SQL、但还没系统建立过索引设计观的后端工程师。 读完你应该能回答四个问题： 一条 SQL 的成本到底花在哪里，索引消掉了其中哪一部分？ 面对一个查询场景，联合索引的列顺序该怎么排，依据是什么？ "最左前缀""回表""覆盖索引""索引下推"分别约束了什么，边界在哪里？ 线上发现 阅读全文

摘要： HashMap 是 Java 后端开发中最常用的集合之一。它看起来只是 put 和 get，但它背后包含了哈希算法、数组寻址、链表冲突处理、红黑树、扩容迁移、负载因子和并发风险等多个设计点。 如果只把 HashMap 当成语法工具，很多问题会被忽略：容量设置不合理会导致频繁扩容；对象 key 设计不 阅读全文

摘要： 理解这三者，最有效的切入点不是定义，而是它们各自站在调用链的哪个位置、保护的是谁。 一句话概括三者的差异：限流管"进来多少"，熔断管"还要不要调用它"，降级管"调不到时给什么"。 一、限流（Rate Limiting） 解决的问题 任何服务的容量都是有限的（线程池、连接池、CPU、DB 连接）。当入 阅读全文

摘要： RPO和 RTO 都是容灾（Disaster Recovery）指标，最直观的区分方式是：它们在时间轴上一个向前看、一个向后看。 RPO = Recovery Point Objective（恢复点目标） → 看故障之前：能容忍丢多少数据 RTO = Recovery Time Objective（ 阅读全文

摘要： 一、可用性怎么定义：两种口径 「可用性」不是一个自然存在的数字，而是你自己定义出来的。定义方式不同，同一个系统能算出完全不同的可用率。这是所有讨论的前提。 1.1 时间维度（传统运维口径） 问题在于「不可用」的判定极其模糊：部分接口 500 算不算？响应从 50ms 涨到 5s 算不算？10% 的用 阅读全文

摘要： 核心结论先摆出来：先更新数据库、再删除缓存（Cache Aside） 是通用读缓存场景下唯一可取的顺序。但它给你的不是强一致，而是"把不一致窗口压到工程可接受"。真正兜住底线的是三样东西：TTL 过期、删除失败的重试、以及不要在事务提交前删缓存。如果业务真的要求缓存与数据库强一致，那么正确的动作往往 阅读全文

摘要： 一句话结论：Future、CompletionService、CompletableFuture 都能把串行请求变并发，但只有后两者能让你按完成顺序拿到结果。而在真实线上系统里，决定这段代码是否可靠的，往往不是选了哪个 API，而是线程池、超时预算、异常语义和可观测性这四件事有没有做对。 一、从一个 阅读全文

摘要： 一、先把两个概念分清楚：size 和 capacity 聊 ArrayList 扩容之前，先区分两个容易混淆的概念： size：当前列表中实际存放的元素个数。 capacity：底层数组 elementData 的长度，也就是当前最多能容纳多少个元素而不触发扩容。 这两个值不是一回事。 List<S 阅读全文

摘要： 缓存一致性问题 计算机在运行程序时，每条指令都是在CPU中执行的，在执行过程中会涉及到数据的读写。我们知道程序运行的数据是存储在主存中，这时就会有一个问题，读写主存中的数据没有 CPU 中执行指令的速度快，如果任何的交互都需要与主存打交道则会大大降低效率，所以就有了 CPU寄存器、各级缓存、主存构成 阅读全文

摘要： 大模型“幻觉”（Hallucination）通常被解释为：模型生成了一段看似流畅、连贯、甚至很有说服力的内容，但其中包含与事实不符、与上下文不一致，或者无法被可靠依据验证的信息。 通俗地说，它就是“一本正经地胡说八道”。 但如果从工程角度看，幻觉的问题不只是“模型答错了”。真正危险的是：模型会用非常 阅读全文