Neon项目中的存储代理(Storage Broker)设计与实现解析

Neon项目中的存储代理(Storage Broker)设计与实现解析

neon Neon: Serverless Postgres. We separated storage and compute to offer autoscaling, branching, and bottomless storage. 项目地址: https://gitcode.com/gh_mirrors/ne/neon

存储代理的定位与作用

在分布式数据库系统中，存储节点间的信息同步是一个关键问题。Neon项目中的存储代理(Storage Broker)就是为解决这一问题而设计的中间层组件。它的核心使命是解决两个主要技术挑战：

1. 节点发现与状态同步：让页面服务器(pageserver)和守护节点(safekeeper)能够动态感知哪些节点持有相同时间线(timeline)的数据副本，以及这些副本的当前状态。

2. 连接数优化：避免在N个存储节点之间形成O(N²)的全连接拓扑，从而降低系统复杂度并提高可扩展性。

核心应用场景

存储代理在Neon架构中扮演着关键角色，主要服务于以下两个核心场景：

1. 页面服务器的WAL同步

页面服务器需要从守护节点获取预写式日志(WAL)时，通过存储代理可以：

• 实时了解所有守护节点的存活状态
• 识别出日志位置(LSN)最先进的守护节点
• 选择最优节点作为WAL同步源

2. 守护节点间的协同

多个守护节点之间需要通过存储代理实现：

• 远程一致性LSN(remote_consistent_lsn)的协同推进
• 备份LSN(backup_lsn)的同步确定
• 协调由哪个节点负责将WAL卸载到S3存储

技术架构解析

存储代理采用了一种轻量级但高效的设计方案：

基础架构

• 通信协议：基于Tonic框架实现的gRPC服务
• 状态管理：采用无状态(stateless)设计，简化了系统复杂度
• 扩展性：天然支持多路复用，有效降低连接数

容错设计

虽然存储代理本身是无状态的，但可以通过Kubernetes等编排系统实现高可用。虽然当前版本没有内置的复制支持，但从架构上看很容易添加这一功能。

消息模型

当前版本主要处理一种核心消息类型：

• SafekeeperTimelineInfo：每个守护节点会定期将其管理的每个活跃时间线状态推送到代理

其他节点通过订阅机制接收这些信息，并基于这些信息做出相应决策。

运维与监控

存储代理提供了完善的运维支持：

1. 监控接口：与gRPC服务共用同一端口提供/metrics端点，方便集成Prometheus等监控系统

2. 调试工具：支持使用grpcurl等工具直接查询当前推送的值，例如：

grpcurl -proto broker/proto/broker.proto -d '{"all":{}}' -plaintext localhost:50051 storage_broker.BrokerService/SubscribeSafekeeperInfo

设计优势分析

1. 解耦设计：将节点发现与状态同步从核心存储逻辑中解耦出来，提高了系统模块化程度

2. 扩展性强：无状态设计使得水平扩展变得简单，只需增加代理实例即可

3. 协议中立：基于gRPC的实现既保证了性能，又提供了良好的跨语言支持

4. 运维友好：内置监控支持降低了运维复杂度

典型应用流程

以一个典型的WAL同步场景为例：

1. 页面服务器启动时，通过存储代理订阅相关时间线的信息
2. 多个守护节点定期推送各自的时间线状态到存储代理
3. 页面服务器收到更新后，分析各守护节点的LSN位置
4. 选择最先进的可用守护节点建立WAL同步连接
5. 持续监控状态变化，必要时切换同步源

这种设计确保了系统能够在动态变化的网络环境中保持高效可靠的数据同步。

总结

Neon的存储代理是一个精心设计的中间层组件，它通过发布-订阅模式优雅地解决了分布式存储系统中的节点发现和状态同步问题。其无状态设计和基于gRPC的实现使其既简单又高效，是Neon架构中不可或缺的基础设施组件。对于需要构建类似分布式存储系统的开发者，这种设计思路值得借鉴。

neon Neon: Serverless Postgres. We separated storage and compute to offer autoscaling, branching, and bottomless storage. 项目地址: https://gitcode.com/gh_mirrors/ne/neon