摘要

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

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

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

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

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

为什么要做分布式？

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

高容量：业务增长，产生大量在线数据。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我今天的分享就到这里，谢谢大家！