扩展Nextdoor的数据库：第二部分

In the second installment of Nextdoor’s “Scaling Nextdoor’s Datastores” blog series, the Core-Services team discusses challenges faced after implementing database read replicas.

在 Nextdoor 的“扩展 Nextdoor 的数据存储”博客系列的第二篇文章中，核心服务团队讨论了在实施数据库读取副本后面临的挑战。

Adding read replicas to an existing database is a very common pattern as applications or products evolve to handle increased demand. Typically, the implementation details are hand waved and it’s assumed that this strategy will work. However, that is rarely the case, and we’ll dive into some more of the intricacies around the implementation.

向现有数据库添加读取副本是一个非常常见的模式，因为应用程序或产品发展以应对增加的需求。通常，实施细节被简化，假设这一策略会有效。然而，情况往往并非如此，我们将深入探讨实施过程中的一些复杂性。

Initial Attempt

初步尝试

When replicas were first introduced in the Nextdoor stack, we gave the product engineers latitude to choose when they wanted to have their query routed to a read replica or to the primary. This was done by leveraging the existing routing mechanism in our ORM, Django.

当副本首次在 Nextdoor 堆栈中引入时，我们给予产品工程师选择何时将查询路由到读取副本或主节点的自由。这是通过利用我们 ORM Django 中现有的路由机制来实现的。

This seemed like the right idea at the time because the product engineers had the most context around consistency requirements within their changes and load characteristics of their product feature. Therefore, they would have the best ability to judge which node to send their query to. However, as our business logic evolved and became more feature-rich, product engineers began to add abstraction layers to help abstract complex operations away from business logic.

当时这似乎是个正确的想法，因为产品工程师对其更改中的一致性要求和产品特性的负载特征有最充分的背景知识。因此，他们在判断将查询发送到哪个节点时具有最佳能力。然而，随着我们的业务逻辑不断发展并变得更加丰富，产品工程师开始添加抽象层，以帮助将复杂操作从业务逻辑中抽象出来。

In this design evolution there is a high frequency read, followed by a low frequency conditional write, followed by a read. The read performed after the write should be routed to the primary, but that may get buried in abstractions and this requirement regressed.

在这个设计演变中，首先是高频读取，接着是低频条件写入，然后是读取。写入后执行的读取应该路由到主数据库，但这可能会被埋在抽象中，导致这一要求退化。

The explicit routing decisions engineers made b...