13518219792
根据您的个性需求进行定制 先人一步 抢占小程序红利时代
前篇：《数据库中间件cobar调研笔记》
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：申请域名、虚拟主机、营销软件、网站建设、大竹网站维护、网站推广。
13年底负责数据库中间件设计时的调研笔记，拿出来和大家分享，轻拍。
一、TDDL是什么
画外音：数据库中间件有基于服务端的，也有基于客户端的，TDDL属于后者;而cobar是一个中间层服务，使用mysql协议，属于前者。
二、TDDL不支持什么SQL
画外音：分布式数据库中间件，join都是很难支持的，cobar号称的对join的支持即有限，又低效。
三、TDDL支持什么SQL
画外音：分布式数据库中间件，支持的语法都很有限，但对于与联网的大数据/高并发应用，足够了，服务层应该做更多的事情。
四、TDDL其他特性
画外音：可以看到，其实TDDL很多东西都不支持，那么为什么它还如此流行呢?它解决的根本痛点是“分布式”“分库分表”等。
加入了解决“分布式”“分库分表”的中间件后，SQL功能必然受限，但是，我们应该考虑到：MYSQL的CPU和MEM都是非常珍贵的，我们应该将MYSQL从复杂的计算(事务，JOIN，自查询，存储过程，视图，用户自定义函数，，，)中释放解脱出来，将这些计算迁移到服务层。
当然，有些后台系统或者支撑系统，数据量小或者请求量小，没有“分布式”的需求，为了简化业务逻辑，写了一些复杂的SQL语句，利用了MYSQL的功能，这类系统并不是分布式数据库中间件的潜在用户，也不可能强行让这些系统放弃便利，使用中间件。
五、TDDL层次结构
TDDL是一个客户端jar，它的结构分为三层：
对应上面图例：matrix数据水平分为了两个group，每个group有主备atom组成。
matrix层
group层
atom层
整个SQL执行过程
画外音：感觉难点在SQL的解析上。
六、TDDL***实践
画外音：这里我展开一下这个使用场景。
以电商的买家卖家为例，业务方既有基于买家的查询需求，又有基于卖家的查询需求，但通常只能以一个纬度进行数据的分库(patition)，假设以买家分库， 那卖家的查询需求如何实现呢?
如上图所示：查询买家所有买到的订单及商品可以直接定位到某一个分库，但要查询卖家所有卖出的商品，业务方就必须遍历所有的买家库，然后对结果集进行合并，才能满足需求。
所谓的“数据增量复制”“表结构冗余”“减少网络次数”，是指所有的数据以买家卖家两个纬度冗余存储两份，如下图：
采用一个异步的消息队列机制，将数据以另一个纬度增量复制一份，在查询的时候，可以直接以卖家直接定位到相应的分库。
这种方式有潜在的数据不一致问题。
继续tddl***实践：
(1) 利用单机资源：单机事务，单机join
(2) 存储模型尽量做到以下几点：
画外音：相比数据库中间件内核，***实践与存储模型，对我们有更大的借鉴意义。
七、TDDL的未来?
画外音：潜台词是，在大数据量高并发下，SQL不是大势所趋，no-sql和定制化的协议+存储才是未来方向?
13年底的调研笔记，文中的“画外音”是我当时的批注，希望能让大家对TDDL能有一个初步的认识，有疑问之处，欢迎交流。
【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】
戳这里，看该作者更多好文
