一、故障排查总纲：多节点交易系统的架构概览、常见故障分类、故障排查的黄金三原则、排查工具链介绍

1.1 多节点交易系统长什么样？

先聊聊架构。多节点交易系统，说白了就是一堆服务器协同干活，处理订单、撮合交易、清算资金。我见过不少刚入行的朋友，一听到「多节点」就头大，其实没那么玄乎。

典型的架构分三层：

• 接入层：负责接收客户端的交易指令。比如下单、撤单、查询。这一层通常用Nginx或自研网关做负载均衡。
• 核心交易层：这是心脏。订单路由、风控校验、撮合引擎都在这里。一般会拆成多个微服务，每个服务部署多个节点。
• 数据层：数据库、缓存、消息队列。MySQL存账户余额，Redis存行情快照，Kafka串起异步流程。

我在项目中遇到过一种情况：接入层节点挂了，但客户端还在疯狂重连，结果把其他节点也拖垮了。嗯，这就是典型的「故障扩散」。所以架构设计时，隔离和熔断必须到位。

1.2 常见故障分类

故障千奇百怪，但归纳起来就几大类。我习惯把它们分成「看得见的」和「看不见的」。

故障类型	典型表现	常见原因
网络故障	超时、丢包、连接重置	交换机故障、带宽打满、防火墙策略
节点故障	进程挂掉、OOM、CPU飙高	代码bug、内存泄漏、配置错误
数据不一致	对账不平、订单状态错乱	分布式事务失败、缓存与DB不同步
性能退化	响应变慢、吞吐量下降	慢SQL、锁竞争、GC频繁
配置错误	功能异常、路由错误	人为误操作、版本不一致

你想想看，这些故障里哪个最头疼？我个人觉得是「数据不一致」。因为网络挂了可以重启，节点挂了可以拉起，但数据乱了，恢复起来要命。我曾经因为一个缓存和数据库的双写顺序搞反了，导致对账差了300多万，熬了一整夜才修回来。

1.3 故障排查的黄金三原则

排查故障，最怕乱。一上来就抓日志、看监控、重启服务，那是瞎忙活。我总结了三条原则，每次出问题都先默念一遍。

1. 先止血，再找根因。系统崩了，第一件事不是查为什么崩，而是让系统先恢复。回滚、切流、重启，怎么快怎么来。等业务稳住了，再慢慢分析。
2. 从现象反推路径。用户说「下单失败」，别急着查数据库。先看请求到了哪一层？网关？交易服务？还是风控？沿着调用链一步步排查。
3. 一次只改一个变量。排查时最忌讳同时改多个配置。我曾经一边改超时时间一边调线程池，结果问题没解决，反而引入了新故障。记住，改完一个测一个。

1.4 排查工具链介绍

工欲善其事，必先利其器。我平时排查故障，离不开这几样东西。

• 日志系统：ELK或Loki。别小看日志，它是第一手证据。我习惯把交易链路的traceId打全，这样一搜就能串起整个请求。
• 监控告警：Prometheus + Grafana。CPU、内存、QPS、延迟，这些指标必须实时可见。我一般会设三个级别的告警：警告、严重、灾难。
• 链路追踪：Jaeger或SkyWalking。多节点系统最怕「黑盒」，链路追踪能让你看到每个请求走了哪些服务，花了多少时间。
• 数据库工具：慢查询日志、pt-query-digest、Explain。SQL层面的问题，这些工具基本能搞定。
• 网络工具：tcpdump、Wireshark、ping、mtr。网络故障时，这些是救命稻草。

1.5 知识体系总览

下面这张图，是我自己梳理的故障排查知识体系。每次带新人，我都会先让他看这张图，心里有个全局观。

这张图把本章的核心内容串起来了。从架构概览出发，理解系统怎么搭的；然后知道故障分几类，心里有数；接着记住黄金三原则，不乱阵脚；最后用好工具链，快速定位问题。说白了，这就是一套「心法+招式」的组合。

好了，第一章就聊到这儿。记住，排查故障不是靠运气，而是靠体系化的思路和扎实的工具功底。后面几章，我会带你一个个拆解具体的故障场景，咱们到时候细聊。