最近的“停课不停学”给互联网教育行业这堆火又添了一把柴火。这把火烧的越旺，后台的资源越紧张，尤其是数据库。最近我就频繁接到一些用户有关数据库过载的求援。
解决这个问题，有两种思路：
- 优化数据库系统的架构，令其能够快速可持续的弹性扩容。
- 降低对关系型数据库系统依赖，最好能够实现即便数据库挂了，业务也不会挂。
快速弹性扩容，这里的关键词是快速，云服务商的数据库服务一般都支持增加只读实例，假如启动一个只读实例要很长时间，我们只能一直开着只读而不敢释放，这样本来的弹性支出就变成了固定支出。假如能够在5分钟之内完成只读节点的拉起提供服务，那么我们就可以根据业务的需求来随时拉起只读实例。我们都知道在线教育行业一般都有非常明显的业务高峰期，通过只在高峰期开启只读就可以节省大笔开支。
假如只能增加只读，写入很快就将变成另一个瓶颈，尤其是超大表的更新和写入操作。分库、分表成为下一阶段的必然选择。初期有分库分表的需求的数据库表和功能模块不是很多，采取直接在程序里编码的方式关系不大，随着“大表”越来越多，越来越多的模块都加入了分库、分表的代码。代码的味道就越来越不对了。于是负责维护代码的同学开始备受煎熬，对代码的洁癖催促他们赶紧把这些代码整合起来，但一整合就发现事情又没有那么容易，早知道就选择一些开源框架好了，但这样的框架就没有坑么？是不能可持续的保证性能扩展呢，毕竟数据库的事情关系重大。
关系型数据库快速持续的弹性扩容，这样的架构其实是现成的：
通过阿里云DRDS整合多个阿里云PolarDB，实现透明的水平拆分，及快速的弹性扩容。
阿里云DRDS 是一个分库分表中间件，也是阿里巴巴去O的功臣，经历过双十一的洗礼，经过这么多年的考验，“坑”早被填的差不多了，DRDS本身采用分布式架构，最大支持1024核4096GB内存。99%的用户都不会触碰到这个性能上限，从而能够实现可持续的性能弹性扩展。
PolarDB 是云原生数据库，采用共享存储架构，因为新增只读节点不需要复制数据，所以能够快速弹性扩容。PolarDB 单节点最大88核710GB内存，最大可扩展到16个节点。节点配置越高，随时弹性扩容节省的就越多。
解决问题的另一个思路是降低对关系型数据库的依赖，例如可以考虑在一些业务中使用NoSQL数据库。NoSQL数据库本身就是从互联网的高并发需求中催生出来的，无论是开源的HBase还是阿里云的表格存储都能够提供PB级的存储和千万级的并发处理能力。
除了NoSQL数据库，还可以考虑用一些消息队列服务来缓冲突然增加的业务压力对业务的冲击，用户的前台操作可以先放到消息队列中，再由后台服务取出慢慢处理。每年的双十一0点刚过的下单高峰就是通过阿里云的消息队列服务进行缓冲处理的。
另外，通过一些限流中间件可以将数据库等一些关键部门保护起来。可以根据业务的优先级将不同等级的服务对数据库的调用进行隔离，系统资源紧张时限制部分非关键业务对数据库的访问。阿里云AHAS高可用服务就是一个这样的限流中间件。
这种降低对关系型数据库依赖的方案还有很多，具体选择什么方案，以及与继续投入关系型数据库如何平衡还要看具体应用场景，改造成本和可预期的业务成长速度相关。
