CA，给了数据库，给了机器，为啥也扩不了容？

发布时间：2025-11-05 06:00:10 来源：码上建站 作者：应用开发

随着业务越来越复杂，数给机数据量越来越大，据库并发量越来越大，啥也数据库的数给机性能越来越低。好不容易找运维申请了两台机器，据库让DBA部署了几个实例，啥也想把一些业务库拆分出来，数给机却发现拆不出来，据库扩不了容，啥也尴尬!

因为数据库强关联在一起，数给机无法通过增加数据库实例扩容，据库就是啥也一个耦合的典型案例。

场景还原

有一个公共用户数据库DB_USER，数给机里面table_user存放了通用的据库用户数据：

在数据量比较小，并发量比较小，啥也业务还没有这么复杂的时候，为了提高资源利用率(程序员才没有考虑什么资源利用率，更多的是图方便)，业务A把用户个性化的数据也放在这个库里：

业务A有一个需求，即要展现用户公共属性，又要展现业务A个性化属性，程序员经常这么实现的：

初期关联查询没有任何问题，单条记录访问，***索引，云南idc服务商一次查询所有数据，简单高效。

如何产生各业务数据耦合?

通过join实现业务，导致通用表table_user和业务表table_A必须存在于一个数据库实例里。

如果业务B也这么做，业务C也这么做，会导致公用业务，业务A，业务B，业务C都必须存在于一个数据库实例里。

会产生什么潜在问题呢?

假如A业务线上线了一个新功能，不小心进行了全表扫描，导致数据库CPU100%，数据库实例性能下降，由于实例共用，通用业务，业务B和业务C都会受影响。

即某个业务线的数据库性能急剧下降导致所有业务都受影响，这种耦合，历史总是惊人的相似：

唉，加了几台机器，加了几个实例，然而并没有什么卵用，都耦合在一个实例里，完全扩不了容。

那，如何解除公共数据库与业务数据库的耦合?

***步：公共数据访问下沉服务化

还是上面的例子，当公共的user数据访问服务化之后，依据服务化的原则：

第二步：垂直拆分，个性化数据访问上浮

原来业务方：

两种方式相比：

业务复杂，数据量大，并发老大，对扩展性要求更高的架构，一定是后者。

此时各业务有自己的库，公共有公共的库：

个性业务数据访问垂直拆分，共性数据访问服务化下沉，只是一个很小的优化点，但对于数据库解耦却是非常的有效。

【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文

相关文章