一、交易系统概述：高并发交易系统的定义、核心挑战与架构演进
大家好，我是你们的老朋友。今天咱们聊聊高并发交易系统。
说实话，我入行那会儿，交易系统还没现在这么复杂。一台小型机，一个Oracle数据库，就能撑起一个券商的交易柜台。但现在？你想想看，双十一的峰值每秒几十万笔订单，这背后要是没有一套靠谱的架构，早就崩了。
这一章，我带你从零开始，把高并发交易系统的底裤看穿。
1.1 什么是高并发交易系统？
先给个定义。高并发交易系统，说白了就是能同时处理大量交易请求的系统。这里的“交易”不光是股票买卖，还包括电商下单、支付转账、抢票预约等等。
我个人习惯用三个指标来衡量一个系统是不是“高并发”：
- 高吞吐量：单位时间内能处理的交易笔数。比如每秒1万笔订单。
- 低延迟：从请求发出到收到响应的时间。一般要求毫秒级，甚至微秒级。
- 高一致性：交易数据不能丢，不能错，不能乱。钱和货必须对得上。
这三个指标，就像三座大山。你压下去一个，另外两个可能就翘起来了。我在项目中遇到过不少团队，为了追求吞吐量，把一致性给牺牲了，结果对账对到崩溃。嗯，这里要注意，交易系统里，一致性是底线。
1.2 核心挑战：延迟、吞吐量、一致性
咱们一个一个拆开看。
1.2.1 延迟
延迟就是慢。用户点一下“下单”，结果转圈转了5秒，这谁受得了？
延迟的来源很多：网络传输、磁盘I/O、锁竞争、GC停顿……我曾经在一个项目中，发现每次Full GC都会导致交易延迟飙升到秒级。后来我们换成了低延迟的垃圾回收器，才把问题压下去。
避坑指南：我曾经以为加机器就能解决延迟问题，结果发现网络开销反而更大了。延迟优化，得从代码层面、系统层面、架构层面一起下手。
1.2.2 吞吐量
吞吐量就是快。系统每秒能处理多少笔交易？
吞吐量的瓶颈通常在数据库。你想想看，一个订单要查库存、扣余额、写流水，这些操作都得落库。数据库的并发能力有限，一旦请求量超过阈值，就会排队等待。
我常用的手段是：读写分离、分库分表、引入缓存。但要注意，缓存用不好，反而会引发缓存穿透、缓存雪崩。这些坑，后面章节我会详细讲。
1.2.3 一致性
一致性是交易系统的命根子。钱多付了、货少发了，都是事故。
这里有个经典问题：分布式事务。在微服务架构下，一个交易可能涉及多个服务，每个服务都有自己的数据库。如何保证所有服务的数据一致？
我个人的经验是：能不用分布式事务，就别用。尽量通过业务设计来规避，比如最终一致性、本地消息表、Saga模式。实在不行，再考虑TCC或Seata。
警告：分布式事务的性能开销很大，能少用就少用。我曾经见过一个项目，因为滥用分布式事务，导致系统吞吐量直接腰斩。
1.3 典型架构演进：单体 → SOA → 微服务 → 事件驱动
架构不是一天建成的。交易系统的架构演进，其实是一部“拆”的历史。
1.3.1 单体架构
早期系统都是单体。一个应用，一个数据库，所有功能都揉在一起。
优点：简单、开发快、部署方便。
缺点：牵一发而动全身，改个支付逻辑，整个系统都得重新部署。
我记得刚入行时，维护过一个老系统。每次上线都提心吊胆，生怕改错一行代码，把整个交易链路搞崩了。
1.3.2 SOA架构
后来大家发现，单体扛不住了。于是开始拆，把业务拆成服务，服务之间通过ESB（企业服务总线）通信。
SOA的好处是：服务可以独立部署、独立扩展。但ESB成了新的瓶颈，而且通信协议太重（SOAP、XML），性能上不去。
1.3.3 微服务架构
微服务是SOA的升级版。服务更小、更独立，通信改用轻量级的REST或gRPC。
微服务的优势很明显：
- 每个服务可以独立开发、测试、部署
- 可以针对热点服务单独扩容
- 技术栈可以多样化
但微服务也有坑：服务多了，调用链长了，排查问题变得困难。我建议你一开始就上链路追踪（比如SkyWalking、Zipkin），否则出了问题，你都不知道是哪个服务在拖后腿。
1.3.4 事件驱动架构
这是目前比较前沿的玩法。服务之间不再直接调用，而是通过事件来通信。
比如，用户下单后，订单服务发布一个“订单创建”事件。库存服务、支付服务、物流服务各自订阅这个事件，然后异步处理。
事件驱动的优点：
- 服务之间解耦更彻底
- 吞吐量高，因为异步处理不阻塞
- 容易扩展，加个新服务只需要订阅事件就行
缺点也很明显：一致性更难保证，事件丢失、重复消费都是常见问题。
提示：如果你刚开始做交易系统，我建议从微服务入手。事件驱动虽然好，但学习曲线陡，不适合新手团队。
1.4 架构演进对比
我整理了一张表，方便你对比这几种架构的差异：
| 架构类型 | 耦合度 | 扩展性 | 一致性 | 适用场景 |
|---|---|---|---|---|
| 单体 | 高 | 差 | 强 | 小团队、低并发 |
| SOA | 中 | 中 | 中 | 企业级系统 |
| 微服务 | 低 | 强 | 弱 | 高并发、快速迭代 |
| 事件驱动 | 极低 | 极强 | 最终一致 | 超高并发、异步场景 |
1.5 架构演进路线图
下面这张图，是我用SVG画的架构演进路线。你可以直观地看到，交易系统是怎么一步步走到今天的。
1.6 小结
这一章，咱们把高并发交易系统的定义、核心挑战和架构演进捋了一遍。
你记住三件事：
- 延迟、吞吐量、一致性是交易系统的三座大山，缺一不可。
- 架构演进的本质是“拆”，从单体拆到微服务，再到事件驱动。
- 没有银弹。每种架构都有优缺点，选型要结合业务场景。
我个人觉得，理解这些基础概念，比背一堆框架配置重要得多。框架会过时，但架构思想不会。
好，今天就到这儿。下一章，咱们聊聊交易系统的核心模型——账户、订单、支付，这些基础概念是怎么设计的。