数据库中间件Cobar功能探究
一、 Cobar项目介绍
一）、Cobar背景概述
Cobar是提供分布式数据库服务的中间件，由阿里巴巴中间件团队开发，是阿里巴巴B2B前台应用访问数据库的统一入口，目前已在github上开源。
Cobar的分布式方案是分库和分表，可以按照业务需求将数据库中耦合度较低的表分到不同的分库中，也可以按照具体表的增长速度和数据量水平切分到不同的分库中，Cobar可以实现应用层与物理分库的双向透明，从而实现应用程序访问分布式数据库与访问单库无差别。 Cobar还可以配合MySQL的心跳和binlog实现备机的自动切换，保证数据节点的可靠性，从而实现高可用性。
但Cobar目前的版本是2013年发布的版本1.2.7，由于作者目前的工作重心不在Cobar，所以虽然会继续更新，进度不会很快。
二）、Cobar架构
其中前端是NIO实现的，通过MySQL协议与应用程序交互，后端也是通过MySQL协议与物理数据库交互。
三）、Cobar的约束
官方文档对Cobar的适用场景和限制都有明确的说明。
- 使用jdbc时，使用mysql-jdbc-5.1以上版本，推荐5.1.6或者5.1.12版本。
- 不支持rewriteBatchedStatements=true参数设置。默认为false
- 不支持useServerPrepStmts=true参数设置。默认为false
- 不支持跨库(数据节点)的关联操作：join、分页、排序、子查询。
- BLOB, BINARY, VARBINARY字段不能使用。若特殊需求需要这三种字段，禁止使用PreparedStatement的setBlob()或setBinaryStream()方法设置参数。
- 不支持SAVEPOINT操作。
- 不支持SET语句的执行，事务和字符集设置语句除外。
- 对于拆分表（分库表），不能更新已有记录的拆分字段（分库字段）值。
- 只支持MySQL数据节点。
- 对于拆分表，插入操作须给出列名，必须包含拆分字段。
二、应用背景
随着业界的逐步去IOE化，分布式MySQL集群成为了一个实现高可用、高性能、可扩展的数据库解决方案。
目前业内有很多MySQL集群方案供不同的使用场景选择，比如：
1．双主复制模式，不做数据拆分，可以综合运用keepalived和MySQL实现。
2．如果需要做数据库拆分，要求分布式事务，就可以考虑Cobar。
3．如果需要数据库拆分，不需要分布式事务，需要读写分离，则可以使用同样是阿里开源的中间件项目。
此外还有一些选择，比如MySQL Proxy，使用lua编写，但是官方维护已经终止；MySQL Cluster， 商用版也是收费的，社区版免费但是性能存疑；还有搜狐新近开源的C语言编写的MySQL分布式中间件DBProxy。
三、Cobar详细分析
为了对Cobar的功能以及约束有一定的认识，搭建了简单的Cobar测试环境进行实验。实验中共使用了3种数据库方案：
1．MySQL单库方案
2．6节点Cobar方案
3．16节点Cobar方案
一）、环境搭建
Cobar的release版本中包含配置文件、jar包以及日志文件。
搭建Cobar环境需要根据情况配置rule.xml、schema.xml、server.xml。其中schema.xml定义了分库分表的规则以及数据节点和数据源的信息。rule.xml定义了水平分表的路由规则，但是目前的路由算法是Cobar源码中硬编码定的，能够配置的只是节点数等参数，如果需要根据业务需求定义路由算法，需要修改Cobar的源码。server.xml定义Cobar服务的信息，包括其作为一个数据源时的用户名密码等，还定义了包含的schema。
bin目录下的文件是用来启动关闭cobar-server的，其中windows下用到的就是startup.bat，该批处理文件需要修改版本号以顺利运行：
启动Cobar后可以查看stdout.log，如果没有报异常则启动正常：
Cobar服务监听8066端口，在MySQL命令行和JDBC连接中，8066作为默认端口。
二）、基本功能测试
本环节测试了基本的MySQL功能，查询，插入等。
数据表分配如下：
在schema.xml中定义了该schema的默认datanode，定义了tb2分布在dbtest2、dbtest3中。默认datanode的作用是存放未指定的表，比如创建tb1，就会默认放在dbtest1中。
在rule.xml中为tb2定义了路由用的partitionCount和partitionLength，会按照特定字段进行分库操作。
1.insert
insert命令能够按照约定的路由规则插入特定的分库中。
为了简单测试cobar的插入效率，对tb2插入了10W条数据，结果显示要比单机MySQL插入10W条数据稍慢，随后测试16节点cobar插入10W条数据，速度已经和单机插入接近，如果多线程并发执行的话，cobar会有比较大的优势。
2.select
对上一步插入的数据进行select操作，每个分库结果会merge在一起但是merge的顺序是不确定的。
同样对cobar中的10W条数据进行查询，结果显示依旧是比单机慢：
Cobar：
单机MySQL：
三）、特定功能测试
正常业务中的SQL语句不会仅仅只是insert、select，会用到聚合函数、内外连接、子查询等。官方文档里已经明确说明不支持跨库条件下的这些操作，具体测试如下。
1、order by
对数据id排序查询，单库中order by可以正常显示，对cobar进行相同的操作，可以返回结果，每个分库的结果集按照各自的order排序，最后merge的时候并不是全部排序，而是随机联接在一起。
2、sum count
sum常用来合计某些字段，count用来计数，都是比较常用的sql关键字。Cobar能够返回sum/count的结果，但依旧是每个分库各自统计。
用子查询也不能合并分库的sum，这两个sql查出来的结果是相同的。
3、join
join也是极其常用的sql关键字，但是在cobar中如果切分规则不同的两张表进行join，则构成了跨库。Cobar会报错，提示不存在共同分库中的相应表。而如果两张表采用相同的切分字段，相同的路由规则，那么两者是能够join的。
在测试环境中，tb1不是和tb4相同切分，如果和tb4 join，就会提示不存在dbtest3.tb1。
而如果和tb4切分相同的tb3和它join就可以实现。
4、exists
exists也可以用，但是也是要考虑在不在一个库中
tb3和tb4是按照相同的分片规则分布在数据库中的
5、子查询
子查询在跨库情况下也是不能实现的，但是如果能够限制过程中使用的都封闭在同一个分库中，那么子查询是可以成立的。
6、存储过程
在尝试插入10W条数据的时候，单机用到了存储过程，总共用时50余秒，同样语句用到cobar的时候，会显示语法错误，官方提示没有测试过存储过程，不推荐使用。
四、应用Cobar的问题及解决方案
现实中有的业务是比较复杂的，功能实现中使用到的SQL语句也可能是很复杂的，可能遇到的问题如下：
一）、参数表
实际业务中会有一些读操作很多而对写要求不多的参数表，会频繁地和其他表进行join，但是cobar不支持跨库join，那么可行的方案就是在每个分库中保留一份参数表，以便每个分库都可以合法操作。
但这会带来两个问题：
1.参数表之间需要union操作，但是每个分库中有一份相同表的结果就是union操作不能够除去重复项。
可以在分表的schema外有一个单库的schema，所有对参数表的增删改操作都限制在该库中，其所产生的变化都同步到每个分库中。
2.不同分库的参数表需要同步，那么如何保持参数表的数据一致性也是必须要考虑的问题。
二）、跨库操作问题
1、分库分表问题
Cobar不支持跨库操作，但是很多操作已经证明只要是封闭在各自分库中就是可以实现的，比如子查询、join等。
那么关键的问题就是如何分库分表，需要按照业务的耦合关系将数据库拆分重组，将不能跨库的操作尽量限制在一个库中。
而且cobar当前的路由算法不一定能够满足复杂业务下的特异性分表方案，所以在有需求的情况下，还需要自定义cobar的路由算法，自定义路由算法需要extends PartitionFunction implements RuleAlgorithm。
2、sum/count
但是即使分库分表方案设计完善，还是不能解决sum/count等功能的不完善，需要把每个分库的结果再累加才是需要的结果。
解决这个问题有几个方案：
1.在应用程序中处理，实现比较简单，但是增加了模块间的耦合度，破坏了数据层与应用层的透明。
2.修改cobar源码，识别sql语句，在收到返回信息的时候进行处理。实现难度比较大，但是保持了模块间的低耦合。
三）、压力问题
本次测试用的是虚拟机，单台虚拟机安装了8个MySQL实例，共实现了16个datanode，虚拟了10W条数据的简单操作，但和生产环境下的硬件条件以及压力情况是有很大区别的，只有在接近生产环境下真正进行了压力测试，才能得出cobar性能好坏的结论。
四）、事务问题
分布式数据库要实现事务是比较困难的，很多对数据一致性要求不是很严格的场景都放弃了强一致性，而力求达到最终一致性。Cobar对于单库的事务是完全支持的，但是对于分布式事务不保证强一致性，分布式事务采用两阶段执行，即分为执行阶段和提交阶段。
执行阶段：把前端连接上当前事务所使用到的后端连接绑定下来，并执行SQL语句。
- 提交阶段：将commit命令分发到这些绑定的后端连接中。
- 在整个事务过程中，执行阶段出错，可以回滚。提交阶段出错不可以回滚。可以说只要是commit之前，执行出现不一致，cobar会自动回滚。
cobar的分布式事务具体做到什么程度，在实际应用前还是需要测试的。
五）、主从备份问题
Cobar支持基于MySQL的心跳（heartbeat）来实现主备机切换，当检测到主机心跳异常，会自动或手动切换到备机，但是故障排除后切换回主机需要手动，除非备机心跳也异常。
主从复制的过程中一致性的保证也是需要注意的问题。
六）、数据迁移问题
当MySQL集群需要扩容时，就可能需要数据迁移，Cobar本身没有对数据迁移有很大的支持，也不支持mysqldump备份，需要备份时，必须在每个物理分库进行dump。数据迁移需要应用程序的DAO和Cobar还有后台迁移程序共同配合完成。
五、总结
通过对cobar的一系列探究，对其有了一定的认识，但是对于这个拥有800个源文件的顶尖数据库开源项目来说，还远远不够。单就应用来说，binlog同步的问题，事务一致性测试的问题，压力测试的问题，路由算法的问题，数据迁移的问题都是需要深入探讨研究的。
Cobar在阿里3年的稳定运行，能够说明它是个成熟的项目，但是同时要意识到，它是契合阿里特定的业务的项目，任何的迁移都是需要论证的；而且在阿里的数据库中间件中，cobar只是上下游中的一环，有可靠的VIP设备，有跨机房同步的数据同步中间件，有先进的分布式消息系统，才能使cobar扬长避短。
所以，cobar在实际项目中应用是可行的，但是应用过程中的问题是需要深入思考的。
