mysql - 即使在使用连接池后如何处理过多的并发连接？

Question

场景

假设您有一个拥有大量流量的网站或应用。即使使用数据库连接池，性能也会受到真正的打击(站点/应用程序甚至可能崩溃)，因为并发连接太多。

问题

处理这个问题的人有哪些选择？

我的想法

我在想有这个问题的人可以创建多个数据库(可能在不同的机器上，虽然我不确定是否有必要)，每个数据库都具有相同的信息并同时更新，这将授予原始数字的倍数单个数据库的连接数。但如果数据库很大，这似乎不是一个非常可行的解决方案。

Answer 1

词干不够具体，无法给出坚定的建议，但可以做的事情的完整列表如下:

• 数据库集群:适用于不想改变应用层，只需要接触数据库的情况。您可以从数据库集群中获得多少是有限制的。如果您的请求量持续增长，此解决方案最终也会失败。但好消息是，您拥有普通单实例 MySQL 中已有的所有功能。
• Sharding:由于您的问题带有 MySQL 标签，并且它本身不支持分片，如果您想使用此解决方案，您需要在应用层实现它。在此解决方案中，您将逻辑上将数据分散到多个数据库(最好是在不同硬件上的多个 MySQL 实例中)。您有责任找到保存您指定数据的适当数据库。这是有史以来最有效的解决方案之一，但并不总是可行的。它最大的缺陷是分散在两个或多个数据库中的数据不能包含在一个事务中。
• 复制:根据您的情况，您可能能够合并数据库复制并在其中拥有数据副本。这样您就可以连接到它们而不是 master 数据库并减少它的负载。默认的复制定义是主/从场景，其中数据流是单向的，从主到从。因此，您可能对从服务器所做的更改将应用​​于从服务器，它们不会影响主服务器。但也有一种主/主复制配置，其中数据双向流动。然而，您不能假设两个主控之间并发数据更改的原子完整性。最后，如果您计划在主/从模式下使用它并使用从属设备进行只读访问，则此解决方案最有效。
• 缓存:也许这个解决方案不应该包含在这里，但是因为你的词干不拒绝它，所以就在这里。减少数据库负载的方法之一是在提取数据后对其进行缓存。如果提取数据的成本很高，则此解决方案特别有用。那里有很多缓存服务器，比如 memcached或 redis .这样您就可以省略很多数据库连接，但仅用于提取数据。
• 其他存储引擎:如果您当前的引擎不能满足您的需求，您可以随时切换到性能更高的引擎。当然，这只有在您的需求允许的情况下才可行。现在有 NoSQL 引擎，比 RDBMS 性能更高，它本身支持分片，你可以用最小的努力线性扩展它们。还有基于 Lucene 的解决方案，具有强大的全文搜索功能，可为您提供相同的自动分片。事实上，您应该使用传统 RDBMS 的唯一原因是事务的原子行为。但是，如果事务不是必须的，那么还有比 RDBMS 更好的解决方案。