异步化和缓存原则

异步化和缓存两个技术都与系统的性能有很大的关系，当今分布式应用架构，如果不能很好的掌握这两项技术，所设计出的应用将很难有优质的性能表现。

这里将介绍的是：

分布式架构中，如何通过业务流程异步化，  也就是通过服务异步调用的方式让业务流程中业务逻辑上允许同步执行的服务同时被调用，从而解决了大量远程服务线性调用带来的性能问题。

接着介绍数据进行分库分表后，数据在进行异步操作的场景下，阿里采用哪些事务处理方式实现该场景下事务一致性与数据库处理性能的平衡

最后说明缓存技术在此类场景中扮演的重要角色

业务流程的异步化

平台进行服务化后，在平台页面上发起的业务请求势必需要将后端不同的服务进行组合调用来实现业务请求的处理。如果顺序调用会造成一次前端请求所花的时间较长，给服务的会话处理线程带来长时间的资源占用。对于服务器整体的系统吞吐量带来巨大的影响。一般都会想到以异步化方式将交易创建过程中，对于有严格先后调用关系的服务保持顺序执行，对于能够同步执行的所有服务均采用异步化方式处理。阿里巴巴内部使用消息中间件的方式实现了业务处理流程，提高服务的并发处理。

通过异步化被分割的两部分逻辑处理并没有太多事务性的关系，即一般是前面部分的逻辑处理成功后，后面那部分是否成功执行不会对前一部分的处理结果产生影响。

回到示例中的淘宝订单创建场景，除了调用一些库存检查，用户校验这样一些从数据读取数据进行业务判断的服务外，还会出现如预减库存，订单生成，支付生成等这些对数据库进行数据修改的操作的服务。而订单生成的服务属于交易服务中心的范畴，预减库存则属于商品服务中心提供的服务，支付记录还要调用支付宝所提供的服务接口， 那如何保证这些服务在一次订单请求中同时成功或失败

关于数据库事务异步化的典型场景，可以以一个互联网金融P2P平台进行交易系统改造中的客户还款场景为例

在传统的实现方式中，整个扣款的逻辑代码都在一个大的事务中，通过数据库的事务特性来实现这样一个稍显复杂的业务的一致性。以还款为例，这样一个大的数据库事务中，每一位借款人进行的还款操作至少会引起500条还款详单+500次借款人账户表的修改+500名收款人账户表修改，共计1500条数据表的修改，而平台的扣款日往往又都集中在自然月的最后一天，这样就导致在最后一天的最后几个小时，平台接受到密集的还款请求，使得数据库的压力持续高水位运行，用户在进行一次还款操作最长要等待10分钟后才能收到系统返回的结果。这个问题的根本原因是大的数据库事务对数据库的资源占用，表记录长时间被事务锁住带来的数据库请求排队。

针对这一场景，解决平台性能问题的核心就是数据库事务的异步化。通俗来说，就是将大事务拆分成小事务，降低数据库的资源被长时间事务锁占用而造成的数据库瓶颈，就能大大提升平台的处理吞吐量和事务操作的响应时间。

在实际业务改造中，同样基于消息服务提供的异步机制，将整个还款流程进行异步化的处理，在五个主要处理流程间（还款开始，还款计算，还款计划分派，还款计划处理，详单处理）通过消息服务进行下一步业务的触发。

1. 当用户在平台上点击"还款"按钮后，会生成一条还款启动的消息，发送到消息服务上
2. "还款开始"程序接受到此消息后，首先执行"找到未还款的计划"，并同时进行"写入还款请求"和发送"还款计划计算消息"到消息服务上。
3. "还款计算"接收到还款计划计算消息后，进行还款总额的计算，并同时进行占款和发起支付流程的消息到消息服务上
4. "还款计划分派"接收到支付流程的消息后，在给平台的账号转账的同时，发送分期支付消息，这里的消息会针对每一位还款详单中对应的还款人生成还款计划处理消息，这个处理是此次改造方案的核心，将之前在一个事务中处理500次还款处理的操作拆分成500个不同的事务
5. "还款计划处理"程序在接收到每一个还款详单支付请求的消息后，进行详单查找，计算还款详单，最后同时进行从借款人账户中进行扣款以及发送还款详单处理的请求消息
6. 最后则是"还款详单"接收到"详单处理"请求的消息后，一次进行给还款人账户加钱，更新详单表信息等操作。

当然在此过程中，一定要考虑到程序异常时对业务的回滚或重试机制，保障整个还款过程结果的最终一致。通过以上还款事务异步化的处理，在不影响业务体验的前提下，整个平台对于还款的处理能力比之前提升了20倍以上。

事务与柔性事务

如何保证业务事务一致性的问题。面对这个问题目前并没有完美的解决方案，本节会介绍淘宝是如何对订单创建场景实现业务一致的实现，以及近一两年来我们在分布式事务上所作出的创新尝试

对数据库事务，核心体现数据库ACID属性，作为一个事务中包含的所有逻辑处理操作在作用到数据库上时，只有这个事务中所有的操作都成功，对数据库的修改才会永久更新到数据库中，任何一个操作失败，对于数据库之前的修改都会失效。传统数据库的事务确实非常好的保证了业务的一致性，但在互联网场景下，就暴露出数据库性能和处理能力上的瓶颈。所以在分布式领域，基于CAP理论和在其基础上延伸出来的BASE理论，有人提出了柔性事务的概念。

CAP理论：一个分布式系统最多只能同时满足一致性 c 可用性 c 分区容错性 p 这三项中的两项

BASE是指 基本可用，柔性状态 ，最终一致性  （允许不同节点间副本的延时就是柔性状态的体现）

高可用 = 系统构建在多机=分布式系统

高性能=分布式系统的副产品

分布式系统内通信和单机内通信的最大区别是：但系统总线不会丢失消息，而网络会

一台向另一台机器通信的结果可能是收到，未收到，不知道收到没收到。消息不可靠带来的副作用是：数据或者状态在多机之间同步的成本很高。

大家都知道Paxos协议，在多机间通信不存在伪造或篡改的前提下，可以经由Paxos协议达成一致性。成本是发给Paxos系统的信息（数据）需要至少同步发送到一半以上多数(quorum)的机器确认后，才能认为是成功的。这样大幅增加了信息更新的延迟。因此分布式系统的首选不是这样抢同步而是最终一致。

而采用最终一致，一定会产生柔性状态。

柔性事务如何解决分布式事务问题：

 引入日志和补偿机制 类似传统数据库，柔性事务的原子性主要由日志保证，事务日志记录事务的开始结束状态，可能还包括事务参与者信息。参与者节点也需要根据重做或回滚需求记录REDO/UNDO日志，当事务重试回滚时，可以根据这些日志最终将数据恢复到一致状态。