每天一道题-优快云博客

原创微服务为什么会变慢？从 QPS、P99 到 Trace 与性能瓶颈

Trace 可以理解成一次业务请求在多个服务之间执行的完整轨迹。Gatewayv| || v| MySQLvRedis如果链路追踪信息能够正确跨服务传递，就可以把这些操作关联到同一个 Trace。这个 ID 用于关联此次请求中不同组件产生的执行记录。一个 Trace 通常由多个 Span 组成。Span 表示一次具体操作或某个执行阶段。| |操作名称开始时间结束时间耗时状态父子关系必要的业务或技术属性Span：Status：OK。

2026-10-29 17:46:51 516

原创微服务为什么会发生级联故障？从 Timeout、Retry 到熔断、限流与 Backpressure

这一篇从库存服务变慢开始，逐步解释了级联故障如何发生，以及不同故障治理机制分别解决什么问题。下游服务变慢v上游请求等待v并发资源被占用v请求开始超时v错误重试增加下游压力v故障向更多服务传播针对这条故障链，我们学习了几种保护机制。限制单次调用的等待时间，避免资源长期占用。在合适的条件下恢复短暂故障，但需要控制次数、时间和额外流量。当下游持续异常时，暂时减少无效调用，防止故障继续向上游传播。控制进入系统的请求速率，避免流量超过处理能力。

2026-10-29 17:02:13 622

原创分布式锁真的安全吗？从 Redis 锁、Lease 到 Fencing Token

这一篇从普通互斥锁开始，逐步讨论了 Redis 分布式锁、Lease 和 Fencing Token。多个服务实例需要互斥vv只有一个实例成功获得锁v锁具有有效期v执行可能超过 TTLv旧持锁者可能继续执行vv下游识别旧代次操作其中最需要记住的是以下几个结论。

2026-10-28 17:11:19 292

原创 CAP、Raft 与多数派：分布式系统如何达成一致？

这一篇从网络分区出发，介绍了 CAP、Raft 和多数派。可以把这些概念放在三个层次理解。概念主要解决的问题CAP网络分区时，一致性与可用性存在什么取舍当前应该由哪个节点组织写入Term如何区分不同选举任期怎样让节点复制相同的操作日志什么样的节点集合有资格形成一致决定哪些日志已经正式提交怎样按照统一的已提交日志顺序更新状态其中最重要的是四个结论。

2026-10-27 17:32:03 387

原创为什么本地事务不够用？从分布式事务、Saga 到 Transactional Outbox

回顾这一篇，我们从一个订单场景出发，逐步讨论了本地事务、2PC、TCC、Saga 和 Transactional Outbox。其中最重要的变化，是事务边界从单个数据库扩展到了多个独立系统。BEGINv执行 SQLv数据库可以在自己的事务边界内协调原子提交。Order DBvv每个系统都有独立的执行结果和故障窗口。如果简单认为失败了就能统一ROLLBACK，就很难正确处理已经提交的数据库操作，以及已经发生的真实支付或外部副作用。

2026-10-25 12:54:18 329

原创一台 MySQL 不够用了怎么办？从主从复制、读写分离到分库分表

这一篇从单台 MySQL 的瓶颈出发，逐步介绍了主从复制、读写分离和分库分表。它们可以概括为三个层次。

2026-10-25 12:53:38 285

原创 MySQL 索引到底怎么工作？从 B+ 树、回表到覆盖索引与联合索引

InnoDB 使用 Clustered Index（聚簇索引）组织表数据。对于具有主键的 InnoDB 表，通常使用主键作为聚簇索引的索引键。聚簇索引的叶子节点包含完整的行记录。iduser_idstatusamount10001888UNPAID19910002889PAID29910003888PAID399主键 B+ 树按 id 定位v叶子节点id = 10001id = 10002注意，这里展示的是逻辑内容，并不代表一条记录必然独占一个数据库页。

2026-10-23 16:44:53 378

原创 MySQL 如何保证并发正确？从事务、隔离级别到 MVCC 与锁

这一篇从订单与库存问题出发，逐步讨论了 MySQL 的事务、隔离级别、MVCC 和锁。| | |v v v事务隔离级别并发锁定| | || MVCC || | || | |v v v原子提交一致性快照读取协调并发修改一组数据库修改如何作为整体提交或回滚。多个事务并发执行时，一个事务允许看到其他事务的哪些变化。如何利用历史版本与读取视图，让普通一致性读不必总是等待写入。当事务需要修改数据或锁定当前记录时，如何协调并发操作。

2026-10-23 16:20:42 257

原创 Kafka 为什么会重复消费？从 Producer ACK、Offset 到消息可靠性

通过这一篇，我们把 Kafka 的消息可靠性从生产端一直梳理到了业务执行端。最重要的是理解以下几个结论。第一，ACK 不等于业务成功。Producer 收到 ACK，只说明 Kafka 按对应机制确认了消息写入，不代表 Consumer 已完成业务操作。第二，提交 Offset 不会删除消息。Offset 记录消费者组的消费位置，消息是否保留主要由 Kafka 的日志保留与清理策略决定。第三，先执行业务再提交 Offset，可能重复消费。因为业务系统和 Kafka 的消费进度不是天然同一个事务。

2026-10-22 16:45:58 343

原创 Kafka 是如何工作的？从 Broker、Partition、Offset 到 Consumer Group

回顾这一篇，Kafka 的核心概念其实可以分成三个层次。第一层：消息如何进入 Kafka。Producer 将消息发送到 Topic，Kafka 根据分区规则将消息写入对应的 Partition。Broker 负责提供消息存储与访问服务。第二层：消息如何组织。Topic 是逻辑主题。Partition 是实际的分区日志。Offset 标识一条消息在某个 Partition 中的位置。同一个 Partition 中的消息可以按其日志位置读取，但不同 Partition 之间没有天然的全局顺序。

2026-10-22 15:33:22 205

原创 Redis 缓存为什么会出问题？穿透、击穿、雪崩与缓存一致性

先查 Redisv没有再查 MySQL但真正复杂的地方，不在缓存命中时，而在它没有命中、突然失效或者与数据库状态不一致时。这篇文章最重要的知识可以归纳为四个问题。第一，查询的数据不存在怎么办？这对应缓存穿透，可以通过空值缓存、布隆过滤器等方式减少无效请求回源。第二，一个热门缓存突然失效怎么办？这对应缓存击穿，需要避免大量并发请求同时重建同一份数据。第三，大量缓存一起失效怎么办？这对应缓存雪崩，需要通过 TTL 分散、高可用以及数据库回源保护，防止缓存故障继续影响后端。

2026-10-22 11:19:07 180

原创 Agent 评测应该怎么做？从任务结果到执行过程的四层评测体系

一个常见问题是先确定几十个指标，然后想办法找数据填充。结果虽然形成了评测报表，但很多指标没有真正有效的测试场景。业务目标 → 关键能力 → 测试场景 → 可观察证据 → 评分指标。例如，希望评测 Agent 的异常恢复能力，就应该设计真实的工具异常场景，而不是仅根据正常任务中的工具调用日志进行推断。字段作用Case ID评测任务唯一标识初始环境和业务数据User Goal用户期望完成的目标可使用的工具及权限需要注入的异常或环境变化任务完成后的目标状态必须满足的行为约束。

2026-10-21 17:23:22 1111

原创 Redis 不只是缓存：从数据结构到 TTL、持久化，理解它为什么这么快

这一篇主要建立了 Redis 的基础知识框架。Redis 的价值不只是比 MySQL 更快，而是它提供了适合高频访问的内存数据操作能力。以内存访问为主，适合低延迟的数据操作。提供 String、Hash、List、Set、ZSet 等常用数据结构。通过 TTL 管理 Key 的生命周期。根据内存淘汰策略控制内存压力下的行为。使用 RDB、AOF 等机制提供数据持久化能力。但这些能力需要和业务需求对应起来。商品详情反复查询vRedis 缓存访问量统计v用户去重vSet。

2026-10-21 15:44:01 291

原创 Docker 和 Kubernetes 到底管什么？理解微服务的运行基础

概念主要职责打包应用与运行环境Container镜像运行后形成的容器实例PodKubernetes 最小可部署单元，容纳一个或多个容器Node实际运行 Pod 的工作节点Deployment管理无状态工作负载的副本与更新ReplicaSet维护符合要求的 Pod 副本提供稳定的服务访问入口管理外部进入集群的流量HPA根据指标调整 Pod 副本数量提供应用配置与敏感数据PV / PVC管理持久化存储资源与申请管理需要稳定身份和存储关联的工作负载。

2026-10-21 14:09:00 253

原创微服务之间如何通信？从 RPC、服务发现到 Gateway

微服务从单体拆分出来后，最直接的变化就是原来的进程内调用变成了跨进程、跨网络的服务通信。围绕这个变化，才逐渐出现了 RPC、服务发现、负载均衡和 Gateway 等配套机制。回头看，这些技术其实分别在回答几个简单的问题。服务之间如何交换信息？可以选择 HTTP/REST、gRPC 或异步消息机制。调用方如何找到目标服务？依靠服务注册发现、DNS 或平台提供的服务网络能力。目标服务有多个实例时，怎么选择？依靠负载均衡机制。外部请求怎样统一进入系统？通过 API Gateway 等入口组件。

2026-10-20 16:43:55 808 1

原创从单体到微服务：Service、Instance 与服务拆分到底是什么关系？

回顾这一篇，几个概念需要明确区分。概念核心含义Monolith多个业务模块作为一个整体构建和部署围绕业务能力组织、可独立运行和演进的服务Service一组明确的业务职责与对外能力Instance某个 Service 实际运行中的一个副本为现有服务增加运行实例调整业务职责及数据所有权的边界保持模块边界，但仍统一部署的架构这几个概念中，我认为最容易弄混的是 Service 和 Instance。例如一个订单系统只有一个 Order Service，但它可以运行十个实例。

2026-10-20 15:54:05 276 1

原创 Transactional Outbox：分布式系统里，如何解决“业务成功了，消息却丢了”？

如果只从代码上看，Transactional Outbox 其实很普通。多写一张表多跑一个 Worker但它真正有价值的地方，是改变了我们处理分布式一致性的方式。然后赶紧 Publish Message希望中间别出问题我不要求这一刻就成功通知所有系统。我先保证：“这个事件必须被发送”这件事情不会因为进程 Crash 而消失。瞬时动作持久化状态RetryRecoveryReplay这也是为什么 Outbox 不只是一个“微服务设计模式”。异步 Worker任务队列Workflow。

2026-10-10 16:53:05 143

原创 Agent 评测的关键，不是给它出难题，而是让它做选择

以前理解 Agent 评测，我也容易把注意力放在 Benchmark、任务成功率、工具调用准确率这些东西上。但深入看了一些研究之后，会发现评测设计本身可能比评分方式更重要。如果任务没有真正的依赖关系，就很难考察连续规划。如果所有信息都已经给出，就很难考察主动探索和澄清。如果失败之后不给任何有效反馈，就很难判断 Agent 是否具备恢复能力。如果每次调用失败都让测试直接结束，就无法观察它如何调整策略。如果任务永远可以执行，就无法知道它什么时候会主动停止。

2026-10-10 16:09:51 460

原创从源码看 Codex Harness：一个 Coding Agent 到底是怎么运行的

Codex 的核心不在模型调用工具，而在于其精密的 Harness 框架。它通过 Session、Turn、Step 分层管理任务状态，用 StepContext 保证模型决策与执行环境一致，通过 WorldState 抽象出模型可见的世界，并实现权限控制、上下文压缩、崩溃恢复等工业级能力。这些设计揭示了构建可靠 Agent 的关键：不仅是 prompt 工程，更是系统级的状态与执行管理。

2026-09-16 17:03:57 238

原创大模型评测到底怎么做：从“跑分”到真正驱动模型迭代

很多评测体系的问题，其实在第一步就埋下了。Correctness（正确性）Faithfulness（忠实度）Task Success（任务成功率）看起来什么都有，但跑完以后只得到一个 78 分，仍然不知道模型究竟哪里差。更合理的做法，是先从真实应用场景往下拆 Capability（能力）。通用模型能力├── Knowledge（知识）├── Reasoning（推理）├── Instruction Following（指令遵循）├── Coding（代码）

2026-08-29 17:34:29 341

原创从 async/await 到幂等恢复：把 Python 并发和 Agent Runtime 一次讲清楚

回头看，进程、线程和协程其实都不难。进程提供隔离和多核执行边界。线程提供共享内存中的执行能力。协程负责把 I/O 等待时间重新利用起来。Lock 保护临界区。Semaphore 控制资源并发。Queue 提供缓冲和 Backpressure。Event 负责状态通知。任务一旦开始并发，就会产生完整的生命周期。正在运行正在等待已经取消已经超时正在重试远端成功但本地不知道Worker 已经死亡租约已经过期消息正在重新投递谁拥有这个任务？它现在是什么状态？

2026-08-24 22:39:41 334 1

原创为什么 Agent 评测不能只看最终答案：我对 Agent Eval 的一些工程化理解

前面拆这么多指标，并不是说最后不要一个总指标。还是需要。Task Success（任务成功）例如用户要求：帮我订一家今晚 7 点、4 人、距离公司 3 公里以内的川菜馆。餐厅符合要求AND时间 = 19:00AND人数 = 4AND预约真正创建成功AND不存在 Critical Forbidden Fact系统到底好不好。为什么不好。这两种指标一个都不能少。ModelUser QueryToolsMemoryPermissionAgent 的执行轨迹就可能发生很大变化。

2026-08-22 16:00:36 351 1

原创我们可能一直低估了 Agent Harness：真正决定 Agent 能力的，已经不只是模型

过去一段时间，我对 Agent 的关注点其实发生了明显变化。模型选哪个？Prompt 怎么写？Function Calling 准不准？Planner 怎么设计？Tool 为什么可以被执行？错误参数为什么没有被拦住？任务状态到底存在哪里？程序崩溃以后怎么继续？Tool 执行一半怎么办？上下文爆炸怎么办？子 Agent 的 Context 怎么隔离？模型为什么有权限访问这个文件？这条 Agent 轨迹能不能 Replay？Harness 改了一版以后，怎么证明它没有退化？

2026-08-21 17:20:56 629