5 posts tagged with "Distributed Systems"

真正可靠的任务看板，不是“WebSocket 一直在线”，而是：状态先成为可恢复的事实，通知只负责让事实更快到达，任何一层短暂故障后都能重新收敛到正确状态。

文件解析、AI 生成、视频转码、报表导出这类异步任务，通常会经过多个服务和步骤。用户真正关心的往往不是复杂的工作流编排，而是几个朴素问题：

• 我的新任务是否已经创建？
• 当前是等待、运行、成功，还是失败？
• 当前由哪个服务执行什么功能，不同功能的数据该如何展示？
• 哪个步骤正在执行，已经用了多久？
• 步骤失败、自动重试或执行器失联时，用户如何收到明确告知？
• 页面断线、刷新或切到后台后，会不会永远停在旧状态？
• 服务多副本、节点重启、网络闪断时，状态通知是否仍能恢复？

本文设计一套专注于任务状态、步骤状态和耗时展示的生产链路。它不负责启动下一步、不替代工作流引擎，也不把实时消息系统当数据库。

最终方案可以概括为：

Business API 创建 workflowId 与独立 taskId
  → Worker 按 taskId 上报状态
  → Task Status Service 事务校验与落库
  → 同事务写 MySQL Outbox
  → Outbox Relay 领取并调用 Centrifugo 发布
  → 用户摘要频道 + 任务详情频道
  → 前端按 version 合并
  → 恢复失败时重新读取数据库快照

零拒绝不是稳定性目标。系统超过容量时，及时拒绝一部分请求，才能保护已接纳请求和故障恢复能力。

本期专门处理“流量大于处理能力”。我们把限速、限并发、队列、重试和熔断放进同一个反馈系统，而不是堆叠互不理解的中间件。

图（Graph）不仅仅是一种数据结构，更是一种看待世界联系的思维方式。在海量数据的今天，简单的关系型数据库已难以应对复杂的关联查询。

本文旨在重塑你对图算法的认知。我们采用渐进式深度的设计，从最直观的遍历开始，逐步深入到复杂的结构分析，并最终探讨工业级的图存储方案。

"The best notebook is not just a place to store information, but a thinking partner that understands context and helps you reason."

Google NotebookLM 展示了 AI 如何革新我们的知识管理方式。本文将详细设计一个开源替代方案，使用现代化技术栈构建一个高性能、可扩展、生产级的智能笔记系统。

"写 Demo 很简单，但理解框架底层才能不被生产事故打个措手不及。"

在 上一篇 中，我们深度解构了 gRPC 的灵魂——HTTP/2 协议。 本文将落地到 Java 实现层，带你剥开 grpc-java 的源码，理解 Netty 线程模型和跨语言调用的实践。