存算分离架构中的数据一致性校验方案与实践

1. 存算分离架构下的数据一致性挑战

在移动云大云海山数据库的存算分离架构中，计算节点与共享存储的解耦带来了显著的扩展性和成本优势，但也引入了数据一致性的新挑战。作为数据库内核开发者，我们经常遇到这样的场景：当计算节点的本地缓存未命中时，需要从共享存储获取数据页，但此时无法确保获取的页版本与计算节点当前事务视图的一致性。

这种架构下主要存在两类数据一致性问题：

1. 时间维度不一致：可能读到"未来页"（包含当前事务尚未可见的修改）或"过去页"（落后于当前应有的版本）
2. 空间维度不一致：不同计算节点可能读到同一逻辑页的不同物理版本

传统单机数据库通过缓冲区管理器和WAL日志保证一致性，但在存算分离架构中，这些机制需要重新设计。我们的解决方案是通过在Redis中维护页面校验和(checksum)的全局视图，建立跨节点的数据一致性基准。

关键设计原则：校验操作必须满足ACID特性中的隔离性——校验过程本身不能影响正常查询性能，校验失败必须立即终止可能引发数据错误的事务。

2. 校验框架的架构设计

2.1 核心组件交互

整个校验框架由三个关键组件构成环形验证链：

code复制计算节点 → 共享存储 → Redis校验服务 → 计算节点

2.2 校验流程的时序设计

1. 写路径校验：

   • 计算节点淘汰脏页时，同步计算并存储checksum到Redis
   • 采用"先Redis后DS"的双阶段提交，确保校验数据先于实际数据持久化

2. 读路径校验：

   mermaid复制sequenceDiagram
   计算节点->>共享存储: 1. 读取数据页
   计算节点->>Redis: 2. 获取预期checksum
   alt 校验通过
     计算节点->>应用: 3. 返回合规数据
   else 校验失败
     计算节点->>系统: 4. 触发panic保护
   end
   

2.3 Redis存储设计优化

针对checksum存储的特殊性，我们做了以下优化：

• Key设计：采用dbId_spcId_relId_forkNum_blockNum的复合键结构，确保全局唯一性
• 存储压缩：将uint32 checksum压缩为16位存储，节省40%内存占用
• 分库策略：每个计算节点独占Redis一个DB，避免锁竞争

c复制// Key生成算法示例
char* GeneratePageKey(Oid dbNode, Oid spcNode, Oid relNode, ForkNumber forknum, BlockNumber blocknum) {
    char *key = palloc0(MAX_KEY_LENGTH);
    snprintf(key, MAX_KEY_LENGTH, "%u_%u_%u_%d_%u", 
             dbNode, spcNode, relNode, forknum, blocknum);
    return key;
}

3. 核心校验算法实现

3.1 数据页checksum计算

采用改进的Fletcher-32算法，相比PostgreSQL原生实现有以下增强：

1. 增加页头元数据校验
2. 支持跳过可变区域（如Hint Bits）
3. 添加时间戳指纹防止重放攻击

c复制uint32 pg_checksum_block(const PGChecksummablePage *page) {
    uint32 sums[N_SUMS] = {0};
    uint32 result = 0;
    
    // 元数据校验区
    CHECKSUM_COMP(sums[0], page->pd_lsn);
    CHECKSUM_COMP(sums[1], page->pd_checksum);
    
    // 数据内容校验区
    for (int i = 0; i < BLCKSZ/sizeof(uint32); i++) {
        CHECKSUM_COMP(sums[i%N_SUMS], page->data[i]);
    }
    
    // 时间指纹校验
    uint32 timestamp = (uint32)time(NULL);
    CHECKSUM_COMP(sums[N_SUMS-1], timestamp);
    
    for (int i = 0; i < N_SUMS; i++)
        result ^= sums[i];
    
    return result;
}

3.2 索引页的特殊处理

针对不同索引类型的页结构差异，设计动态掩码机制：

c复制// B-Tree页校验示例
void btree_mask(Page page) {
    BTPageOpaque opaque = (BTPageOpaque) PageGetSpecialPointer(page);
    mask_page_lsn_and_checksum(page);
    
    if (P_ISDELETED(opaque)) {
        mask_page_content(page);  // 已删除页只校验元数据
    } else {
        mask_unused_space(page);
    }
}

4. 生产环境调优实践

4.1 性能优化方案

1. 批量校验：对连续块号实施批量checksum校验，减少Redis往返次数

   sql复制-- 批量获取checksum的Redis命令
   MGET page_1_1663_24575_0_0 page_1_1663_24575_0_1 ... page_1_1663_24575_0_63
   

2. 热点页缓存：在计算节点本地维护高频访问页的checksum缓存

   • 采用LRU-K算法管理缓存项
   • 设置5秒的缓存有效期

3. 异步校验：对只读查询启用延迟校验模式

   c复制if (IsReadOnlyTransaction()) {
       EnableLazyChecksum();
   }
   

4.2 故障处理机制

我们建立了分级响应策略：

典型的页修复流程：

1. 记录错误页到pg_checksum_error系统表
2. 从最新检查点恢复该页基础版本
3. 重放相关WAL记录重建页内容

5. 验证效果与典型案例

5.1 性能影响评估

在TPC-C基准测试中，不同负载下的性能表现：

5.2 典型问题捕获

1. 共享存储缓存污染：

   • 现象：频繁出现未来页校验失败
   • 根因：存储节点未正确隔离不同租户的缓存
   • 解决：引入tenant_id维度增强校验key

2. 网络分区引发的版本分裂：

   python复制# 模拟网络分区的测试用例
   def test_network_partition():
       with db.transaction():  # 事务T1
           update_page(block_id=42)
           network.drop_packets()  # 模拟网络中断
           assert read_page(block_id=42).checksum == get_redis_checksum(42)  # 触发panic
   

3. 索引页逻辑损坏：

   • 发现方式：GiST索引校验连续失败
   • 分析：存储引擎的页刷新顺序错误
   • 修复：调整刷脏策略确保索引页先于数据页持久化

6. 框架的演进方向

在实际运维中我们积累了几个关键改进点：

1. 增量checksum：对大页实施分段校验，降低计算开销
2. 基于Raft的校验服务：替代Redis提高一致性强度
3. 机器学习预测：通过历史模式预测可能的问题页

一个正在试验中的优化是选择性校验：

sql复制-- 通过页面访问模式决定校验强度
CREATE POLICY checksum_policy ON ALL TABLES
USING (access_mode IN ('critical', 'normal'))
WITH (check_frequency = CASE 
        WHEN access_mode = 'critical' THEN 'always'
        ELSE 'lazy'
     END);

这套框架上线后，将数据一致性事故的平均修复时间(MTTR)从小时级降低到分钟级。对于数据库内核开发者而言，最重要的经验是：在存算分离架构中，必须建立贯穿整个IO路径的验证机制，才能确保分布式环境下的数据正确性。