对话DDM：分布式数据库中间件全解析

进入云计算时代，传统的数据库在性能和容量等方面已没法知足企业的要求，随着数据量的不断骤增，易于扩展、拆分的数据库解决方案对于企业的云化转型更是显得尤其重要。为使企业应用上云更简单，分布式数据库中间件DDM（Distributed Database Middleware）专一解决企业在上云过程当中面临的的数据库瓶颈难题，不但更能轻松知足水平拆分、扩容、读写分离等业务需求，同时也比传统方案更具性价比。接下来让咱们一块儿零距离解密DDM。

DDM是什么？

DDM专一于解决数据库分布式扩展问题，它突破了传统数据库的容量和性能瓶颈，实现海量数据高并发访问。DDM提供了对应用透明的数据库读写分离、自动的数据分片、灵活的弹性伸缩等分布式数据库能力。

DDM如何定义读写分离？

从数据库的角度来讲，对于大多数应用来讲，从集中到分布，最基本的一个需求不是数据存储的瓶颈，而是在于计算的瓶颈，即SQL查询的瓶颈，在没有读写分离的系统上，极可能高峰时段的一些复杂SQL查询就致使数据库系统陷入瘫痪，从保护数据库的角度来讲，咱们应该尽可能避免没有主从复制机制的单节点数据库。传统读写分离解决方案耦合应用代码，扩容读节点或修改读写分离策略等须要修改应用代码，升级应用程序，很是复杂。DDM实现了透明读写分离，应用实现读写分离不须要修改代码，为了保证读一致性， 默认状况在事务中的读所有分发到主节点。事务外的读分发从节点。写分发主节点。在应用程序需求复杂时，DDM提供了hint可由程序自主控制sql的读写分离逻辑。此外，后端DB若是部分节点故障了，DDM会自动摘除故障节点，自动进行主从切换，对应用无感知。

( 附改造先后构架对比图)

应用在微服务架构下，服务会拆分的比原来更多，与数据库的链接数也会增长不少，这是否一样是分布式数据库中间件须要解决的一个重要问题？

对的。举个栗子，好比某应用的最大链接数是2000，未作服务化拆分前，应用程序独享2000个数据链接，假设拆分红100个微服务，那么为了保证总的链接数不超过MySQL的最大链接数，那么每一个微服务能配置的最大链接数就是20.这对应用几乎是不可接受。市面上不少分库分表中间件如Cobar、Atlas等，对后端MySQL的链接池管理是基于分片来实现的，而不具有整个MySQL实例的共享互通，抗并发能力被严重削弱。而DDM是真正基于MySQL实例模式实现的，一个MySQL实例下的全部数据库共享一个链接池。这个对于分片来说，能避免有些库的链接很空闲，有些库的链接不够用的状况，最大限度提升并行性。其中涉及到session级别的属性由DDM自动维护，应用程序无感知。

在这种共享模式下链接数有上限吗？

DDM的前端链接与MySQL链接对比起来相对轻量级，能够相对轻松支持上万的链接。固然，为了防止单个用户滥用资源，支持设置前端最大链接数限制。

( 附改造先后构架对比图)

在应用场景上，是否必定要用DDM的方式去解决？这里一样也有硬件升级、数据库自身的分区方案，该如何选择？

硬件方案因为成本高和扩展性差的问题在这里就不谈了，而数据库自身的分区表方案，只能局限在一个库内，数据没法跨库跨实例，扩展方案有限，DB故障和调整都须要应用同步调整，运维难度剧增，升级维护工做量大，小型系统还好，对于大型系统不可接受，长期来看采用分布式数据库中间件是解决之道。

DDM如何作分片设计？

对于分布式数据库中间件，业内广泛有如下两种作法，第一种，认为分片算法的选择对用户来讲是一种心智负担，应该对用户彻底隐藏，另一种观点认为应该给用户彻底自由去选择，好比一些开源软件，提供了十几种分片算法。DDM认为若是彻底隐藏分片字段和分片算法的选择，可能会形成没必要要的全表扫描，浪费资源，没法作到线性扩展。由于最了解业务的仍是用户本身。分片算法过多的确会带来选择上的负担，有些算法存在主要是由于缺乏平滑扩容存在的不得已而为之。DDM设计了三种标准分片算法，hash、range、list，后续酌情开放自定义算法。

这三种算法具体是？

1. hash：hash算法的特色的数据分布比较均匀，无热点问题，缺点是若是有针对部分范围的查询，须要全分片扫描。hash类数据扩容须要迁移数据，DDM有平滑扩容功能，因此这块不用担忧。
2. range：数据按数字范围或者日期范围进行分片，针对范围的查询能够并行，可是缺点范围是单个范围可能会有热点问题，好比按日期最近一个月的数据操做会比较多，按范围就只其中一台或少许几台机器能够负担操做。范围分片在扩容时不须要迁移数据，只须要将新范围配置到新加的RDS便可。
3. list：枚举分片能够看作range的一个特例，在此再也不赘述。

hash算法的设计？

hash算法的设计，主要考虑到与平滑扩容的配合，采用二级映射分片规则，主要为了方便控制slot到实际dataNode的映射关系，而一致性哈希这里是算法固定。

与传统方案相比，DDM在扩容上有什么独特的优点？

传统作法DBA手工迁移数据，要停机，影响业务，迁移过程可能会出错。业内不少中间件的实现扩容方式通常是按照整库迁移的方案，好比原先有8个分库，迁移只是将部分库整库迁移到新的RDS上，这样的弊端是分片个数并无增长。DDM的作法是真正实现了数据重分布，按slot为单位迁移数据，迁移完成后保证数据的大体分布均匀。分片个数随着新增RDS而自动增长。DDM在操做上真正作到了自动化，实现了一键式迁移，迁移过程当中切换路由、清理数据均是自动化完成，不须要用户时刻盯着再去操做。即便迁移中出现异常，也会自动回滚，保证迁移数据的一致性。迁移过程当中不阻塞业务，只在切换路由时短暂中断写入操做，读操做正常，并且只影响到被迁移的那部分数据的写入，对其余数据彻底没有影响。

( 附迁移流程图)

在路由切换速度和内容准确性上DDM有哪些考虑？

关于切换路由速度，虽然业内不少号称毫秒级，通常是省略了数据校验，或者只校验条数。号称是算法精巧已经测试比较充分了。DDM认为即便测试已经充分了也难以保证百分之一百保证不出问题。因此DDM经过设计了快速的校验算法，对数据的内容进行校验，即便数据有一点点不同，算法也能校验出来，同时充分利用了RDS的计算能力提升校验的速度。

在通常的大型应用里，有的表数据量很大，有的表数据量少且不怎么更新，DDM是如何作到不一样类型场景的支持？

针对业务会遇到的实际场景，DDM设计了三种表类型：分片表：针对那些数据量很大的表，须要切分到多个分片库的表，这样每一个分片都有一部分数据，全部分片构成了完整的数据；单表：针对数据量相对比较少，没有和其余分片表join查询的需求。单表数据保存在默认当一个分片上，这种设计能够尽可能兼容单表自身的复杂查询；全局表：针对数据量和更新都比较少，可是和其它分片表有join的需求。全局表每一个分片上保存一份彻底同样的数据，这样能够解决与分片表的join直接下推到RDS上执行。

在分布式条件下，原有数据库中的主键约束将没法使用，是否是须要引入外部机制保证数据惟一性标识，那么这种全局惟一序列DDM是如何保证的呢？

DDM 全局惟一序列，使用方法与 MySQL的AUTO_INCREMENT 相似。目前 DDM 能够保证该字段全局惟一和有序递增，但不保证连续性。目前DDM设计了2种类型的序列机制，DB和TIME。DB方式的序列是指经过DB来实现，须要注意步长的设置，步长直接关系到序列的性能，步长的大小决定了一次批量取序列的大小。TIME序列使用了时间戳加机器编号的生成方式，好处是无需通信便可保证惟一性。

DDM在运维监控方面的优点？

DDM: 采用传统中间件运维彻底须要本身运维，通常中间件专一核心功能，较少考虑运维和图形化界面的操做。DDM充分利用云化的优点，提供了对实例、逻辑库、逻辑表、分片算法等的全面图形化界面操做。同时能够在线查看慢SQL等监控内容，方便对系统进行针对性的性能调优。

将来DDM会往什么方向发展？

DDM将来方向对分布式事务、分布式查询能力加强、性能的优化等，考虑到有些特性实现若是只从中间件层面实现会限制比较多。DDM会经过与数据库底层的修改进行配合，一块儿提供更优秀的特性来知足用户的业务需求。