解DBA之惑：数据库承载能力评估及优化手段

比如,我们可能需要一个数据中间层,来屏蔽后面的分库分表细节.这个中间层可能需要完成语句解析、访问路由、数据聚合、事务处理等一系列功能.即使使用了中间层产品,对于应用来说,数据库的功能也会相对“弱化”,应用级代码不得不进行很多的调整来适应这种变化.此外,如何把一个线上正在运行的系统,顺利平稳地迁移到新的结构下,这无疑又是一个给飞驰的跑车换轮胎的问题等等.

如果项目在运行中,出现了数据库架构级的调整,很有可能说明在前期项目设计规划阶段出现了失误,或者对项目的业务预期出现了偏差.因此,这两点一定在初始阶段进行充分的评估,并在设计上保留有充分的“弹性”.

有些情况下,单纯依靠数据库是无法解决的,需要综合考虑整个应用架构.在整个系统架构中,数据库往往处于系统的最末端,其扩展性是最差的.因此,在应用架构设计初期,就应该本着尽量不要对数据库产生压力的原则进行设计.或者即使有大的压力,系统可以采取自动降级等方式保证数据库的平稳运行.

常见的例如增加缓存、通过MQ实现削峰填谷等.通过增加缓存,可以大幅度减少对数据库的访问压力,提高整体系统的吞吐能力.引入MQ,则可以将对数据库的压力以“稳态”的形式,向数据库持续施压,而不至于被某个异常高峰压死.

最后一种情况是从业务角度进行一些调整.这往往是一种妥协,通过做适当的减法保证系统的整体运行.甚至不排除牺牲一部分用户体验等方式,来满足大部分用户的可用性.这就需要我们的架构师对系统能提供的能力要很清楚,对业务也要有充分的了解.对于承载什么样的业务,及为了承载业务所需要花费的代价成本有充分的认知,才可以做出一些取舍.

这里要避免一些误区,认为技术是“万能”的.技术可以解决一定的问题,但不能解决所有问题,或者解决所有问题的成本代价是难以接受的.这个时候,从业务角度稍作调整,就可以达到“退一步海阔天空”的结果.

文章出处：DBAplus社群(订阅号ID:dbaplus)

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!