内容来源：2017年6月4日，袋鼠云首席数据库架构师宏翊在“企业互联网架构优化升级之路”进行《让数据库不再成为业务发展瓶颈——分布式数据库架构设计》演讲分享。IT 大咖说（ID：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。
阅读字数：1705 | 3分钟阅读
获取嘉宾演讲视频回放及PPT，请点击：http://t.cn/RkDNJ0l
摘要
企业如何实现高容量大并发数据库服务？公司业务高速发展，单实例数据库到达瓶颈的情况下，如何做好分布式设计，提供高并发高性能的数据库服务以支撑业务增长？
本次分享主要内容包括数据库分布式架构设计思路，拆分原理，改造难点，解决方案等，让数据库不再成为业务发展瓶颈。
为什么要做分布式？
高并发：分布式应用带来更大量的数据库请求。
高容量：业务增长，产生大量在线数据。
资源向上扩展存在天花板。
支撑业务高速发展，平滑扩容。
拆分原则：循序渐进
在业务初期，客户量比较少，可以把所有服务和数据都存在一个实例上，都能支持业务的发展。
发展之后的客户量、数据量和并发都上来了，这时数据库很容易出现瓶颈。我们建议大家首先进行服务化的改造，将不同的业务模块做垂直梳理，把不同服务的数据库相互隔离，中间的交互由业务上去实现。这样数据库就可以分布在不同的实例上，能够支持相对较高的并发和容量。
继续发展的话，实例依然是一个瓶颈，这时我们就要考虑做水平的拆分。把一个服务的数据分布到不同的实例上，以支持扩展、高并发、大容量的数据库服务。
拆分需要循序渐进，然后做服务的梳理，最后再做水平拆分。
水平拆分会引入一些复杂性，研发方面需要考虑的东西就比较多，所以需要谨慎地做拆分。数据库的拆分和业务架构紧密结合，有时在业务上的一个小改动完全可以把压力挡在数据库之外。
水平拆分的难点
水平拆分的一个服务数据会分布到不同的底层数据库上，所以会带来一些复杂性。
系统架构需要适应数据库的分布式，就需要做一些改造。面临的技术挑战就是应用需要处理复杂的分布式逻辑，比如分布式的事务、跨库查询。在稳定性方面也会有一些挑战，但不是最主要的。主要是分布式的局限性，分布式数据分布在不同的数据库上，它不支持跨库的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采集，实时监控数据库的运行状态。
日志：数据库错误日志采集。
安全：数据库账号和操作的审计，基于服务器的安全设计。
我今天的分享就到这里，谢谢大家！