让数据库不再成为业务发展瓶颈——分布式数据库架构设计

4,244 阅读5分钟


摘要

企业如何实现高容量大并发数据库服务?公司业务高速发展,单实例数据库到达瓶颈的情况下,如何做好分布式设计,提供高并发高性能的数据库服务以支撑业务增长?

本次分享主要内容包括数据库分布式架构设计思路,拆分原理,改造难点,解决方案等,让数据库不再成为业务发展瓶颈。

内容来源:2017年6月4日,袋鼠云首席数据库架构师宏翊在“企业互联网架构优化升级之路”进行《让数据库不再成为业务发展瓶颈——分布式数据库架构设计》演讲分享。IT 大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。

阅读字数:1705 | 3分钟阅读

嘉宾演讲视频回放:t.cn/RQCVFyS

为什么要做分布式?

高并发:分布式应用带来更大量的数据库请求。

高容量:业务增长,产生大量在线数据。

资源向上扩展存在天花板。

支撑业务高速发展,平滑扩容。

拆分原则:循序渐进


在业务初期,客户量比较少,可以把所有服务和数据都存在一个实例上,都能支持业务的发展。

发展之后的客户量、数据量和并发都上来了,这时数据库很容易出现瓶颈。我们建议大家首先进行服务化的改造,将不同的业务模块做垂直梳理,把不同服务的数据库相互隔离,中间的交互由业务上去实现。这样数据库就可以分布在不同的实例上,能够支持相对较高的并发和容量。

继续发展的话,实例依然是一个瓶颈,这时我们就要考虑做水平的拆分。把一个服务的数据分布到不同的实例上,以支持扩展、高并发、大容量的数据库服务。

拆分需要循序渐进,然后做服务的梳理,最后再做水平拆分。

水平拆分会引入一些复杂性,研发方面需要考虑的东西就比较多,所以需要谨慎地做拆分。数据库的拆分和业务架构紧密结合,有时在业务上的一个小改动完全可以把压力挡在数据库之外。

水平拆分的难点

水平拆分的一个服务数据会分布到不同的底层数据库上,所以会带来一些复杂性。

系统架构需要适应数据库的分布式,就需要做一些改造。面临的技术挑战就是应用需要处理复杂的分布式逻辑,比如分布式的事务、跨库查询。在稳定性方面也会有一些挑战,但不是最主要的。主要是分布式的局限性,分布式数据分布在不同的数据库上,它不支持跨库的join、分布式事务、以及全局sequence等。

解决方案:客户端实现数据路由

在客户端直接做一个配置,去实现路由的功能。它的好处就是不需要引入额外模块,整体架构不变;程序的把控力强,场景简单方便使用;对代码的侵入性强;配置管理复杂。

此方案不会引入额外的组建,架构上比较轻量,简单场景使用尚可,比如配置管理复杂等,不建议使用。

解决方案:数据库中间件

实现自动分库分表,对应用透明;使用门槛极低,应用改造量小;方便的动态水平扩容;针对分布式的各种定制功能,如异构索引、小表广播等;最重要的是,有了数据库中间件,应用看到还是单一的数据库。

中间件的使用最大限度的屏蔽了分布式数据库所引入的复杂性,极大降低了研发的门槛。




DRDS功能简介

分库分表是DRDS的核心功能,支持数据的多维度切分和路由访问;内建读写分离功能,可以灵活配置访问权重;自带全局唯一ID组件;查询引擎识别和下推复杂查询,兼容98% MySQL语法;弹性扩容组件实现自动化在线水平扩容。


DRDS物理框架

数据拆分,能够组合1K个MySQL;分布式SQL查询引擎与高度的SQL兼容性;数据存储的平滑扩容;处理性能的弹性伸缩;读写分离(应用透明);小表广播、跨库join、全局sequence。


主库和读库通过数据库的原生复制实现,数据是强一致的。DRDS会自动判断请求,然后做分发。事务性的操作全部路由到主库上去,读库则承担一些读的操作。


把join从DRDS层往下推,在MySQL层实现它的join,业务设计上要避免跨库join。


分布式SQL规范设计:最佳实践

查询尽可能带上分库条件。如果把一个表拆分到底层的十个库,查询的时候每次都带上一个拆分条件,DRDS能够很清楚地把请求路由到底层的库上。

Join的时候有几种解决方案。一种是两个表的分库键都相等去做join,这样就能限定在一个库上。还有一种是广播表,join的字段不一样,但是每个表都带上分库的条件,这样还是会限定在同一个库里面。


EasyDB:数据库自动化管理平台

资源:实时监控数据库和服务器空间的使用状态。

高可用:云上高可用架构设计,故障自动切换。

备份:定期的数据库全量,增量备份,可灵活配置。

监控:异常情况下自动捕获和告警,支持短信,邮件和微信通知。

性能:超过50个指标性能趋势和SQL采集,实时监控数据库的运行状态。

日志:数据库错误日志采集。

安全:数据库账号和操作的审计,基于服务器的安全设计。

我今天的分享就到这里,谢谢大家!