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