关于乐观事务与悲观事务的通俗解释

　　近期看到有些同学，特别是在分布式数据库学习的初期过程中，对乐观事务（Optimistic Transaction)与悲观事务（Pessimistic Transaction)的概念有所疑问，或者说不能真正理解其涵义。而相关文档，大多都是技术性描述及技术流程的介绍，例如＂乐观事务在事务提交时检查冲突＂、＂并发事务不常修改同一行时，可以跳过获取行锁的过程进而提升性能。但是并发事务频繁修改同一行（冲突）时，乐观事务的性能可能低于悲观事务。＂，以及两阶段提交过程的算法式描述。虽然客观上问题已经说的很清楚了，但对于那些对分布式事务没有特别深入掌握，或者没有实操编程经验的人来讲，还是很难得到正确、清晰的理解，有相当一部分技术人停留在＂乐观事务比悲观事务更宽松一些＂的理解层面上，甚至有相当一部分人认为乐观事务会对事务的执行结果做出一定妥协，如互联网行业中一些不需要强事务的场景一样，允许得出一个折衷的结果。
　　因此，本文面向初学者，特对乐观事务与悲观事务作以尽量形象易理解的解释。
　　首先，需要强调的是，必须清楚：无论是乐观事务，还是悲观事务，其事务的执行结果都是一样的，即一个事务中的操作，对ACID级别的要求，完全一样，无论是原子性、一致性、隔离性或者持久性，都是完全一致，不存在乐观事务就宽松一些，悲观事务就严格一些的情况。
　　在此基础上，再来理解两种事务类型，其实：最为直接有效准确的方法，就是纯字面理解。所谓乐观事务，就是指执行者在执行前对事务的估计＂乐观＂一些时选用它，悲观事务就是执行者在执行前对事务的估计＂悲观＂一些时选用它。怎么解释呢？当编程者用分布式数据库来处理事务需求时，需要对所面对业务的状态有一个判断：就是并发事务的写冲突是否频繁？如果判断不频繁，就是＂乐观＂，应该用乐观事务方法；如果判断频繁，就是＂悲观＂，应该用悲观事务方法。而无论选择＂乐观＂还是＂悲观＂，都只是根据实际面对的问题选择一个尽量效率高的两阶段提交执行策略，而不是对事务结果的妥协。
　　这里举一个形象的例子。比如我们国家进行核酸检测，有报道说在很短时间内就检测了几千万次，其效率之高很惊人！这其实就是用到了类似乐观事务的执行策略：我们事先判断感染的人数比例是很少的，因此就采用批量检测的方案，就是把很多待检测样本混成一个批次，一个批次做一次检测，只有当检测到有感染的批次，才对那个批次进行单个的分拆检测。由于感染的人数非常小，因此大部分批次的检测都是合格的，不合格的批次只是少数，因此比全样本单个检测效率高很多。但可以想见，如果实际的情况是感染人数比例很高（悲观），那么，这种基本乐观判断的批次检测策略就明显会比单个检测更慢。在这个例子中，如果对感染人数是乐观判断，就采用＂乐观＂的处理方案：批量检测；如果对感染人数是悲观判断，就采用＂悲观＂的处理方案：单个检测。但无论什么检测方法，都不能对检测的准确度做出任务妥协：一个都不能放过！当然，这个例子并不是说乐观事务就是用批处理方法来处理事务，而是对基于乐观判断的策略选择做以形象的解释。
　　这就是乐观事务与悲观事务的区别，它只是两阶段提交基于待处理业务状态的不同执行策略，其选择基于执行者的判断，其效率高低基于被处理业务的实际状态（并发事务的写冲突频繁度），而其结果则是完全一样的。