系统日报-20220515（解析 Google 兼容 PostgreSQL 的云原生数据库 AlloyDB）

AlloyDB 是 Google Cloud 在 Google I/O 2022 大会上发布的兼容 PostgreSQL 标准的云原生数据库，其存储层设计具有诸多亮点，以下从架构、读写流程、弹性伸缩、跨区多活几个方面进行详细解析：

AlloyDB 分为 Database 层和存储层，DB 层负责兼容 PostgreSQL 协议，解析 SQL 语句并转化为读写请求发送给存储层。存储层细分为三层：

• log storage 层：DB 层将写入转换为操作日志（WAL）写入该层，它只支持追加写入，能实现低延迟、高可用，还可利用 LSN 进行读写并发控制和分布式事务。
  

• LPS 层（Log Processing Service）：作为日志处理服务层，消费 log storage 层的 WAL 并生成 Block，本质是物化过程。它无状态且可伸缩，能根据负载、统计信息等动态增删实例。
• block storage 层：对应单机 PostgreSQL 的 block 层，用于服务查询。通过分片提供并行度，通过冗余保证跨区容错性，推测其提供的 block 仅支持单次写多次读，便于做缓存和版本控制。

• 写入请求：客户端向主实例发起写入请求（如 SQL insert），经 DB 层解析后变为 WAL Records 发到存储层。WAL 同步写入成功后事务提交并返回，之后 LPS 异步将日志物化为 Block。不过，原文未展开的日志分段、容错、多地部署和生命周期管理也是关键设计点。

• 读取请求：客户端向任何实例发起读取请求（如 SQL query），经 DB 层解析后，先检查 DB 层中的缓存（Buffer Cache），命中则直接返回；若缓存不够，去 Ultra-fast Cache 中查找，命中则不访问存储层；若仍缺少所需 block，则带上 block id 和 LSN 向存储层发送请求。block id 用于检索 block，LSN 用于等待 LPS apply 进度以保证一致性视图。LPS 负责 block 读写，每个 LPS 维护 Buffer Cache，在日志重放时先写入 Buffer Cache，此时充当 buffer 以批量刷入 block storage；刷入前若收到读取请求且命中 Buffer Cache，则直接返回，此时充当 cache。LPS 需维护类似脏表的数据结构追踪 block 生命周期和下刷失效时机。
  

为应对变化负载，LPS 实例数量可伸缩，即调整 LPS 和 block shard 的映射关系。一组 block 集合为一个 shard，一个 shard 最多由一个 LPS 实例处理，一个 LPS 实例可同时处理多个 shards。以餐厅类比，block 是客人，shard 是餐桌，LPS 实例是服务员，负载低时一个服务员照顾所有餐桌客人，负载高时可为每个餐桌分配一个服务员。这种动态调节可完全自动化，无需用户感知和干预，且因 LPS 无状态（Buffer Cache 不算状态）可快速伸缩。

为容忍区域性故障，AlloyDB 将每个 block 分片的多个副本放到不同 zone 中。推测 region 指物理区域，zone 指逻辑区域。当某个 zone 发生故障时，在同一 region 新拉起一个 zone 并进行数据恢复，先使用其他副本的 snapshot 恢复，再将 snapshot 之后的 WAL 回放。正常情况下，每个 zone 可独立服务，跨 zone 流量较少。此外，AlloyDB 还支持逻辑上（如某个 database）的手动和自动备份，防止用户误删数据。

AlloyDB 的存储层基于日志服务实现，分为两层存储和一层计算，利用 LSN 控制并发，动态伸缩 LPS 应对负载，这种设计在分布式数据库领域具有一定创新性和实用性，为云原生数据库的发展提供了新的思路和参考。