@Azure：轻松扩展 PostgreSQL 读取。在 #AzureFriday，@shanselman 和 Paula Berenguel 展示 PostgreSQL Flexible Serv…

轻松扩展 PostgreSQL 读取。在 #AzureFriday 中，@shanselman 和 Paula Berenguel 展示了 PostgreSQL 灵活服务器如何利用只读副本和虚拟终结点来处理繁重的读取工作负载。

立即观看：https://t.co/tGKvvqCGhm https://t.co/dowBQRHNMw

TL;DR：Azure Database for PostgreSQL 灵活服务器上的读取密集型 PostgreSQL 工作负载可以通过只读副本轻松扩展——每个主实例最多 30 个副本——采用与 ChatGPT 相同的模式。

ChatGPT 运行在 Postgres 上

Scott Hanselman 在节目开场时对 Postgres 的扩展是否真的如此简单表示怀疑。他的嘉宾 Paul 分享了一个令人惊讶的事实：

最令人惊讶的是，大多数人不知道 ChatGPT 背后的数据库实际上是 Postgres。它有一个主实例和只读副本——没有分片，也没有花哨的分布式引擎。

Scott 确实很惊讶：他原以为 ChatGPT——这个“世界级计算机”——会运行在某种远比支撑他自己网站的技术更独特的东西上。Paul 澄清说，ChatGPT 在很大程度上是由 Postgres 支撑的，更重要的是，OpenAI 使用的模式是任何开发人员都可以应用到自己的项目中的。

模式：一个主实例负责写入，副本负责读取

Paul 的核心观点：开发人员往往忘记了应用程序的读取操作远多于写入。当读取流量增长、CPU 飙升时，大家的本能反应是求助于分片、分布式数据库或一种完全不同的技术。但对于 Azure Database for PostgreSQL 灵活服务器——以及一般意义上的 Postgres——最简单的答案通常是只读副本。

这种模式如下：

• 主节点负责处理写入。
• 只读副本负责横向扩展读取。

演示架构：主实例位于英国南部，副本遍布欧洲

演示架构模仿了 OpenAI 服务 GPT 用户的方式。主实例部署在英国南部，副本分布在整个欧洲。Paul 在演示中选择了意大利北部和西班牙中部，但他强调，你不必局限于某个区域位置：

不要把副本局限在欧洲。它们可以放在澳大利亚，也可以放在美国。在这个案例中，我只是想模仿 OpenAI 服务 GPT 用户的方式——按大洲划分，让数据更接近实际用户。

演示中部署了三个副本，但这只是所有可能配置中的一小部分。

虚拟终结点：无需更改连接字符串即可实现故障转移

演示中还包括一个虚拟终结点，Paul 说这个功能经常被忽视。它的主要用途是故障转移：如果发生灾难，迫使你将主实例切换为某个副本，应用程序无需做任何更改。应用可以无缝过渡到新的主实例并继续运行。

这是人们经常忽视的事情之一，也是我从客户那里经常听到的问题：“如何在不更改应用程序连接字符串的情况下，在 Azure 中实现跨区域故障转移？”

Paul 明确提到一个限制：目前你不能使用虚拟终结点在所有副本之间进行负载均衡。这仍然是应用程序的责任。

副本有多新鲜？副本延迟

Scott 问了一个实际问题：如果他向英国南部的主实例写入数据，然后立即从西班牙中部的副本读取，延迟会是多少？毫秒？秒？还是天？

Paul 的回答：副本——即使是跨区域的，甚至是远在澳大利亚的副本——的延迟时间都应保持在个位数秒以内，通常不超过 10 秒。实际延迟取决于两个因素：

• 主实例与副本之间的距离
• 写入量——主实例承受的压力

在实践中，通常只需要几秒钟。

读写一致性属于应用程序层面的关注点

Scott 进一步追问：如果他的应用程序需要立即访问刚刚写入的数据，该怎么办？Postgres 有没有什么设置可以提供快速访问，还是说这是一个应用层问题？

Paul 确认这是一个应用层问题。有些应用程序可以容忍这种小延迟，以换取从副本读取的好处。另一些则不能：

如果他们必须在提交后立即读取——立刻看到自己提交的内容——他们通常必须把这种读写功能保留在主实例上，或者你需要考虑其他解决方案。

好消息是：开箱即用，应用程序无需做任何事即可从复制中受益。所有复制工作都由 Postgres 灵活服务器处理。

在 Azure 门户中创建副本

Paul 在门户中进行演示，所有内容都已为演示预先配置好——但你自己创建副本也很简单。在“复制”选项卡中，你可以：

• 选择副本区域（例如，意大利北部、西班牙中部）
• 选择副本大小——你可以创建规格高于或低于主实例的副本
• 查看复制阶段
• 检查当前的延迟时间

门户视图也便于向管理层展示复制正在正常工作。这里也是你配置虚拟终结点的同一个位置。

演示第 1 部分：对主实例施压

为了展示副本的价值，Paul 首先设置了一个基线工作负载，所有操作都针对英国南部的主实例执行。这个基准测试应用模拟了一个典型的聊天机器人：

• 检索你的会话
• 在会话中搜索
• 为用户创建新会话

该工作负载以读取为主，并混合了一些写入。当基线脚本运行时，主实例的 CPU 不断攀升。Paul 放大了 Azure 门户图表——粒度为 1 分钟——CPU 达到 97%。

需要说明的是，此时副本已经存在，但完全处于空闲状态，就好像它们根本不存在一样。这个场景演示了当你在一个 Postgres 主实例上运行所有操作时会发生什么。

演示第 2 部分：将读取卸载到副本

Paul 停止了基线应用——该应用在 257 秒内执行了 37,000 个查询。在真实应用中，你不需要停止任何操作；只需将读取指向副本即可。但在演示中，他运行了一个切换脚本，将流量路由到：

• 写入 → 英国南部主实例
• 读取 → 只读副本

该设置包括 6 个读取器和 4 个写入器，每秒触发大约 80 到 170 个查询。

回到 Azure 门户，主实例的 CPU 开始下降——它仍然处理写入，但读取压力消失了。与此同时，副本的 CPU 随着它处理应用程序的读取请求而上升。如果需要，你还可以将负载进一步分散到更多副本上。

这就是减轻主实例压力、为更多功能、更高性能和更大可扩展性腾出空间的方法——这一切都通过灵活服务器实现。

你能扩展多大规模？30 个副本，以及副本的副本

Scott 问了一个显然的后续问题：他可以拥有任意多的副本，部署在世界各地的区域——就像 ChatGPT 那样吗？

是的，你最多可以拥有 30 个副本。

Paul 接着解释了层级结构：

第一层可以有 30 个，而每一个第一层副本还可以再有 5 个。

意识到这一点后，Scott 询问多层复制是如何运作的。在这种场景下，如果 Azure Friday 的主实例位于英国南部，你可以导航到某个副本的复制页面，在其下面再创建 5 个副本。

哦，真的吗？这就是副本的副本。

Paul 确认——副本的副本——并提醒说，如果链条中的某个区域发生故障，整个副本链都会受到影响。

要点总结

在 Postgres 上扩展读取并不需要分布式数据库，也不需要迁移到新技术。借助 Azure Database for PostgreSQL 灵活服务器，你可以保留一个主实例用于写入，在世界各地添加只读副本，并处理海量读取流量——第一层最多 30 个副本，每个副本还可以再拥有 5 个。支撑互联网上使用最广泛的应用程序之一的同一模式，如今任何开发人员都可以通过 Azure 门户使用。

来源：轻松扩展 PostgreSQL 读取 | Azure Friday (https://www.youtube.com/watch?v=Pkg1_4e3i2I)