使用AWS SQS作为Aurora数据库的写入队列提高系统性能是否有效

Question

我正在 AWS 上开发需要支持高读写吞吐量的 Web 应用程序服务器。老大给了我这样的高级设计

我卡在 "Write Queue" 上了。团队告诉我，我们需要它来提高写入性能，因为我们只能写入 1 个主副本。我对SQS和RabbitMQ等消息队列有一些基础知识，但对将其用作数据库写入队列一无所知。

现阶段我有3个问题：

1. 使用这种架构，是否真的能够提高写入数据库的性能（相对于直接写入主副本）。

2. 如何处理事务，特别是在写入过程中出现错误时如何回滚。通常，我们会在应用程序代码中控制事务，当发生错误时，整个事务被回滚，App Server 响应给客户端一些错误代码。

3. 我提到我已经研究过使用消息队列作为写队列，但我不确定我是否在寻找正确的方向。也许，已经有一些其他技术适合作为数据库的写入队列？

除了问题之外，我认为这应该是一个很大的话题，我想知道我可以详细研究这个话题的资源。

Answer 1

在类似的情况下，队列被用作解耦两个系统的手段。实施此类架构模式时有几个优点和缺点。我会尝试列出我认为是主要的。

优势

1. 响应时间缩短

   由于队列不需要复杂的事务，因此它们通常是一种快速且如果配置正确则安全的存储。这意味着来自客户端的感知响应延迟将减少，给人一种服务 "faster" 的感觉。

2. 关注点分离

   正确解耦服务可以提高它们对错误的恢复能力。例如，如果 DB 不能接受更多的写请求，客户端将不受影响，并且他们的请求仍然不会丢失，因为它们将在队列中。这使运营商有更多时间对问题做出反应，而服务价值仅受到部分影响。

3. 改进的可扩展性

   当操作变得复杂时，将它们分成微组件通常是个好主意。扩展微组件比单体服务更容易。作业队列启用了这样的设计模式。

缺点

1. 从错误中恢复变得更加复杂

   如上所述，如果数据库停止接受请求，作业将堆积在队列中。现在您有 2 个问题需要处理：完整的数据库和完整的作业队列。系统问题开始像涟漪一样在您的体系结构中传播，导致一些副作用，并且很难理解根本原因是什么。

2. 识别瓶颈需要更多时间

   如果数据库写入很慢，在它前面放一个队列不会让事情变得更快。作业仍会堆积在队列中，您的下一个任务将是找出发生这种情况的原因。在处理复杂的 ETL 管道时，提高性能成为一项相当乏味的打地鼠操作，您的瓶颈只是从一个系统转移到另一个系统。

3. 每次操作的成本增加

   一项工作完成所需的阶段越多，该工作所需的时间和金钱就越多。

解耦组件通常被视为处理性能问题的灵丹妙药。正确分离关注点和责任是一种非常有益的做法，但需要大量的经验和细心。如今，单一服务被视为万恶之源。就我个人而言，我更喜欢处理一大堆意大利面，而不是分布式的。