浅谈事务理解

用语	解释
查询	泛指针对数据记录而执行的操作（，而非特指select）。
逻辑单元	在功能或语义上紧密相关、共同完成某个特定任务的一组代指令。
领域	人类知识或活动的逻辑边界。
事务	所做的或要做的事情。
业务	为特定群体创造价值而展开的活动。这些活动会受到所在行业（和企业）的规则和流程所约束。
业务领域	强调业务的范畴。
用例	系统响应外部请求的潜在场景。定义角色与系统之间的交互步骤，和明确操作目的。
原子性	不可分割的整体。在软件开发中，通常用来表达一种“要么同时成功，否则就应该同时失败”的语义。
准确性	一种衡量计算结果与真实结果之间的差异的度量概念。
一致性	关于“一致性”一词，在不同的上下文中会有不同的解释。此处可理解为确保数据的约束规则不会遭到破坏。
数据完整性	在数据的整个生命周期内，维护和保证其准确性和一致性。
最终一致（性）	无法马上确保数据完整性，但承诺最终会做到这一点（只是时间上会稍有延迟）。

在谈论事务之前，务必先搞清楚事务到底是一个什么概念。或者说，应该从什么角度来理解它才更为妥当。譬如技术人员谈论事务时，通常谈论的是数据库事务。此时可将事务理解为是数据库查询的逻辑单元。它由一到多个查询组成，是一个不可分割的整体。而对于业务人员而言，他们谈论的其实是业务领域事务。此时事务代表着一个完整的业务范畴。例如对于电商行业而言，顾客的购物过程就属于一个事务。它涵盖了选择商品、加入购物车、下单、支付、商家发货、签收、评价等流程。

对于系统设计而言，事务其实是一种保证系统正确性的机制。作为设计者，我们应该关心的是应用事务。应用事务通常以系统用例为逻辑边界；它真正关心的是请求处理过程的原子性。如果进程能够独自完成事务，那么可将其称为本地事务，否则就属于分布式事务。前者通常可以直接透过数据库事务来实现，而后者则需要依赖特定的原子提交协议¹或设计模式才能解决。

重点注意。缺乏经验的设计者经常存在一个误区，认为系统必须实现应用事务才能确保数据完整性。然而并非如此。是否需要（应用）事务，其实完全取决于用例本身的严谨程度。通常情况下，只有涉及到金钱、健康、安全、决策等问题时，系统才会对数据完整性要求苛刻。而在数据完整性要求不高的用例中（如 社交网络、内容系统、数据分析），事务机制就不是必须的。因为即便处理过程发生意外，但最终也会因为重新计算而达到最终一致。

Atomic commit ↩︎