Meta 推出 ZGateway，这是一个面向其广泛使用的分布式键值存储系统 ZippyDB 的无状态代理层，旨在解决由超过 100 万个客户端主机带来的连接和可靠性挑战。该网关每秒处理超过 10 亿次操作，并承担了 ZippyDB 约 40% 的流量；而根据 Meta 的模型估算，该架构将持久连接总数减少为原来的约 1/19。
ZippyDB 支持在 Meta 的全球分布式基础设施上处理产品元数据、计数器、配置及其他工作负载。在直接访问模型中，客户端会连接到提供所需分片的数据库主机。单个客户端可能访问分布在数十万台数据库主机上的数万个分片，从而形成了密集的“多对多”连接网格。Meta 表示，连接风暴可能会导致文件描述符耗尽和内存不足的情况。
ZGateway 在客户端与 ZippyDB 服务器之间部署了一个托管代理层。客户端与区域网关主机之间保持粘性连接，而数据库服务器则从受控的网关集群接收连接。ZGateway 作为通过 ServiceRouter（Meta 的超大规模服务网格解决方案）发现的区域层运行，从而使客户端始终位于其网关附近。该网关使用 Meta 现有的 C++ ZippyDB 客户端作为请求引擎，并同时支持纯代理和读透式缓存层。根据 Meta 的模型估算，每个主机的连接数将减少约 97% 至 98%，而持久连接总数将减少为原来的约 1/19。
这一变更还改变了共享流量管理的位置。ZGateway 可以对请求进行身份验证和授权，应用基于租户的准入控制，解析分片，使用本地缓存，并在将请求转发至 ZServer 副本之前对请求进行批处理或合并。由于网关能够看到来自多个客户端的流量，所以它可以将单个客户端库在不同进程间无法观察到的请求进行合并。
连接池、服务网格、CDN 和 API 网关也使用该代理模式，不过它们的职责和可扩展性权衡各不相同。Meta 之前对 ZippyDB 的描述表明，数据库本身已经提供了托管分片、复制、故障检测和容量管理功能，而 ZGateway 则在这些功能之前添加了一个共享的流量管理层。
额外增加的网络跳数是有意做出的权衡。在 LinkedIn 的一篇博文中，Sherbrook 架构师 Md Shuvo 特别强调了这一点：
实际上，额外增加一个网络跳数能改善整体延迟，因为这可以使数据库节点免于承受连接管理带来的巨大开销。
ZGateway 还为负载均衡、跨区域容错、缓存和过载保护提供了集中管理平台。在 CPU 利用率超过 90% 的受控测试中，约 1350 个租户存储桶中有 6 个将流量分流，而其余租户处理了 99.9% 的请求且未出现任何拒绝处理的情况。Meta 可以按服务、分片前缀、百分比或区域逐步路由流量，并配备了用于回滚的全球紧急关闭开关。
Meta 计划将所有 ZippyDB 流量通过 ZGateway 进行路由，同时探索基于代理的控制机制、与 ZServer 的选择性共置，以及采用多进程架构来实现更强的故障隔离。
原文链接：https://www.infoq.com/news/2026/09/meta-zgateway-zippydb-proxy/