我正在为一个应用程序设计一个中间层，该应用程序每隔几秒钟将接收多达 5000 个请求，并且需要从数据库中检索信息。我一直在考虑使用 Play Framework（我使用 scala 进行我的 REST api 设计），因为他们说它完全异步并建立在 Akka 之上。但是，任何解决方案的主要瓶颈似乎都发生在对数据库的读/写期间。许多数据库无法支持从这种规模的数据库同时读取/写入。那么这样的应用程序是如何实现如此高的并发性的呢？我猜 Facebook/Twitter/（其他大公司的名字）可能已经为他们的应用程序实现了这一点，因为数百万人可能同时使用它们。
【问题讨论】：
标签： concurrency architecture software-design
正如蒂姆的评论所说，缓存可能会或可能不会对您的情况有所帮助。如果不是，我还建议您研究水平可扩展的数据库，例如cockroachdb，如果您想要一个事务性 SQL 数据库。否则有很多无 SQL 选择，比如 mongodb 等。如果你真的想坚持传统的 SQL 系统，你将不得不垂直扩展你的服务器（购买最昂贵的硬件）并使用 read-replicas。
【讨论】：
一个巨大的组成部分是您的数据模型和查询访问模式。如果每个查询都在增加一个必须同步的共享计数器，则会出现大量争用，但如果每个查询在另一端触及完全独立的数据，那么争用就会少很多。
我认为我会考虑几个维度：
数据架构和访问模式（如上所述）
语言选择 这很重要，因为如果您在 Web 服务器上下文中并且默认情况下使用 prefork，则每个进程可能都有自己的数据库连接。在像 python 或 ruby 这样的环境中，您可能需要数百个进程来处理您的负载。将此与 akka 或其他基于异步网络的运行时（node、python gevent/asyncio、go 等）进行对比，其中具有小线程池的单个实例可以处理大量请求。各有各的取舍。
分布式系统
根据您的数据架构和访问模式，每秒向 RDBMS 发出 5000 个请求是完全可以实现的。它可能需要相对强大的硬件，但我个人已经做过很多次了。达到更大的规模需要更多的计算机来分配工作/负载。如果您的工作量很大并且您可以支持可能过时的读取，那么read replica 是一种选择。混合中的另一台机器读取分布在 2 台机器上，但写入仍然针对单个机器（领导者）。缓存是另一种选择。
在更高的工作负载下，需要进行某种分区以克服单台机器的限制。 https://github.com/vitessio/vitess
许多大型竞争者都有横向扩展其数据库的解决方案。这也有很多缺点，需要仔细规划。
我建议的一件事是，如果预计在不久的将来每秒有 5000 个请求，则从所需的最少硬件（单实例）查询模式开始，分布式数据库的操作会呈指数级增长。
【讨论】：