Nextdoor 的数据库演进：扩展阶梯

📌 一句话摘要

对 Nextdoor 增量数据库扩展策略的技术深度解析，涵盖了从单实例 PostgreSQL 到结合缓存、CDC 和分片的分布式架构的演进过程。

📝 详细摘要

本文探讨了 Nextdoor 为应对数百万用户增长所遵循的“扩展阶梯”。文章详细描述了一个严谨的演进过程：从单个 PostgreSQL 实例开始，引入 PgBouncer 进行连接池管理，并实施主从（Primary-Replica）架构以扩展读取能力。为了处理复制延迟，他们使用了基于时间的动态路由。为了提升性能，他们添加了基于 Valkey 的旁路缓存（look-aside cache），并使用 MessagePack 和 Zstd 进行压缩。为确保数据完整性，他们开发了一个带有 Lua 脚本的版本控制引擎以实现原子更新，并构建了基于 Debezium 的变更数据捕获（CDC）流水线，用于自我修复式的数据协调。最后阶段涉及通过分片（sharding）实现水平写入扩展。

💡 主要观点

- 通过 PgBouncer 中间件克服连接限制。 PostgreSQL 的“每个连接一个进程”模型在规模化时会产生巨大的开销；PgBouncer 允许数千个应用程序工作进程共享一个较小的热连接池。

利用主从架构和动态路由扩展读取能力。 为了缓解异步复制延迟，Nextdoor 使用了“基于时间的动态路由”，即在用户执行写入操作后的一小段时间内，将其读取请求发送到主数据库。

通过版本控制和 Lua 脚本确保缓存完整性。 在 Valkey 中使用 system_version 列和基于 Lua 的“比较并设置”（Compare and Set）操作，可以防止旧更新覆盖缓存中较新数据的竞态条件。

使用 CDC 和 Debezium 实现自我修复机制。 通过监听 PostgreSQL 的预写式日志（WAL），系统能够检测到不一致并触发后台协调，从而使过期的缓存条目失效。

💬 文章金句

- 每一项性能提升都会引入对数据完整性的新要求。

复杂性必须是“挣来”的。扩展阶梯的每一层在解决一个问题的同时，也会在数据一致性方面引入新的挑战。
服务器最终花费在进程间切换上的时间，比运行驱动社区动态的实际查询所花费的时间还要多。

📊 文章信息

AI 评分：86

来源：ByteByteGo Newsletter

作者：ByteByteGo

分类：软件编程

语言：英文

阅读时间：10 分钟

字数：2385

标签： PostgreSQL, 系统设计, 数据库扩展, PgBouncer, CDC

阅读完整文章

Nextdoor 的数据库演进：扩展阶梯

🤖 問 AI