1.简介

DRDS也是一个NewSQL系统。从前身TDDL进化而来。

2. TDDL

TDDL主要功能是做数据库切分,一个或一组SQL请求提交到TDDL,TDDL进行规则运算后得知SQL应该被分发到哪个机器,然后直接将SQL转发到对应及其即可。具体过程如下图:

TDDL存在SQL兼容性的问题:随着服务的应用增长,原本的方案有较多限制。为了改善这种问题,DRDS也就应运而生了。

3.DRDS

3.1 三层架构(简单看看)

Matrix对应数据库切分场景,对SQL有一定限制,Group对应读写分离和高可用场景,对SQL几乎没有限制。这种设计是为了弥补TDDL的缺点(比如无法再非读写分离场景应用复杂SQL)。至于为什么存在这样的缺点。博主表示没研究过代码,也不清楚。

3.2 分布式SQL执行引擎

底层实现上和传统SQL执行引擎差别还是很大,采用分布式就不得不考虑网络通信的问题。分布式数据库比较情调吞吐调优,涉及跨机的查询,尽量成批发送。

3.3 按需数据库集群平滑扩缩(简单看看就好)

这个是DRDS的一个特性。就是现在云数据库很火的按需扩容或者缩容。没啥好说的,看张图就好。

3.4 小表广播(值得一看)

小表广播也是我们在分布式数据库领域内最常用的工具之一,他的核心目的其实都是一个——尽可能让查询只发生在单机。
让我们用一个例子来说明,小表广播的一般使用场景。


上图中,如果我想知道买家id等于0的用户在商城里面买了哪些商品,我们一般会先将这两个表join起来,然后再用where平台名=”商城” and buyerID = 0找到符合要求的数据。然而这种join的方式,会导致大量的针对左表的网络I/O。如果要取出的数据量比较大,系统延迟会明显上升。

这时候,为了提升性能,我们就必须要减少跨机join的网络代价。我们比较推荐应用做如下处理,将左表复制到右表的每一个库上。这样,join操作就由分布式join一下变回到本地join,系统的性能就有很大的提升了,如下图所示。

3.5 分布式事务套件

在阿里巴巴的业务体系中存在非常多需要事务类的场景,下单减库存,账务,都是事务场景最集中的部分。而我们处理事务的方法却和传统应用处理事务的方案不大一样,我们非常强调事务的最终一致性和异步化。利用这种方式,能够极大地降低分布式系统中锁持有的时间,从而极大地提升系统性能。

参考资料:
http://www.csdn.net/article/2015-07-15/2825221?_t=t