事务一致性简述

  服务化之后，事务一致性需要得到保证。具体要视业务场景选择合适的方案保证事务的一致性。

  数据库事务的ACID特性，分别含义如下：

  A:  指原子性，即一个事务下的n个复合操作，要么全部成功，要么全部失败。

  c：指的是一致性，即要求事务做完后，要求满足数据库的一些完整性约束，如：记录的主键约束。从业务层理解是：A帐户转钱给B帐户100元钱，这时数据库事务就必须保证A帐户钱减100,B帐户加100,且最终a,b帐户余额也是正确的。

 i： 指的隔离性，指的是一个事务未提交的业务结果是否对于其它事务可见。级别一般有：read_uncommit，read_commit，read_repeatable，串行化访问。

 d：指的是持久性。即事务操作完后，事务的结果应该是持久化的。

  传统数据库，如mysql，oracle一般采用日志来保证事务的acid特性。事务acid在单个数据库时比较容易满足。即只要将a,b,c三个业务操作放在一个事务中执行，之后的acid特性由数据库底层保证。

  而当服务化后，多个业务操作会涉及多台服务器，多个数据库存储。这就需要有相应的手段保证业务操作在多个数据库中的一致性。

  分布式服务事务比较有名的cap理论，提供了一种在分布式服务中事务设计的一种思路。

  cap理论中的c指的是，从任意多个结点（如多个数据库），它们上面的数据副本应该是一致的。a指的是对于［更新数据的服务］的可用性。

  p指的是分区的情况。

 简单来讲cap指的是无法同时满足cap三者。这样在有p分区的情况下，需要我们在c和a间做一个平衡。

 

  举例来讲，电商中，要购买一件产品，假设有：Ａ操作－扣除产品份额，b操作－支付扣用户帐户钱，c操作将产品加到用户资产。

  这个就是典型的一种分布式服，由于a,b,c操作分别调用三个服务。而当操作a，b, c时都可能发生网络超时会数据库等错误。这样会导致a,b,c操作会处于不一致状态。

  如a操作－扣款产品份额成功，b操作超时，这时就发生了分区的情况。因为b操作－支付可能成功也可能失败，此时系统已经发生不一致的情况。

  此时我们一般使用事务补偿机制来做，即后台一个线程会扫描此笔交易，发现b支付操作如果成功，则更新订单为成功，做c操作。

  如果b支付操作失败，则回滚a操作。

  如果b支付操作为操作中，则回滚a操作产品扣份额。此笔订单之后再做处理。直到明确得到支付结果再执行正向提交操作，或逆向回滚操作。