<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>bytedepth</title>
<link>https://bytedepth.cn</link>
<description>bytedepth 最近发布的文章</description>
<atom:link href="https://bytedepth.cn/feed.xml" rel="self" type="application/rss+xml"/>
<lastBuildDate>Wed, 19 Aug 2026 19:00:21 +0800</lastBuildDate>
<item>
<title>编程 Agent 工程实践：从上下文到可靠交付</title>
<link>https://bytedepth.cn/posts/reliable-agent-engineering</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/reliable-agent-engineering</guid>
<description>&gt; 编程 Agent 的价值不在于代替工程判断，而在于把清晰意图、恰当上下文和快速反馈组成可重复的工程闭环；人负责目标、边界与风险，Agent 负责在可验证的循环中推进实现。 &gt; **TL;DR**：用好编程 Agent 的关键不是赋予它更大自主权，而是把软件工程中原本依赖资深工程师脑内完成的工作显式化：**用任务契约定义意图，用分层上下文提供证据，用自动化反馈校验结果，用人类监督处理高影响判断**。模型越强，越应投资于测试、架构边界、交付门禁和可恢复工作流；这些不是 Agent 的替代品，而是让 Agent 可靠放大团队能力的基础设施。 **关联笔记**：[AI Coding 工程实践：成为</description>
<pubDate>Wed, 19 Aug 2026 19:00:21 +0800</pubDate>
</item>
<item>
<title>容量规划与弹性：水位线、扩缩容与大促保障</title>
<link>https://bytedepth.cn/posts/capacity-planning-and-elasticity</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/capacity-planning-and-elasticity</guid>
<description>&gt; 本文系统梳理容量规划与弹性架构的完整体系：从容量规划的三种方法论（历史数据外推/压测推算/排队论建模），到水位线三级告警体系，再到弹性伸缩的触发策略与 K8s HPA/KEDA 实战，以及大促前的容量保障流程。综合了《容量保障核心技术与实战》（吴骏龙）的核心内容，强调&quot;鼓励快速扩容作为应急手段，但警惕无脑扩容&quot;。 --- ## 目录 | 章节 | 说明 | |------|------| | [容量保障的目标与度量](#容量保障的目标与度量) | 容量的定义与核心指标 | | [容量规划三种方法](#容量规划三种方法) | 历史外推 / 压测推算 / 排队论 | | [容量评估公式](#容</description>
<pubDate>Wed, 19 Aug 2026 15:03:04 +0800</pubDate>
</item>
<item>
<title>性能测试体系：压测方法、指标与瓶颈定位</title>
<link>https://bytedepth.cn/posts/performance-testing-framework</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/performance-testing-framework</guid>
<description>&gt; 本文系统梳理性能测试的完整体系：从测试类型（基准/负载/压力/稳定性/浸泡）的本质区别，到测试流程、工具选型（JMeter/Gatling/Locust/wrk 对比）、关键指标（TPS/RT/P99/P999）、瓶颈定位四步法，以及常见性能陷阱。综合了《性能测试实战 30 讲》（高楼）和《高并发架构实战课》（李智慧）的核心内容，强调&quot;没有证据链的分析就是耍流氓&quot;。 --- ## 目录 | 章节 | 说明 | |------|------| | [性能测试类型](#性能测试类型) | 五种类型的本质区别与适用场景 | | [业务指标 vs 技术指标](#业务指标%20vs%20技术指标) </description>
<pubDate>Wed, 19 Aug 2026 15:02:57 +0800</pubDate>
</item>
<item>
<title>性能优化方法论：指标分析与分层调优策略</title>
<link>https://bytedepth.cn/posts/performance-optimization-methodology</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/performance-optimization-methodology</guid>
<description>&gt; 本文从&quot;先测量再优化&quot;的基本原则出发，系统梳理性能优化的方法论框架：性能三要素（吞吐量/延迟/资源利用率）的定义与关系、CPU 密集 vs IO 密集的优化方向、JVM 层/数据库层/网络层/缓存层的具体优化手段，以及优先级判断原则（Amdahl 定律）。来源综合了《性能优化高手课》（尉刚强）和《高并发架构实战课》（李智慧）的核心内容。 **性能工程系列**：[高并发系统设计](/posts/196) · [秒杀系统设计](/posts/199) · **相关**：../02 编程语言/02 Java/03 Java 虚拟机 · ../02 编程语言/02 Java/04 Java 性能调</description>
<pubDate>Wed, 19 Aug 2026 15:02:50 +0800</pubDate>
</item>
<item>
<title>秒杀系统设计：库存、防超卖与高并发治理</title>
<link>https://bytedepth.cn/posts/seckill-system-design</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/seckill-system-design</guid>
<description>&gt; 本文系统梳理秒杀系统的设计方法：从核心挑战出发，讲解分层架构（CDN→Nginx→网关→应用层→缓存层→数据库）、库存扣减方案（先扣缓存/数据库乐观锁/消息队列异步）、防超卖三层防护、限流策略、预热方案，以及监控与降级。包含完整架构图（Mermaid）和每层技术选型说明。 **性能工程系列**：[高并发系统设计](/posts/196) · [性能优化方法论](/posts/200) · **相关**：[Redis 简介](/posts/172) · 消息队列核心原理 --- ## 目录 | 章节 | 说明 | |------|------| | [秒杀核心挑战](#秒杀核心挑战) | 瞬</description>
<pubDate>Wed, 19 Aug 2026 15:02:43 +0800</pubDate>
</item>
<item>
<title>全链路压测：容量验证、流量构造与瓶颈定位</title>
<link>https://bytedepth.cn/posts/full-link-stress-testing</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/full-link-stress-testing</guid>
<description>&gt; 全链路压测是在**生产环境**对完整业务链路进行压力测试，验证系统真实容量上限的工程实践。它不是一个工具，而是一套涉及架构改造、数据隔离、流量构建、监控分析的体系工程。读完可掌握：全链路 vs 隔离压测的本质区别、RESAR 方法论、数据隔离三种方案、容量规划公式、压测指标体系与瓶颈定位方法。 --- ## 目录 | 章节 | 说明 | |------|------| | [为什么需要全链路压测](#为什么需要全链路压测) | 隔离压测的局限 | | [RESAR 全链路方法论](#RESAR%20全链路方法论) | 五大模块框架 | | [核心链路梳理与流量模型](#核心链路梳理与流量模</description>
<pubDate>Wed, 19 Aug 2026 15:02:36 +0800</pubDate>
</item>
<item>
<title>稳定性与容灾设计：限流、熔断、降级与隔离</title>
<link>https://bytedepth.cn/posts/reliability-and-resilience</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/reliability-and-resilience</guid>
<description>&gt; 本文系统梳理分布式系统的稳定性保障体系：从限流（令牌桶/漏桶/滑动窗口）到熔断（Hystrix/Sentinel 原理）、降级策略、超时与重试（指数退避）、幂等设计、故障隔离（舱壁模式），再到灰度发布与压测容量规划，构建完整的稳定性防线。 --- ## 目录 | 章节 | 说明 | |------|------| | [稳定性威胁来源](#稳定性威胁来源) | 接口级故障的根因分析 | | [限流](#限流) | 令牌桶 / 漏桶 / 滑动窗口算法 | | [熔断](#熔断) | Hystrix / Sentinel 原理与状态机 | | [降级](#降级) | 丢车保帅，保核心业务 | </description>
<pubDate>Wed, 19 Aug 2026 15:02:29 +0800</pubDate>
</item>
<item>
<title>高并发系统设计：架构演进与关键技术选型</title>
<link>https://bytedepth.cn/posts/high-concurrency-system-design</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/high-concurrency-system-design</guid>
<description>&gt; 本文系统梳理高并发系统设计的核心方法：从 QPS/TPS/响应时间等核心指标出发，讲解水平扩展 vs 垂直扩展的选择依据，深入分析多级缓存、读写分离、分库分表、消息队列削峰、CDN 加速、连接池与线程池、异步化改造等关键技术，并给出系统演进的实践路径。 **性能工程系列**：[秒杀系统设计](/posts/199) · [性能优化方法论](/posts/200) · **相关**：消息队列核心原理 · [分布式一致性](/posts/48) --- ## 目录 | 章节 | 说明 | | ---------------------------------------------------</description>
<pubDate>Wed, 19 Aug 2026 15:02:22 +0800</pubDate>
</item>
<item>
<title>树与堆：二叉树、平衡树与优先队列</title>
<link>https://bytedepth.cn/posts/trees-and-heaps</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/trees-and-heaps</guid>
<description>&gt; 本文覆盖二叉树（遍历/完全/满）、BST、AVL 树、红黑树、堆（堆排序/优先级队列）和 Trie 树，重点理解各数据结构的**适用场景**和**操作复杂度**，以及设计背后的&quot;为什么&quot;。 --- ## 目录 | 章节 | 说明 | |------|------| | [二叉树基础](#二叉树基础) | 定义、存储、三种遍历 | | [二叉搜索树（BST）](#二叉搜索树（BST）) | 插入/删除/查找，三种删除场景 | | [平衡二叉树](#平衡二叉树) | AVL 树与红黑树，工程选型对比 | | [堆](#堆) | 最大堆/最小堆、核心操作、堆排序、应用 | | [Trie 树](</description>
<pubDate>Mon, 17 Aug 2026 15:07:55 +0800</pubDate>
</item>
<item>
<title>哈希表与位图：冲突处理、HashMap 与空间优化</title>
<link>https://bytedepth.cn/posts/hash-tables-and-bitmaps</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/hash-tables-and-bitmaps</guid>
<description>&gt; 本文覆盖哈希表的核心原理（散列函数设计、冲突解决、装载因子）、Java HashMap 实现要点，以及布隆过滤器和位图两种空间高效的数据结构。 --- ## 目录 | 章节 | 说明 | |------|------| | [散列表基础](#散列表基础) | 散列思想、散列函数设计 | | [冲突解决](#冲突解决) | 开放寻址法 vs 链表法 | | [装载因子与扩容](#装载因子与扩容) | 性能退化的关键指标 | | [Java HashMap 原理](#Java%20HashMap%20原理) | 底层实现与优化 | | [布隆过滤器](#布隆过滤器) | 空间高效的概率型数据结</description>
<pubDate>Mon, 17 Aug 2026 15:05:57 +0800</pubDate>
</item>
<item>
<title>线性数据结构：数组、链表、栈、队列与跳表</title>
<link>https://bytedepth.cn/posts/linear-data-structures</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/linear-data-structures</guid>
<description>&gt; 本文覆盖五种核心线性数据结构：数组、链表、栈、队列和跳表。掌握它们的内存模型、操作复杂度和典型应用场景，是理解更复杂数据结构的基础。 --- ## 目录 | 章节 | 说明 | |------|------| | [数组](#数组) | 连续内存、随机访问、动态扩容 | | [链表](#链表) | 单/双/循环链表，与数组的对比 | | [栈](#栈) | LIFO 结构，括号匹配、函数调用栈 | | [队列](#队列) | FIFO 结构，循环队列、阻塞队列 | | [跳表](#跳表) | 链表 + 多级索引，O(logn) 查询 | --- ## 数组 **数组（Array）** 是一</description>
<pubDate>Mon, 17 Aug 2026 15:05:52 +0800</pubDate>
</item>
<item>
<title>显式栈与状态机：替代递归的通用方法</title>
<link>https://bytedepth.cn/posts/explicit-stack-state-machine-recursion</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/explicit-stack-state-machine-recursion</guid>
<description>&gt; 递归把“下一步从哪里继续”保存在运行时调用栈中；显式栈把这份控制权交还给程序。本文给出从递归到 `Deque&lt;Frame&gt;` 的通用转换法，并用后序遍历、回溯和记忆化 DFS 三类例子说明何时必须加状态、如何避免遗漏回溯与结果汇总。 --- ## 目录 | 章节 | 说明 | |---|---| | [递归到底替你做了什么](#递归到底替你做了什么) | 看清调用栈替我们保存的内容 | | [何时应该改用显式栈](#何时应该改用显式栈) | 判断收益是否值得复杂度 | | [转换的核心：栈帧 + 阶段](#转换的核心：栈帧%20+%20阶段) | 用 `Frame` 重建一次函数调用 | </description>
<pubDate>Fri, 14 Aug 2026 09:59:21 +0800</pubDate>
</item>
<item>
<title>并查集：连通性、路径压缩与进阶变体</title>
<link>https://bytedepth.cn/posts/union-find</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/union-find</guid>
<description>&gt; 并查集（Union-Find / DSU）专门解决“两个元素现在是否属于同一组，以及两组如何合并”。从朋友圈、动态连通性出发，本文逐步推导 `find`、`union`、路径压缩和按大小合并，并解释为何它能做到近似常数时间。 --- ## 目录 | 章节 | 说明 | |------|------| | [先理解问题：不断合并的社群](#先理解问题：不断合并的社群) | 并查集到底在维护什么 | | [并查集这个名字是什么意思](#并查集这个名字是什么意思) | “并”“查”“不相交集合”分别指什么 | | [最小接口：find 与 union](#最小接口：find%20与%20unio</description>
<pubDate>Thu, 13 Aug 2026 18:36:17 +0800</pubDate>
</item>
<item>
<title>日志平台：采集、存储与 SLO 告警</title>
<link>https://bytedepth.cn/posts/logging-collection-alerting</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/logging-collection-alerting</guid>
<description>&gt; 日志平台的目标是以可控成本支持排障、审计和关联分析；告警的目标是发现用户可感知的风险，而不是对每条 ERROR 日志做出反应。本文给出当前可维护的采集、存储和告警基线。 --- ## 目录 | 章节 | 说明 | |------|------| | [架构选择](#架构选择) | Elastic、Loki 与 OpenTelemetry Collector 的适用边界 | | [采集与缓冲](#采集与缓冲) | Agent、Collector、Kafka 的决策条件 | | [结构化日志的交付基线](#结构化日志的交付基线) | Google Cloud 实践抽象出的可移植要求 | | [</description>
<pubDate>Mon, 10 Aug 2026 14:48:28 +0800</pubDate>
</item>
<item>
<title>分布式追踪：OTel、MDC 与异步传播</title>
<link>https://bytedepth.cn/posts/distributed-log-correlation</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/distributed-log-correlation</guid>
<description>&gt; 分布式日志关联的默认解法是 OpenTelemetry 上下文与 W3C Trace Context；MDC 只是把当前上下文投影到日志的桥梁。本文说明两者的分工、异步边界和 Spring Boot 的接入策略。 --- ## 目录 | 章节 | 说明 | |------|------| | [关联模型](#关联模型) | trace、span、request 的职责 | | [默认方案：OTel 与 W3C](#默认方案：OTel%20与%20W3C) | 传播标准和日志关联 | | [MDC 的正确位置](#MDC%20的正确位置) | 生命周期、清理与补充上下文 | | [异步与消息</description>
<pubDate>Mon, 10 Aug 2026 14:48:18 +0800</pubDate>
</item>
<item>
<title>业务与审计日志：领域事件、AOP 与 Outbox</title>
<link>https://bytedepth.cn/posts/business-audit-logging</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/business-audit-logging</guid>
<description>&gt; 业务日志应表达领域事实；审计日志则需要可追溯、可验证且受控地保存操作证据。本文说明两者的边界，以及 Domain Probe 与 Spring AOP 的正确落地方式。 --- ## 目录 | 章节 | 说明 | |------|------| | [三类业务记录](#三类业务记录) | 操作审计、分析事件与变更历史的边界 | | [事件的最小字段](#事件的最小字段) | Who、When、Target、Action、Result 之外还需什么 | | [Domain Probe](#Domain%20Probe) | 用领域语义隔离观测实现 | | [审计日志的可靠性模型](#审计日志</description>
<pubDate>Mon, 10 Aug 2026 14:48:10 +0800</pubDate>
</item>
<item>
<title>日志体系：类型、Schema 与安全基线</title>
<link>https://bytedepth.cn/posts/logging-foundations</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/logging-foundations</guid>
<description>&gt; 日志是可观测性的事件记录，不是调试输出的堆放处。本文定义日志类型、级别、统一字段与安全边界，并给出从应用到平台的职责划分。 --- ## 目录 | 章节 | 说明 | |------|------| | [日志类型与保留目标](#日志类型与保留目标) | 区分运行、业务与审计记录 | | [级别与事件命名](#级别与事件命名) | 选择恰当的严重程度和稳定事件名 | | [统一日志 Schema](#统一日志%20Schema) | 字段、命名和基数约束 | | [Java 编码基线（阿里规约）](#Java%20编码基线（阿里规约）) | 参数化日志、异常与性能约束 | | [应用与平台</description>
<pubDate>Mon, 10 Aug 2026 14:48:00 +0800</pubDate>
</item>
<item>
<title>Quorum 与 NWR：读写一致性权衡</title>
<link>https://bytedepth.cn/posts/quorum-nwr-v0</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/quorum-nwr-v0</guid>
<description>&gt; NWR 模型是分布式存储系统（Dynamo、Cassandra、Riak）中调节一致性与可用性的核心机制。本文深入分析 Read Repair、Hinted Handoff、Sloppy Quorum 的算法细节，并给出 W+R≤N 导致脏读的数学证明和异常场景的完整分析。 **相关文章**：[Paxos 算法](/posts/54) · [Raft 共识算法](/posts/56) · [CRDT（无冲突复制数据类型）](/posts/57) · [Merkle Tree 与反熵同步](/posts/60) --- ## 目录 | 章节 | 说明 | |------|------| | </description>
<pubDate>Mon, 3 Aug 2026 15:49:08 +0800</pubDate>
</item>
<item>
<title>CRDT：无冲突复制的数据类型</title>
<link>https://bytedepth.cn/posts/crdt-v0</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/crdt-v0</guid>
<description>&gt; CRDT（Conflict-free Replicated Data Type）是一类可以在多个副本上独立更新、并在任意时刻自动合并且不产生冲突的数据结构。本文覆盖 G-Counter、PN-Counter、LWW-Register、OR-Set 等核心类型的原理与伪代码，并深入分析网络分区、并发写、消息乱序等异常场景下的行为保证。 **相关文章**：[向量时钟与因果一致性](/posts/55) · [Quorum 与 NWR 模型](/posts/58) · [Merkle Tree 与反熵同步](/posts/60) --- ## 目录 | 章节 | 说明 | |------|---</description>
<pubDate>Mon, 3 Aug 2026 15:49:07 +0800</pubDate>
</item>
<item>
<title>向量时钟：因果关系与并发判定</title>
<link>https://bytedepth.cn/posts/vector-clock-causality-v0</link>
<guid isPermaLink="true">https://bytedepth.cn/posts/vector-clock-causality-v0</guid>
<description>&gt; 分布式系统中没有全局时钟，节点间的事件顺序无法用物理时间判断。本文从 Lamport 时钟出发，推导向量时钟与版本向量，深入分析乱序消息、并发写冲突、网络分区恢复时的合并策略，以及与 HLC 的关系。 **相关文章**：[Raft 共识算法](/posts/56) · [CRDT（无冲突复制数据类型）](/posts/57) · [Hybrid Logical Clock（HLC）](/posts/61) --- ## 目录 | 章节 | 说明 | |------|------| | [为什么物理时钟不够用](#为什么物理时钟不够用) | 时钟漂移与因果性丢失 | | [Lamport 时</description>
<pubDate>Mon, 3 Aug 2026 15:49:05 +0800</pubDate>
</item>
</channel>
</rss>