事务

副标题 / 摘要 Saga 是一组本地事务的流程编排，补偿是失败后的回滚手段。本文解释二者关系与工程实践。 目标读者 设计跨服务流程的工程师 需要理解一致性策略的团队 架构与技术负责人 背景 / 动机 分布式系统不适合强一致长事务。 Saga 通过补偿机制实现“最终一致”。 核心概念 Saga：多个本地事务组成的流程 补偿操作：失败后执行的逆操作 编排/协作：流程驱动方式 实践指南 / 步骤 为每个步骤设计补偿动作 明确补偿是否可逆与可重复 记录流程状态与执行日志 处理部分失败与重试 可运行示例 # 订单流程：创建 -> 扣库存 -> 失败补偿 state = [] def step(name): state.append(name) def compensate(name): print("compensate:", name) def run(): try: step("create_order") step("reserve_stock") raise RuntimeError("fail") except Exception: while state: compensate(state.pop()) if __name__ == "__main__": run() 解释与原理 Saga 描述的是完整流程，而补偿是其中一部分“逆向操作”。 没有补偿，Saga 就无法在失败时回滚。 ...

副标题 / 摘要 长期事务会长时间占用资源、锁与连接，导致系统吞吐下降。Saga 用补偿机制更符合分布式现实。 目标读者 负责分布式事务的后端工程师 设计跨服务流程的架构师 需要权衡一致性与可用性的团队 背景 / 动机 在 SOA 或微服务中，一个业务流程可能跨多个系统。 传统的长期事务会锁住资源，导致性能与可用性问题。 核心概念 长期事务：跨服务长时间持锁 Saga：一系列本地事务 + 补偿操作 补偿：失败后用反向操作修正状态 实践指南 / 步骤 把业务拆成可独立提交的步骤 为每个步骤设计补偿动作 用编排或协作方式驱动流程 记录状态，支持重试与恢复 可运行示例 # 简化 Saga：下单 -> 扣库存 -> 扣款 def reserve_stock(): return True def release_stock(): print("compensate: release stock") def charge_payment(): raise RuntimeError("payment failed") def refund_payment(): print("compensate: refund") def run_saga(): try: if not reserve_stock(): return False charge_payment() return True except Exception: release_stock() refund_payment() return False if __name__ == "__main__": print(run_saga()) 解释与原理 长期事务依赖全局锁与强一致，会在高并发场景中放大等待与失败率。 Saga 把事务拆小，允许最终一致，从而提高可用性。 ...

副标题 / 摘要 事务像“要么全部成功，要么全都不做”的规则。本文用简单故事解释它。 目标读者 需要做科普的开发者 初学者与非技术读者 想更好解释概念的工程师 背景 / 动机 事务看起来抽象，但可以用生活中的“成套动作”来理解。 比如“付钱和拿到东西”必须一起完成。 核心概念 原子性：要么全部成功，要么全部失败 一致性：规则必须被遵守 持久性：完成的结果不会消失 实践指南 / 步骤 讲一个买糖果的故事 强调钱和糖果必须同时完成 如果其中一步失败就取消 说明成功后结果不会被抹掉 可运行示例 # 简化事务示意：买糖果 def buy(cash, candy_price): if cash < candy_price: return cash, 0 # 失败，什么都没发生 return cash - candy_price, 1 # 成功，钱少了糖果多了 if __name__ == "__main__": print(buy(5, 3)) print(buy(2, 3)) 解释与原理 事务就是“成套动作必须一起完成”。 这样可以避免“钱扣了但糖果没给”的情况。 常见问题与注意事项 事务一定很慢吗？ 不一定，但确实需要更多保障。 所有操作都需要事务吗？ 不需要，只有关键操作才用。 事务与锁有关系吗？ 有，锁保证并发安全。 最佳实践与建议 用生活例子解释复杂概念 强调“要么全做，要么不做” 对关键操作使用事务 小结 / 结论 事务就像一套必须一起完成的动作。 它让系统在出错时也能保持正确。 参考与延伸阅读 数据库事务基础 ACID 原理 元信息 阅读时长：5~7 分钟 标签：事务、科普 SEO 关键词：事务解释, ACID 元描述：用儿童类比解释数据库事务。 行动号召（CTA） 尝试用“现实故事”解释一个复杂技术概念给身边的人。

副标题 / 摘要 当底层系统不支持事务时，你仍然需要一致性保障。本文给出从应用层实现“类事务”的核心思路。 目标读者 需要保证数据一致性的后端工程师 构建存储系统或中间层的开发者 负责业务可靠性的技术负责人 背景 / 动机 没有事务意味着更新失败会留下不一致状态。 在关键业务中，必须通过应用层补偿或日志保证正确性。 核心概念 写前日志（WAL）：记录意图，支持回滚 锁/隔离：防止并发冲突 补偿事务：失败后反向修复 实践指南 / 步骤 为关键操作记录意图日志 设计回滚逻辑与补偿函数 用锁或版本号避免并发冲突 定期对账，检测异常状态 可运行示例 # 简化的“事务”示例：使用回滚日志 class Txn: def __init__(self, store): self.store = store self.log = [] def set(self, key, value): self.log.append((key, self.store.get(key), value)) def commit(self): for key, _, value in self.log: self.store[key] = value def rollback(self): for key, old, _ in reversed(self.log): if old is None: self.store.pop(key, None) else: self.store[key] = old if __name__ == "__main__": store = {"a": 1} tx = Txn(store) tx.set("a", 2) tx.set("b", 3) tx.rollback() print(store) 解释与原理 通过记录“修改前状态”，可以在失败后回滚。 这模拟了事务中的“原子性”，但要自己处理并发与持久化。 ...

副标题 / 摘要 ACID 是关系型数据库事务的核心语义。本文解释原子性、一致性、隔离性、持久性，并说明工程上的取舍。 目标读者 使用关系数据库的后端工程师 需要理解事务语义的开发者 负责数据可靠性的技术负责人 背景 / 动机 事务保证系统在故障与并发条件下保持一致性。 不了解 ACID，会导致错误的并发假设与数据不一致。 核心概念 原子性（Atomicity）：要么全部成功，要么全部失败 一致性（Consistency）：事务前后保持约束成立 隔离性（Isolation）：并发事务互不干扰 持久性（Durability）：提交后结果持久保存 实践指南 / 步骤 选择合适隔离级别（读已提交/可重复读等） 明确业务一致性约束（唯一性、外键、余额不为负等） 在关键路径使用事务 避免事务过大，减少锁竞争 理解数据库的实现细节（MVCC/日志） 可运行示例 BEGIN; UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE accounts SET balance = balance + 100 WHERE id = 2; COMMIT; 解释与原理 ACID 的核心是“在并发与故障下保持一致性”。 实现依赖日志、锁、MVCC 等机制，因此隔离性往往伴随性能成本。 常见问题与注意事项 一致性一定由数据库保证吗？ 不一定，业务规则也需应用层保证。 更高隔离级别一定更好吗？ 不一定，可能造成性能下降与锁等待。 NoSQL 就没有 ACID 吗？ 有些系统支持局部 ACID，但往往有取舍。 最佳实践与建议 事务只包围必要的关键操作 明确隔离级别，避免误解 用监控观察锁等待与事务时长 小结 / 结论 ACID 是事务语义的基石，但并不等于“免费”。 在一致性与性能之间需要做工程取舍。 参考与延伸阅读 PostgreSQL Transaction Isolation MySQL InnoDB MVCC Database System Concepts 元信息 阅读时长：7~9 分钟 标签：ACID、事务、数据库 SEO 关键词：ACID, Transaction, Isolation 元描述：解释 ACID 的四个属性及工程意义。 行动号召（CTA） 检查一次核心交易逻辑的事务边界，看看是否覆盖了所有一致性约束。