2.1 整体架构分层模型

2.1 整体架构分层模型

本节摘要：openGauss 内部可分为 SQL 引擎、存储引擎、事务与日志管理三层，外加安全与运维管理两个纵切面。一条查询自上而下穿过这三层，故障也几乎总是能定位到其中某一层。本节沿一次数据访问的完整旅程把这层皮剥开。

行话先立起来：交付团队怎么称呼每一层

现场排障时，老手说"这是执行器的问题"或"缓冲区命中率掉了"，新人往往接不上话——因为这些行话都指向架构里的具体层。openGauss 的分层沿用了经典数据库教科书的骨架：最上层是 SQL 引擎，负责听懂并规划查询；中间是事务与日志管理层，负责一致性与崩溃安全；最底下是存储引擎，负责真正把数据读出来、写下去。两侧还有两个纵切面贯穿三层：安全子系统（认证、加密、审计）与运维管理接口（监控视图、工具挂载点）。后面所有章节的讨论都在这张图上定位。

图：openGauss 分层架构总览——三层主体与两个纵切面

一条查询的旅程：六站接力

把上面这张图变成动态。客户端发出一条查询后，旅程这样展开：

第一站，连接与鉴权。监听线程接受连接，安全子系统核对用户名、密码与来源限制，通过后为这个会话分配服务线程。连接数上限在这一站起作用——第 7 章排障时常见的"连接堆积"，就是会话在线程层排队。

第二站，解析与分析。解析器做词法与语法检查，把 SQL 文本变成语法树；分析器再查系统目录，确认表存在、列存在、类型能对上、你有权限。绝大多数"表不存在""列类型不匹配"报错都死在这一站，此时还没碰任何数据。

第三站，优化。优化器基于统计信息为语法树挑选执行路径：走哪个索引、多表用什么顺序连接、用嵌套循环还是哈希连接。它生成的执行计划是第 4 章的绝对主角，"这条 SQL 为什么慢"的答案八成藏在这里。

第四站，执行。执行器按计划驱动算子：扫描算子向存储引擎要数据页，连接算子在内存里做匹配，聚合算子做分组统计。执行期间的排序、哈希可能溢出到磁盘临时空间，这也是慢查询的常见来源。

第五站，事务与日志。数据页的修改先以日志记录的形式写入 WAL，保证崩溃后可重放；可见性判断由 MVCC 完成，锁管理器协调并发写者。提交时日志先行——事务是否成功，以日志落盘为准，而不是以数据页落盘为准。

第六站，存储与返回。缓冲区管理器决定命中内存还是读盘，脏页由后台线程择机刷盘；结果按相反方向返回客户端。

分层的实战意义：按层报障

分层不是考试知识点，是排障的路由表。举一个真实工单的处理路径：报表接口超时。先看报错发生在哪一站——连接正常、无报错、单纯慢，说明问题在第三站之后；取执行计划，发现对大表做了顺序扫描，统计信息过期导致优化器放弃索引，属于第三站；更新统计信息后计划改为索引扫描，耗时从十二秒降到两百毫秒。全程没有动任何"底层"，但每一步判断都依赖你分得清"慢在解析、慢在计划、还是慢在 IO"。再比如备份恢复报错：日志显示归档缺失，属于第五站的日志管理域，去查归档目录与备机回放位点，而不是去查 SQL 引擎。

一个常被忽略的协同细节：三层之间不是单向瀑布。执行器发现缓冲区不够会触发淘汰，日志写入延迟会反过来拖慢提交，统计信息更新会改变下一个查询的计划。所以生产环境做变更（改参数、刷统计信息、扩容表空间）前，老交付团队的习惯是先在心里过一遍"这个变更会波及哪几层"，把影响面写进变更单。

纵切面的协同：一次审计事件穿过几层

用一次真实事件看纵切面与三层的联动。场景：安全团队通知，某业务账号在凌晨两点导出了一整表敏感数据，要求给出完整链路报告。第一层证据来自安全子系统的审计记录——什么时候、哪个来源地址、哪个账号、什么语句；第二层证据来自 SQL 引擎侧的语句文本与执行计划快照——导出是全表扫描还是索引逐步读取，估算与实际行数多少；第三层证据来自事务与存储侧——该会话的快照边界、读到的版本范围、是否与并写入交叉。三层证据拼起来，报告才能回答安全团队真正关心的问题：这是一次合法业务行为还是越权操作，数据流向了哪里，同类行为如何预防。这个案例说明架构分层的另一半价值：它不仅路由故障，也路由取证——每一层留痕的内容不同，组合起来才是完整的事实。

分层视角下的容量评审

装机评审会上用分层语言提问，效率远高于泛泛而谈。按层走一遍：SQL 引擎层，最复杂查询的连接表数与排序规模多大，决定执行内存的规划；事务层，峰值每秒提交数与同步复制的等待预算，决定日志盘的写带宽与网络规划；存储层，热数据工作集多大，决定共享缓冲区与盘型的匹配；安全层，审计与加密的开启级别，决定额外的存储与计算开销；运维层，监控采集频率与备份窗口，决定与业务流量的错峰安排。一张评审表下来，每一层都有对应的一两个数字要确认——交付老手的评审会就是这样开的：问的是架构层，记的是容量数。

三层协同的失败模式：级联放大

分层架构最大的风险不是单层故障，而是故障沿层传导放大。三条典型的级联链值得背下来。链一，存储层到执行层：磁盘延迟升高，缓冲区淘汰变慢，扫描算子排队，查询整体变慢，应用超时重试，读压力再翻倍——一次磁盘抖动最终以"全站变慢"的形态呈现在业务层。链二，事务层到存储层：长事务持锁不释放，写者排队，锁表膨胀，内存压力上升，触发检查点加压——一个忘提交的会话能牵出一条完整的资源紧张链。链三，SQL 层到事务层：统计信息过期导致计划劣化，单条大查询执行时间翻倍，事务持有时长同步翻倍，与并发写者的冲突窗口拉长，锁等待上升。三条链的共同启示：定位故障时往上游找一层找根因，往下游找一层找影响面——分层图不只是结构图，还是故障传导的路线图。交付培训时让新人手画这三条链，画得出才算真懂了分层的动态含义。

用分层图读懂一份监控大屏

学完分层，回看你们环境现有的监控大屏，做一次映射练习：屏幕上每个图表对应架构图的哪一层。常见的映射结果：CPU、内存、磁盘图对应存储与资源层；连接数、活跃会话对应 SQL 引擎入口层；提交延迟、锁等待对应事务层；审计类告警对应安全纵切面。映射练习的价值在两处：一，发现监控盲区——映射不上去的层就是没有观测的层，典型盲区是事务层与安全层；二，理顺告警路由——告警应该按层分发给不同的人，存储层告警找系统管理员，事务层找 DBA，安全层找安全岗，路由错层的告警响应必然慢。这个练习十分钟，建议纳入每个交付项目的监控验收环节。

本节要点回顾

• 三层主体：SQL 引擎管听懂与规划，事务与日志管一致与可恢复，存储引擎管读写落地；
• 两个纵切面：安全与运维贯穿三层，任何一层的事件都可能同时留下安全与运维两条线索；
• 六站旅程：鉴权、解析、优化、执行、事务日志、存储返回，报错先定站再定位；
• 层间有反馈：缓冲区、日志、统计信息都会跨层施压，变更前先想影响面；
• 路由口诀：慢在算、丢在事务、堵在存储、泄在安全、断在复制。

下一站深入单机内部：线程怎么排班、内存怎么分家、磁盘读写走什么通道——单机架构的账算不清，集群规模再大也是空谈。