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

摘要

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

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

内容来源：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采集，实时监控数据库的运行状态。

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

安全：数据库帐号和操做的审计，基于服务器的安全设计。

我今天的分享就到这里，谢谢你们！