阿里面试题解析：分库分表后的无限扩容瓶颈与解决方案

本文来源于方志朋的博客，回复“666”获取面试宝典。

作为一名初级开发者，总是会遇到各种技术问题，从最初的JDK API、NIO到JVM，再到服务的可用性和可扩展性。本文重点讨论服务的扩容问题。

服务架构的演变

让我们从最简单的单体应用说起。

1. 单体应用：大多数初创公司都是从这种架构开始的，使用SSM或SSH等框架，每个程序员都经历过这一阶段。

2. RPC应用：随着业务的增长，我们需要对服务进行水平扩容。只要服务是无状态的，扩容就相对简单。如下图所示：

   

当业务进一步扩大时，服务之间的关系变得复杂，很多服务只需要连接缓存，而不需要连接数据库。此时，可以将这些服务分离出来，以减少数据库的连接压力。如下图所示：

许多公司都停留在这个阶段，使用Dubbo来解决服务间通信的问题。

如果业务继续增长，数据量激增，SQL操作变慢，数据库将成为瓶颈。这时，通常会采用分库分表的策略，通过ID哈希或范围划分等方式来分散数据。如下图所示：

然而，分库分表真的能实现无限扩容吗？实际上，这种架构仍然存在瓶颈，尤其是数据库连接数过多的问题。

在RPC应用中，应用通过中间件（如Sharding JDBC）访问数据库，应用本身并不知道具体连接哪个数据库。这导致每个应用都需要与所有数据库建立连接。例如，如果有30个RPC应用，每个应用的数据库连接池大小为8，那么每个MySQL实例需要维护240个连接。MySQL的默认连接数为100，最大连接数为16384，这意味着超过2048个应用就无法继续扩容。

即使通过代理来解决连接数问题，代理本身的性能也会成为瓶颈。如果并发请求超过16384，代理也无法解决问题。

那么，如何解决这个问题呢？

单元化方案

单元化是一种高级的架构模式，通常在大型分布式系统中使用。其核心思想是让每个应用只连接特定的数据库，而不是所有数据库。

假设我们将数据按范围划分为10个库，有10个应用，每个应用只连接一个库。当应用数量增加到20个时，可以将10个库扩展为20个库，从而避免数据库连接数过多的问题。

实现这一点的关键在于确保每个请求都能正确路由到相应的应用和数据库。通常，这需要一个全局的规则，例如通过用户ID哈希，并由配置中心广播该规则。这样，所有组件都能保持一致的规则，正确访问数据库。如下图所示：

通过单元化，我们可以实现真正的无限扩容。

总结

本文从单体应用出发，逐步介绍了服务架构的演变过程，指出了分库分表并不能完全解决无限扩容的问题，而单元化才是有效的解决方案。尽管单元化带来了更多的复杂性，但其带来的好处显而易见。

需要注意的是，单元化虽然解决了无限扩容的问题，但还需要考虑服务的可用性，例如数据库的单点问题。

来源：thinkinjava.cn/2019/01/fkfb/

热门内容： 使用Nacos踩坑经历 Java泛型：你可能还没用过的高级特性 面试官问：MySQL的自增ID用完了怎么办？ 王者荣耀英雄的生成机制 饿了么CTO观点：框架不应被滥用 最近面试BAT，整理了一份《Java面试BAT通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等内容。获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。

明天见(≧∇≦)/♡