一句话说明：把灰度发布、熔断降级、幂等、分库分表与链路追踪按流量、容错、数据、观测四层摆开，逐条给出定义、适用场景、常见坑与易混概念。
全部内容内置在本页，本地检索，不连接任何线上服务。
6 terms / 4 layers / 0 requestscanary。还没有选满两张卡。常见的一对是熔断与降级：一个被动切断，一个主动收缩。
给每个场景选一个最贴合的术语，提交后逐条给解释。不评分、不排名，只用来检查概念有没有记混。
预览：—
| 输入词 | 命中术语 | 所属层 | 匹配方式 | 备注 |
|---|
灰度发布是什么？它是流量层的发布策略：新版本只放给一小部分用户，观察错误率与业务指标后逐步放量。它解决的是变更风险，不是容量问题，也不要和 A/B 测试的「对比实验」混为一谈。
熔断降级区别最容易被连写掩盖。熔断是容错层的被动保护：依赖持续失败时先切断调用，留恢复窗口再半开试探；降级是主动取舍：大促或故障时关掉非核心功能，把资源留给主链路。两者常一起用，但触发条件与动作方向不同。
幂等怎么设计？关键不是限制重试次数，而是让同一请求重复到达时最终状态一致：业务唯一键加唯一索引、状态机只允许一次流转、请求号去重表都是常见做法。分库分表什么时候用则更靠后——索引与 SQL 优化仍不够、单机容量或写入吞吐见顶时才考虑，因为它会带来跨片查询与分布式事务成本。
链路追踪怎么串？用同一个 traceId 贯穿一次请求经过的服务与耗时，用来定位慢在哪一段，它不等于日志收集，也不等于指标监控。本页把这四层放在同一张索引卡上，支持架构术语并排对照与后端术语批量检索，内容全部本地内置，不生成可执行的配置代码。
| 灰度发布 | 把新版本先放给一小部分流量，观察指标再逐步放量；与「一次性全量上线」相对。 |
|---|---|
| 熔断与降级 | 熔断是依赖持续失败时暂时切断调用；降级是主动关掉非核心功能保住主链路，两者不是一回事。 |
| 幂等 | 同一请求重复执行多次，结果一致；实现方式常见唯一键、状态机与去重表，不是简单的「加个重试」。 |
| 分库分表 | 按业务或数据量把单库单表拆开；引入跨片查询、分布式事务与扩容成本，不是性能问题的第一选择。 |
| 链路追踪 | 用 traceId 串起一次请求经过的服务与耗时，用来定位慢在哪一段，不等于日志收集。 |
这些词常在技术方案里一起出现，却分别属于流量层、容错层、数据层与观测层。本页按层拆成六张卡，避免把「熔断降级」当成一个词、把「幂等」当成去重。
页面只做本地术语对照与检索，不连接任何线上服务，也不生成可直接用于生产环境的配置代码。
熔断是依赖持续失败后暂时切断调用，防止故障扩散；降级是主动关闭非核心功能，把资源留给主链路。一个被动、一个主动，触发条件也不同。
按用户、地域或比例把新版本先放给少量流量，观察错误率与业务指标后再逐步扩量，与一次性全量发布相对。
常见做法是业务唯一键加唯一索引、状态机只允一次流转、或请求号去重表。关键是让重复请求的最终状态一致，而不是单纯限制重试次数。
单机容量、写入吞吐或运维边界成为瓶颈且索引与 SQL 优化已不够时再考虑；它会带来跨片查询、分布式事务与扩容成本。
可以。勾选后可导出 Markdown 或 JSON，批量检索支持逗号、中文逗号与制表符分隔，导出内容按标准 CSV 规则转义。
现在只有你自己能看到这条留言（已标上「待审核」），管理员审核通过后才会展示给所有人～
资料版本 2026-11。本页为通用工程术语的静态整理，不针对特定框架或中间件版本，不连接线上服务，也不生成可直接用于生产环境的配置代码；具体实现请以所用组件的官方文档与团队规范为准。
还没有留言，来抢沙发吧！