分布式系统「伸缩性」大招之——「水平&垂直切分」详解

如果第二次看到我的文章，欢迎文末扫码订阅我的公众号（跨界架构师）哟~  >

本文长度为5389字，建议阅读14分钟。

坚持原创，每一篇都是用心之作～

 

 

没想到这篇文章写了这么长，一时半会没消化完的话，可以收藏一下先。

 

 

这是「伸缩性」章节的第四篇，先给新来的小伙伴们简单回顾下前三篇的内容。

 

做「伸缩性」最重要的就是先做好「无状态」，如此才可以随心所欲的进行横向“扩展”，而不用担心在多个副本之间切换会产生错乱。《分布式系统关注点——「无状态」详解》聊的就是这个。

 

不过，就算做好了横向扩展，本质上还是一个“大程序”，只是变得「可复制」了而已。

 

如果要消灭“大程序”，那就得“切分”，做好切分必然离不开「高内聚低耦合」的核心思想。《分布式系统关注点——「高内聚低耦合」详解》这篇聊的就是这个。

 

题外话：当你遇到单点单应用支撑不住使用的时候，Z哥给你的普适性建议是：先考虑“扩”，再考虑“切”。这个和写代码一样，“增加”新功能往往比在老功能上改容易。

 

“扩”的话先考虑「垂直扩」（加硬件，钱能解决的都不是问题），再考虑「水平扩」（无状态改造+多节点部署，这是小手术）。

 

“切”的话一般就是「垂直切」（根据业务切分，这是大手术），偶尔会用到「水平切」（其实就是单个应用里的分层，比如前后端分离）。

 

 

第三篇《分布式系统关注点——弹性架构》我们聊了常见的两种「松耦合」架构模式，为的是让应用程序的「伸缩性」更上一层楼。

 

 

以上这些呢都是应用程序层面的工作。一般情况下，在应用程序层面做做手术，再配合以缓存的充分运用，就可以支撑系统发展很长时间了。特别是数据量不大，只是请求量大的「CPU密集型」场景。

 

但是，如果所处的工作场景是一个非常成熟且具有一定规模的项目，越发展到后面瓶颈总是出现在数据库这里。甚至会出现cpu长期高负荷、宕机等现象。

 

在如此场景下，就不得不对数据库开刀了。这次Z哥就来和你聊聊做数据库的「伸缩性」有哪些好方法。

 

 

核心诉求

面临数据库需要开刀的时候，整个系统往往已经长成这个样子了。

 

 

正如前面所说，这时候的瓶颈往往会体现在「CPU」上。

 

因为对数据库来说，硬盘和内存的扩容相对容易，因为它们都可以直接用“增加”的方式进行。

 

CPU就不同了，一旦CPU飙高，最多检查下索引有没有做好，完了之后基本就只能干看着。

 

所以解决这个问题的思路自然就变成了：如何将一个数据库的CPU压力分摊到多个CPU上去。甚至可以做到按需随时增加。

 

那这不就是和应用程序一样做「切分」嘛。也是分布式系统的「分治」思想体现。

 

既然是切分，本质上就和