Cobar是阿里巴巴（B2B）部门开发的一种关系型数据的分布式处理系统，它可以在分布式的环境下看上去像传统数据库一样为您提供海量数据服务。那么具体说说我们为什么要用它，或说cobar--能干什么？以下是我们业务运行中会存在的一些问题：
1.随着业务的进行数据库的数据量和访问量的剧增，需要对数据进行水平拆分来降低单库的压力，而且需要高效且相对透明的来屏蔽掉水平拆分的细节。
2.为提高访问的可用性，数据源需要备份。
3.数据源可用性的检测和failover。
4.前台的高并发造成后台数据库连接数过多，降低了性能，怎么解决。
针对以上问题就有了cobar施展自己的空间了，cobarhttp://code.alibabatech.com/wiki/display/cobar/Home
TDDL
淘宝根据自己的业务特点开发了TDDL（Taobao Distributed Data Layer 外号:头都大了 ©_Ob）框架，主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制，它是一个基于集中式配置的 jdbc datasource实现，具有主备，读写分离，动态数据库配置等功能。
TDDL所处的位置（tddl通用数据访问层，部署在客户端的jar包，用于将用户的SQL路由到指定的
淘宝很早就对数据进行过分库的处理， 上层系统连接多个数据库，中间有一个叫做DBRoute的路由来对数据进行统一访问。DBRoute对数据进行多库的操作、数据的整合，让上层系统像操作一个数据库一样操作多个库。但是随着数据量的增长，对于库表的分法有了更高的要求，例如，你的商品数据到了百亿级别的时候，任何一个库都无法存放了，于是分成2个、4个、8个、16个、32个……直到1024个、2048个。好，分成这么多，数据能够存放了，那怎么查询它？这时候，数据查询的mysql和oracle数据库
7.基于jdbc规范，很容易扩展支持实现jdbc规范的数据源
8.无server,client-jar形式存在，应用直连数据库
9.读写次数,并发度流程控制，动态变更
10.可分析的日志打印,日志流控，动态变更
TDDL必须要依赖diamond配置中心（diamond是淘宝内部使用的一个管理持久配置的系统，目前淘宝内部绝大多数系统的配置，由diamond来进行统一管理，同时diamond也已开源）。
TDDL 其实主要可以划分为 3 层架构，分别是 Matrix 层、 Group 层和 Atom 层。 Matrix 层用于实现分库分表逻辑，底层持有多个 Group 实例。而 Group 层和 Atom 共同组成了 动态数据源 ， Group层实现了数据库的 Master/Salve 模式的写分离逻辑，底层持有多个 Atom 实例。最后Atom 层 (TAtomDataSource) 实现数据库 ip,port,password,connectionProperties 等信息的动态推送 , 以及持有原子的数据源分离的 JBOSS 数据源）。
章节的最后，我们还需要对 TDDL 的原理进行一次剖析。因为我们知道持久层只关心对数据源的 CRUD 操作，而多数据源的访问，并不应该由它来关心。也就是说TDDL 透明给持久层的数据源接口应该是统一且 “ 单一 ” 的，至于数据库 到底如何分库分表，持久层无需知道，也无需 编写对应的 SQL 去实行 应对策略 。这个时候对 TDDL 一些疑问就出现了， TDDL 需要对 SQL 进行二次解析和拼装吗？答案是 不解析仅拼装 。说白了 TDDL 只需要从持久层拿到发出的 SQL
再按照一些分库分表条件，进行特定的 SQL 扩充以此满足访问路路由操作。
数据库实现性能的提高。具体使用哪种还要经过深入的研究，严谨的测试才可决定。