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