2. 高可用架构基础：CAP理论、BASE理论、故障类型与应对策略
聊交易网关的高可用，咱们得先打好地基。说白了，就是搞清楚几个核心理论，以及系统到底会怎么「挂」。
我见过不少团队，一上来就堆中间件、搞集群，结果连最基本的CAP都没想明白。最后出了问题，定位起来那叫一个痛苦。所以，这一节咱们把底层的逻辑捋清楚。
2.1 CAP理论：分布式系统的「不可能三角」
CAP理论是分布式系统的基石。它告诉我们，一个分布式系统，在一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三者之间，最多只能同时满足两个。
你想想看，这就像你同时要追求「快」、「好」、「省」，总得牺牲点什么。
- C - 一致性：所有节点在同一时刻看到的数据是一样的。就像你转账后，查余额立刻就是新的数字。
- A - 可用性：每个请求都能收到一个非错误的响应，但不保证是最新的数据。说白了，系统还能用，但数据可能有点「旧」。
- P - 分区容错性：系统内部网络断了，部分节点联系不上，系统还能继续工作。这在分布式系统里是必须面对的。
核心观点：在分布式系统中，网络分区是必然发生的。所以，P 是必选项。我们实际是在 CP 和 AP 之间做选择。
我在项目中遇到过，有人非要在交易系统里追求「强一致性」，结果网络一抖，整个网关就拒绝服务了。这其实是在拿可用性换一致性，对于交易网关来说，往往是不可接受的。
下面这张图，能帮你快速理解这个「不可能三角」：
2.2 BASE理论：对CAP的妥协与升华
既然CAP里P是必选的，那我们在C和A之间怎么选？BASE理论给出了答案。
BASE是 Basically Available（基本可用）、Soft State（软状态） 和 Eventually Consistent（最终一致性） 的缩写。它不像ACID那么死板，而是允许系统在一段时间内处于不一致的状态，但最终会达成一致。
- BA - 基本可用：系统出问题时，允许损失部分功能，比如降级、限流，但核心功能还在。就像双十一，你可能抢不到优惠券，但下单功能还是正常的。
- S - 软状态：允许系统存在中间状态，这个状态不影响系统整体可用性。比如数据正在同步，不同节点数据不一样，但系统不报错。
- E - 最终一致性：经过一段时间后，所有数据副本最终会达成一致。这是交易网关最常用的模型。
我的经验：交易网关里，订单状态、账户余额这些核心数据，我们通常采用「最终一致性」模型。比如，用户下单后，先返回「下单成功」，后台再异步去扣库存、记账。如果失败了，再通过补偿机制回滚。这样用户体验好，系统也扛得住。
2.3 故障类型：系统到底会怎么「挂」？
搞清楚了理论，咱们得看看现实。交易网关会碰到哪些故障？我把它分成三类：
| 故障类型 | 具体表现 | 对网关的影响 |
|---|---|---|
| 硬件故障 | 服务器宕机、磁盘损坏、网卡松动、电源故障 | 节点不可用，请求失败，数据丢失风险 |
| 软件故障 | 代码Bug、内存泄漏、线程死锁、配置错误、依赖服务超时 | 服务响应慢、功能异常、雪崩效应 |
| 网络故障 | 网络分区、丢包、延迟抖动、DNS解析失败、防火墙拦截 | 节点间通信中断，数据不一致，请求超时 |
我曾经遇到过一个经典案例：某个交易网关因为上游行情服务的一个配置错误，导致所有行情请求都超时。结果网关的线程池被占满，连正常的交易请求也处理不了了。这就是典型的「软件故障」引发的「雪崩」。
2.4 应对策略：怎么「扛」住故障？
知道了故障类型，咱们得对症下药。应对策略可以总结为四个字：冗余、隔离、限流、降级。
2.4.1 冗余：多副本，不怕挂
这是最基础的手段。服务器搞两台，一台挂了另一台顶上。数据库做主从，数据多存几份。但要注意，冗余会带来一致性问题，这就回到我们前面讲的CAP和BASE了。
2.4.2 隔离：别让一个故障拖垮全局
把系统拆分成独立的模块，比如交易模块、行情模块、风控模块。一个模块挂了，不影响其他模块。线程池也要隔离，别让一个慢请求占满所有线程。
2.4.3 限流：挡住过载的流量
当流量超过系统处理能力时，主动拒绝一部分请求。常用的算法有令牌桶、漏桶。我习惯在网关层做限流，保护下游系统不被冲垮。
2.4.4 降级：丢卒保车
系统压力过大时，主动关闭一些非核心功能。比如，行情展示可以暂时用缓存数据，甚至不展示，保证交易下单的核心链路畅通。
避坑指南：我曾经在降级策略上吃过亏。当时为了快速恢复，直接关闭了风控模块。结果被恶意用户刷单，造成了不小的损失。所以，降级一定要有「度」，核心的安全策略不能降。
好了，这一节的内容就这些。理论是基础，但真正用起来，还得结合业务场景。下一节，我们会把这些理论落地，看看交易网关的具体架构设计。