基于电商业务中台最佳实践：交易中台技术要点设计之高性能基于电商业务中台最佳实践：交易中台技术要点设计之高性能
接着上篇继续讲，接下来主要介绍交易总体设计的技术要点设计，对于电商中台来说，交易系统是核心中的核心，一开始就需
要围绕高性能，高可用，和高扩展三个方面来重点设计。本篇主要介绍高性能设计。
对于高性能的定义，通常可以理解为系统/服务接口响应时间低（rt）且并发量（qps,tps）高. 提高性能的主要策略有：选择合
理的分布式事务处理机制，数据库的分库分表，读写分离，异步化，缓存，复杂查询走搜索。
选择合理的分布式事务处理机制
交易业务要求订单，库存，优惠券，红包，支付等数据要强一致，如何保证这些数据之间的一致性是必须要解决的问题，也就
是分布式事务的场景。
业界分布式事务的选择方案非常多，每种方案之间的差异性非常大。让我们大概看一下几种常见的方案和其特点：
2PC: 二阶段提交协议，最大几个问题是事务管理器（协调者）和资源管理器（参与者）之间的调用是同步阻塞的，如果在一
次事务中只有部分资源管理器进行了commit操作，其他超时或者没有成功，会导致数据的不一致性。
3PC: 三阶段提交协议，是对2PC的改进版本，引入了超时机制，极大的降低了同步阻塞，preCommit 阶段协调者和参与者出
现通信问题后，仍然会出现数据不一致性的问题。
TCC: 其实也是2PC的改进版本，TCC将事务参与者从数据库本身提升到了业务服务粒度，让每个业务单元实现
try,confirm,cancel三个接口，协调者在调用完try接口会，根据返回接口调用confirm还是cancel，其最大问题是业务侵入性非
常强，2PC的单点问题，超时问题也都存在，并且需要业务单元考虑各种异常情况，没法利用数据库的事务机制。
阿里GTS: GTS通过将事务协调器集群化的方式解决了单点问题，但这也带来了另外一个问题，原来本地化的协调者变成了要
网络通信的云协调者，如果不是在同一个数据中心，要跨越公网或者专有网络，性能损耗比较大，此外GTS支持的服务框架
也是有限的，如果不支持也需要实现类似于TCC的业务接口。
SAGA: 在微服务架构下，关注的人越来越多了，但saga早在1987年就提出来了，基本核心思想Saga是一系列本地交易，每
笔事务都会更新单个服务中的数据。第一个事务由系统外部请求启动，然后每个后续步骤由前一个事件完成而触发。其最常见
的两种实现方式如下：
1.事件/编排：没有中央协调器，每个服务产生并聆听其他服务的事件，然后采取对应的处理动作。通常会使用消息中间件来
实现。
2.命令/协调：中央协调器负责集中处理事件的决策和业务逻辑排序。因引入协调器模式比较重，目前没有好的框架。
对saga要详细理解可以自行google，baidu.
事务消息最终一致性方案:利用消息中间件的事务性消息/两阶段消息来实现，流程如下：
这种模式对业务的侵入性比较比较低，利用消息中间件，性能上有非常好的保障，此外即使遇上网络超时等问题，通过消息中
间件的超时回调功能最终都能保证数据的最终一致性。因此我们也选择了这种方案作为我们的实现。以简化的确认下单时序来
说明这个场景：
评论0