基于大中台架构的电商业务中台最佳实践之三：交易中台技术要点设计之高性能

最新推荐文章于 2024-08-12 21:30:00 发布

yinghe_one

最新推荐文章于 2024-08-12 21:30:00 发布

阅读量8.3k

点赞数 4

分类专栏：架构文章标签：架构高性能中台交易分布式

本文链接：https://blog.csdn.net/yinghe_one/article/details/83785669

版权

本文介绍了基于大中台架构的电商交易系统如何设计以实现高性能，重点关注分布式事务处理机制的选择，包括2PC、3PC、TCC、SAGA、事务消息最终一致性方案。此外，还探讨了数据库分库分表、读写分离、异步化、缓存和复杂查询走搜索等技术要点，以确保系统的高性能、高可用和高扩展性。

摘要由CSDN通过智能技术生成

接着上篇继续讲，接下来主要介绍交易总体设计的技术要点设计，对于电商中台来说，交易系统是核心中的核心，一开始就需要围绕高性能，高可用，和高扩展三个方面来重点设计。本篇主要介绍高性能设计。

对于高性能的定义，通常可以理解为系统/服务接口响应时间低（rt）且并发量（qps,tps）高. 提高性能的主要策略有：选择合理的分布式事务处理机制，数据库的分库分表，读写分离，异步化，缓存，复杂查询走搜索。

选择合理的分布式事务处理机制

交易业务要求订单，库存，优惠券，红包，支付等数据要强一致，如何保证这些数据之间的一致性是必须要解决的问题，也就是分布式事务的场景。

业界分布式事务的选择方案非常多，每种方案之间的差异性非常大。让我们大概看一下几种常见的方案和其特点：

2PC: 二阶段提交协议，最大几个问题是事务管理器（协调者）和资源管理器（参与者）之间的调用是同步阻塞的，如果在一次事务中只有部分资源管理器进行了commit操作，其他超时或者没有成功，会导致数据的不一致性。

3PC: 三阶段提交协议，是对2PC的改进版本，引入了超时机制，极大的降低了同步阻塞，preCommit 阶段协调者和参与者出现通信问题后，仍然会出现数据不一致性的问题。

TCC: 其实也是2PC的改进版本，TCC将事务参与者从数据库本身提升到了业务服务粒度，让每个业务单元实现try,confirm,cancel三个接口，协调者在调用完try接口会，根据返回接口调用confirm还是cancel，其最大问题是业务侵入性非常强，2PC的单点问题，超时问题也都存在，并且需要业务单元考虑各种异常情况，没法利用数据库的事务机制。

阿里GTS: GTS通过将事务协调器集群化的方式解决了单点问题，但这也带来了另外一个问题，原来本地化的协调者变成了要网络通信的云协调者，如果不是在同一个数据中心，要跨越公网或者专有网络，性能损耗比较大，此外GTS支持的服务框架也是