Excalidraw描述分布式事务：一致性方案对比
在微服务架构大行其道的今天，一个简单的电商下单操作，可能牵动订单、库存、支付、物流等多个独立服务。每个服务都有自己的数据库，彼此之间通过网络通信协作——这正是现代系统的强大之处，也是其复杂性的根源。
当用户点击“提交订单”时，我们期望的是：要么所有环节都成功完成，形成一笔完整的交易；要么任何一个环节失败，整个流程都能回退到初始状态，避免出现“钱付了但库存没扣”或“订单创建了却无法发货”的尴尬局面。这种跨服务、跨数据源的一致性保障，就是分布式事务的核心命题。
传统的数据库事务（ACID）在单体应用中游刃有余，但在分布式的环境下却显得力不从心。网络延迟、节点宕机、分区故障……这些不可靠因素让“强一致性”变得代价高昂甚至不可实现。于是，一系列基于CAP理论和BASE原则的新模式应运而生：2PC、TCC、Saga、消息队列最终一致性等。它们不再追求瞬时的绝对一致，而是通过补偿、异步、重试等机制，在可接受的时间窗口内达成“最终一致”。
然而，问题来了：如何让团队中的每个人——无论是后端开发、测试工程师，还是略懂技术的产品经理——都能快速理解这些抽象的设计逻辑？口头解释容易遗漏细节，文字文档枯燥难懂，而传统绘图工具又过于正式和笨重，难以支持快速迭代的讨论过程。
这时候，一个看似“简单”的工具开始展现出惊人的潜力：Excalidraw。
它没有复杂的菜单栏，也没有华丽的模板库，界面就像一张空白的草稿纸。但正是这种极简的手绘风格，消除了人们对“画得不够专业”的心理负担，鼓励人们大胆地把想法“扔”到画布上。更重要的是，它支持实时协作和AI辅助生成图表，使得技术沟通从“我说你听”变成了“我们一起画”。
想象一下这样的场景：你在远程会议上提出要用Saga模式处理订单流程。你只需在Excalidraw中输入一句：“画一个包含订单、库存、支付服务的Saga流程图，失败时触发逆向补偿。” 几秒钟后，一幅结构清晰的初稿就出现在白板上。你们围在这幅“草图”周围，一边讨论一边拖动元素、添加注释、修改箭头方向。十分钟内，一个经过集体确认的设计方案就成型了，并且所有人都参与其中、心知肚明。
这就是Excalidraw的魅力所在——它不是为了产出一份精美的交付物，而是为了加速那个最关键的阶段：从模糊概念到共同认知的转化过程。
它的底层其实相当扎实。前端基于React + TypeScript构建，图形渲染依赖Canvas API，保证了流畅的交互体验。多用户实时协作则通过WebSocket结合CRDT（无冲突复制数据类型）或OT（操作变换）算法实现，确保即使多人同时编辑，也不会出现数据冲突或丢失。每一个矩形、每一条箭头、每一行文本，都被序列化为JSON对象，在客户端之间高效同步。
更值得称道的是它的AI能力。当你输入自然语言指令时，系统会调用大型语言模型（LLM）来解析语义，识别出关键实体（如“订单服务”）、动作（如“扣减库存”）、流程关系（如“然后”、“如果失败则”），并将其转化为Excalidraw可识别的元素结构。这个过程并非完美无缺，但它提供了一个强大的起点，让你不必从零开始布局。
比如下面这段代码，展示了如何将Excalidraw嵌入一个自定义网页，预加载一个初始的分布式事务设计模板：
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <title>Embedded Excalidraw</title> <script type="module"> import { Excalidraw } from "https://cdn.jsdelivr.net/npm/@excalidraw/excalidraw@0.15.0/dist/excalidraw.min.js"; window.addEventListener("load", () => { const excalidrawContainer = document.getElementById("excalidraw"); new Excalidraw(excalidrawContainer, { initialData: { appState: { viewBackgroundColor: "#ffffff", }, elements: [ { type: "rectangle", x: 100, y: 100, width: 200, height: 80, strokeColor: "#000000", backgroundColor: "#ffcccb", roughness: 2, }, { type: "text", x: 130, y: 130, text: "Order Service", fontSize: 20, }, { type: "arrow", x: 300, y: 140, points: [[0, 0], [60, 0]], startArrowhead: null, endArrowhead: "arrow", } ], }, }); }); </script> </head> <body> <h2>Distributed Transaction Design Board</h2> <div id="excalidraw" style="height: 600px; border: 1px solid #ccc;"></div> </body> </html>这段代码虽然简短，却揭示了一个重要的可能性：你可以把Excalidraw变成自己内部技术平台的一部分。比如，构建一个“一致性方案设计器”，让团队成员选择某种模式（如TCC），系统自动加载对应的图形模板，再由人工细化业务逻辑。这不仅提升了效率，也保证了设计规范的统一。
那么，具体怎么用它来表达那些复杂的分布式事务模式呢？
以Saga模式为例。它本质上是一个长事务的拆解：把一个全局事务分解成一系列本地事务，每个步骤完成后发布事件，驱动下一步执行；一旦某步失败，则按相反顺序执行预先定义的补偿操作。
在Excalidraw中，你可以这样呈现：
- 横向排列多个服务框（订单、库存、支付），模拟微服务架构。
- 纵向作为时间轴，向下表示流程推进。
- 使用绿色实线箭头表示正向执行路径。
- 当某步失败时，用红色虚线箭头反向标注补偿动作，如“退款”、“释放库存”。
- 添加注释框说明关键约束，例如“补偿必须幂等”、“需记录事务日志”。
如果你不想手动绘制，可以直接对AI说：“生成一个电商下单的Saga流程图，包含三个步骤和对应的补偿操作。” 它会迅速给出一个可用的框架，你只需要微调即可。
类似的，对于TCC模式，你可以画出三个明显的阶段：
- Try：资源预冻结，比如锁定库存；
- Confirm：真正提交，扣除库存；
- Cancel：取消操作，释放锁定。
用不同颜色区分正常路径与异常路径，再用条件判断框（如“是否超时？”）连接分支，整个流程一目了然。相比纯文字描述“Try阶段要预留资源”，图形直接告诉你“预留”发生在哪一步、影响哪些服务。
而对于经典的两阶段提交（2PC），尽管它因阻塞和单点故障问题在跨服务场景中已较少使用，但仍适用于数据库集群内部。在Excalidraw中，你可以清楚地标出协调者与参与者之间的两轮通信：第一阶段“准备投票”，第二阶段“全局提交或回滚”。旁边加个醒目的黄色警告框：“注意！协调者宕机会导致所有参与者长期阻塞。”
甚至可以做一个横向对比图，直观展示各种方案的优劣：
| 方案 | 一致性强度 | 性能影响 | 实现复杂度 | 适用场景 | 关键注意事项 |
|---|---|---|---|---|---|
| 2PC | 强一致性 | 高延迟，阻塞 | 中等 | 数据库集群内事务 | 协调者单点故障风险高 |
| TCC | 最终一致 | 较低延迟 | 高 | 高并发金融交易 | 必须实现Try/Confirm/Cancel接口 |
| Saga | 最终一致 | 异步高效 | 中等 | 跨服务长事务 | 补偿操作必须幂等 |
| 消息队列 | 最终一致 | 高吞吐 | 低 | 日志类、通知类操作 | 无法保证严格顺序 |
这张表本身就可以画在Excalidraw里，配合旁边的流程图，形成完整的决策依据。
更有意思的是，这些图表不仅仅是静态展示。借助Excalidraw的API，我们可以编写脚本动态生成常见模式的模板。例如下面这个JavaScript函数，能自动生成一个标准的Saga流程图：
function createSagaDiagram(excalidrawInstance) { const services = ["Order", "Inventory", "Payment"]; const xSpacing = 150; const startY = 100; const elements = []; // 绘制服务栏 services.forEach((service, index) => { const x = 100 + index * xSpacing; // 服务标题 elements.push({ type: "text", x: x, y: startY, text: service, fontSize: 16, fontWeight: 600, }); // 本地事务框 elements.push({ type: "rectangle", x: x - 40, y: startY + 30, width: 80, height: 40, strokeColor: "#2d5a27", backgroundColor: "#c8e6c9", }); elements.push({ type: "text", x: x - 30, y: startY + 50, text: "Local Tx", fontSize: 14, }); // 连接箭头（正向） if (index < services.length - 1) { elements.push({ type: "arrow", x: x + 40, y: startY + 50, points: [[0, 0], [xSpacing - 80, 0]], endArrowhead: "arrow", }); } }); // 失败补偿路径（反向） for (let i = services.length - 1; i > 0; i--) { const x = 100 + i * xSpacing; elements.push({ type: "arrow", x: x - 40, y: startY + 90, points: [[0, 0], [-(xSpacing - 80), 0]], strokeColor: "#d32f2f", endArrowhead: "bar", }); elements.push({ type: "text", x: x - 100, y: startY + 70, text: `Compensate ${services[i]}`, fontSize: 12, strokeColor: "#d32f2f", }); } // 更新画布 excalidrawInstance.updateScene({ elements }); }这个函数不仅能节省重复劳动，还能作为团队内部自动化设计工具的基础模块。每次新建Saga设计任务，一键生成标准结构，再由设计师填充具体业务逻辑，极大提升了规范性和效率。
在实际工作流中，Excalidraw通常扮演着“设计中枢”的角色：
需求明确后，架构师先在白板上勾勒出大致流程；接着利用AI快速生成候选方案；然后在评审会议中共享链接，所有人实时标注疑问和建议；根据反馈不断迭代优化；最后导出为PDF或SVG嵌入Wiki归档，成为后续开发的依据。
它解决了太多现实痛点：新人看不懂晦涩的文字协议？看图就行。远程协作时信息不同步？所有人看到的是同一块实时更新的白板。讨论中漏掉了某个异常分支？可视化之后，明显能看到“这里没有补偿路径”。
当然，用好它也需要一些实践智慧：
- 保持简洁：不要堆砌装饰性元素，重点是传达逻辑而非美观。
- 约定符号规范：比如实线代表主流程，虚线代表异常，红色代表补偿，蓝色代表查询。
- 重视版本管理：虽然Excalidraw本身不提供版本控制，但你应该定期导出快照并命名存档，如
saga-v1.2.excalidraw。 - 注意隐私安全：涉及核心业务逻辑时，优先使用自建实例，避免通过公共链接分享敏感信息。
说到底，Excalidraw的价值远不止于“画图”。在这个系统日益复杂、协作半径不断扩大的时代，我们需要的不仅是更强的计算能力，更是更高的认知效率。而Excalidraw所做的，正是降低技术表达的门槛，让抽象的分布式逻辑变得可视、可议、可迭代。
一张手绘风格的草图，或许看起来不够“正式”，但它承载的是一群人共同的理解与共识。当我们在白板上画下一个箭头、圈出一个问题、标出一个补偿动作时，我们不只是在绘制流程，更是在构建一种共享的思维语言。
而这，恰恰是应对复杂性的最有力武器。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
