我正在 AWS 上开发一个 Web 应用程序服务器，需要支持高吞吐量的读写。我的老板给了我这样的高级设计。
我被困在“写入队列”上。团队告诉我，我们需要它来提高写入性能，因为我们只能有 1 个可以写入的主副本。我对 SQS 和 RabbitMQ 等消息队列有一些基本知识，但对将其用作数据库写入队列一无所知。
现阶段我有3个问题：
使用这种架构，是不是真的能够提高写入数据库的性能（相对于直接写入主副本）。
当写入过程中出现错误时，如何处理事务，特别是如何回滚。通常，我们会在应用程序代码中控制事务，以便当发生错误时，整个事务回滚，并且应用程序服务器向客户端响应一些错误代码。
我提到我已经研究过使用消息队列作为写入队列，但我不确定我是否在寻找正确的方向。也许，已经有一些其他技术适合作为数据库的写入队列？
除了问题之外，我认为这应该是一个大主题，并且想知道我可以详细研究该主题的资源。
在类似的情况下，队列被用作解耦两个系统的手段。实现此类架构模式有几个优点和缺点。我将尝试列出我认为主要的内容。
优点
-
改进的响应时间
由于队列不需要复杂的事务，因此它们通常是一种快速且安全的存储（如果配置正确）。这意味着来自客户端的感知响应延迟将会减少，给人一种服务“更快”的感觉。
-
关注点分离
正确地解耦服务可以提高其对错误的恢复能力。例如，如果数据库无法接受更多写入请求，客户端将不会受到影响，并且它们的请求仍然不会丢失，因为它们将在队列中。这使得运营商有更多的时间来应对问题，而服务价值仅受到部分影响。
-
提高可扩展性
当操作变得复杂时，将它们分成微组件通常是个好主意。扩展微型组件比单体服务更容易。作业队列支持这种设计模式。
缺点
-
从错误中恢复变得更加复杂
如上所述，如果数据库停止接受请求，作业将堆积在队列中。现在您有两个问题需要处理：完整的数据库和完整的作业队列。系统问题开始像涟漪一样在您的架构中传播，导致一些副作用，并且很难理解根本原因是什么。
-
识别瓶颈需要更多时间
如果数据库写入速度很慢，那么在它前面放置一个队列并不会让事情变得更快。作业仍然会堆积在队列中，您的下一个任务将是找出发生这种情况的原因。在处理复杂的 ETL 管道时，提高性能变成了一项相当乏味的打地鼠操作，其中瓶颈只是从一个系统转移到另一个系统。
-
每次操作的成本增加
一项工作需要经历的阶段越多，所需的时间和金钱就越多。
解耦组件通常被视为处理性能问题的灵丹妙药。正确分离关注点和责任是一种非常有益的做法，但需要大量的经验和细心。如今，单一服务被视为万恶之源。就我个人而言，我更喜欢处理一堆整体的意大利面条，而不是分布式的意大利面条。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
