从日志即数据到存储抽象层：TaurusDB存算分离架构的数据持久化路径重构

传统MySQL数据库的扩展瓶颈根植于一个结构性设计：计算与存储紧密耦合，数据文件的读写与SQL执行共享同一台服务器的资源。添加只读节点需要复制全量数据，数据量达到TB级别时扩容周期以天计。存算分离架构的核心思路是将数据存储与计算能力解耦，让计算层和存储层可以独立扩展，但随之而来的是一个更深层的工程挑战——日志的持久化路径需要被完全重新设计。

华为云TaurusDB的解法是将“日志即数据”（Log is Data）作为存算分离架构的持久化基石。数据库的持久化不再依赖数据页面的刷盘，而是以日志的持久化为中心，数据页面通过日志回放异步构建。这一设计需要存储抽象层（SAL）在InnoDB引擎和分布式存储之间建立一套完整的日志服务、页面管理和数据写入机制。

存算分离的数据持久化困境
传统MySQL的持久化路径是双层的：事务提交时，WAL日志先写入本地磁盘的redo log文件，确保崩溃可恢复；数据页面在缓冲池中修改后，由后台线程异步刷写到表空间文件。日志和数据页面是分离的，日志是“临时保障”，数据页面是“最终状态”。

这个设计在单机环境下工作良好，但在存算分离架构中遇到了根本性矛盾。如果计算节点仍然需要将数据页面刷写到远端存储，那么每次刷写都是一次网络I/O，延迟远高于本地磁盘。更严重的是，多个计算节点如果都向同一份共享存储刷写数据页面，页面版本的冲突协调会成为性能灾难。

TaurusDB的解法是改变持久化的中心。日志不再是“临时保障”，而是持久化的主体。SAL层将数据库存储引擎的持久化卸载到Page Store执行——先持久化日志，再通过日志回放修改页面并创建检查点。数据页面不再从计算节点直接刷写到远端存储，而是在存储层通过日志回放生成。

SAL层的日志服务：PLog与CULog的工程实现
存储抽象层（SAL）位于计算层的InnoDB引擎和存储节点之间，其核心职责是向InnoDB提供日志和数据的存储服务。SAL层的日志服务建立在两个基础组件之上：PLog和CULog。

PLog（Persistent Log）是SAL层日志服务的最小存储对象。每个PLog的大小固定为256MB，采用3副本强一致策略——写入请求需要在3个副本上都完成才视为成功。如果某个副本所在服务器出现异常，写入请求会立刻选择新的服务器并在该服务器上创建新的PLog，然后再次执行请求直至成功。这种设计将日志的持久化从“单点写入+异步复制”转变为“多数派同步写入”，在保证强一致性的同时，通过副本切换机制避免了单点故障导致的写入阻塞。

基于PLog，SAL层实现了CULog（Continuous Unlimited Log），这是一个具有无限空间的日志组件。TaurusDB配置了8个日志CULog，每次日志写入时采用轮询方式并发写入以提高性能。数据库日志系统使用多个CULog进一步封装实现了PWAL（Persistent Write Ahead Log），每条日志对应一个递增的日志序列号（LSN），SAL维护多种LSN来确保日志的一致性和可恢复性。

这个设计的工程意义在于，它将日志的持久化从“顺序追加到单一文件”转变为“并行写入多个日志流”。8个CULog的轮询写入意味着日志写入的吞吐量不再受限于单个存储设备的顺序写带宽，而是可以横向扩展到多个存储节点的聚合带宽。

页面管理与数据分片机制
日志持久化解决了事务提交的延迟问题，但数据页面最终仍然需要被持久化。TaurusDB将页面数据按固定大小分片，每个分片（Slice）为10GB。分片机制使得存储管理更加精细——当一个分片写满后，系统自动分配新的分片，避免了单一大文件的管理开销。

在计算节点侧，分布式缓冲池位于数据访问层和分布式存储层的中间，所有数据访问都要经过缓冲池。分布式缓冲池需要保证页面数据的一致性和页面查找访问的高效性，是云原生数据库实现透明多写和内存资源弹性的关键模块。

TaurusDB将页面按访问特征分为三类进行差异化缓存。跨节点共享页面（如Heap页面、FSM页面）适合存放在远程内存中，页面地址共享，避免页面在多个计算节点之间频繁传递。高频只读页面（如索引非叶子页面、系统表页面）适合存放在本地内存，利用本地访问的低延迟优势。单节点读写页面（如智能路由优化后的索引叶子节点页面）适合存放在本地内存，通过SQL优化器的Range路由实现亲和性访问。

页面查找通过Page Directory（PD）机制实现。每个页面缓存对应一个元信息，记录页面的最新版本位于哪个节点（Page Owner Node）、页面是否为共享远程页面以及远程页面地址。PD分布在各个计算节点上，采用一致性Hash方法管理，使每个节点都能快速定位页面的属主，无需广播查询。

存算分离的工程边界
TaurusDB的存算分离架构在扩展性和弹性方面带来了明确的收益。所有计算节点共享同一份存储数据，添加只读节点无需复制全量数据，添加节点的时间与数据量大小无关，可实现分钟级添加只读节点。计算层可根据业务负载动态调整资源，存储容量可按需线性扩展。

但这一架构也有清晰的工程边界。SAL层的日志服务依赖3副本强一致策略，日志写入的延迟下界由最慢的副本决定。在跨可用区部署时，副本之间的网络延迟会直接影响事务提交延迟。CULog的8路并发写入虽然提升了吞吐，但也增加了日志一致性维护的复杂度——多个日志流之间的LSN协调需要在SAL层完成，任何日志流的短暂不可用都会影响整体的写入能力。

从更宏观的视角来看，TaurusDB的“日志即数据”设计代表了一种持久化范式的转变：数据库的持久化不再以数据页面为中心，而是以日志为中心。数据页面成为日志的派生结果，存储层负责通过日志回放构建页面状态。这种设计将计算节点从数据页面的刷写负担中解放出来，使计算资源可以专注于SQL执行，存储资源可以专注于日志持久化和页面构建。两者的解耦程度越高，各自的扩展效率就越高。