zebra

zebra是一种支持读写分离、分库分表、动态数据源、端到端监控的数据库中间件。
数据的切分（Sharding）根据其切分规则的类型，可以分为两种切分模式。一种是按照不同的表（或者Schema）来切分到不同的数据库（主机）之上，这种切可以称之为数据的垂直（纵向）切分；另外一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面，这种切分称之为数据的水平（横向）切分。

1 分库分表

垂直切分

优点：

拆分后业务清晰，拆分规则明确。

系统之间整合或扩展容易。

数据维护简单。

缺点：

部分业务表无法 join，只能通过接口方式解决，提高了系统复杂度。

受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高。

事务处理复杂。

水平切分

相对于垂直拆分，水平拆分不是将表做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中包含一部分数据。

我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中。

切分方法：

按照用户 ID 求模，将数据分散到不同的数据库，具有相同数据用户的数据都被分散到一个库中。

按照日期，将不同月甚至日的数据分散到不同的库中。

按照某个特定的字段求模，或者根据特定范围段分散到不同的库中。

值得一提的是，分库分表并不会影响业务方的数据查询，其中的细节会在数据库中间件等处进行解析、路由、改写、执行等。

2 读写分离

读写分离，基本的原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操作。

数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。

因为数据库的“写”（写10000条数据到oracle可能要3分钟）操作是比较耗时的。 但是数据库的“读”（从oracle读10000条数据可能只要5秒钟）。

所以读写分离，解决的是，数据库的写入，影响了查询的效率。

3 数据库中间件

可以看到在操作单库单表的情况下，我们是直接在应用中通过数据源(c3p0、druid、dbcp等)与数据库建立连接，进行读写操作。

但是在进行读写分离/分库分表后，底层的数据库实例就会有多个，读写分离情况下一个master多个slave；分库分表的情况下，有多个不同的分库。

从应用的角度来说，除了要与多个不同的数据库建立连接，还需要处理分库分表/读写分离特定场景下的问题：

在读写分离的情况下，应用需要对读sql/写sql进行区分，读sql走从库，写sql走主库，并考虑主从同步延迟、高可用等一系列问题。

在分库分表的情况下，应用需要能对sql进行解析、改写、路由、结果集合并等一些操作，以及分布式事务、分布式id生成器等。

这无疑是个复杂的工作，而数据库中间件的作用，是让开发人员可以像操作单库单表那样去操作数据库，屏蔽底层复杂的实现。

服务端代理(proxy：代理数据库)

我们独立部署一个代理服务，这个代理服务背后管理多个数据库实例。而在应用中，我们通过一个普通的数据源(c3p0、druid、dbcp等)与代理服务器建立连接，所有的sql操作语句都是发送给这个代理，由这个代理去操作底层数据库，得到结果并返回给应用。在这种方案下，分库分表和读写分离的逻辑对开发人员是完全透明的。

客户端代理(datasource：代理数据源)

应用程序需要使用一个特定的数据源，其作用是代理，内部管理了多个普通的数据源(c3p0、druid、dbcp等)，每个普通数据源各自与不同的库建立连接。应用程序产生的sql交给数据源代理进行处理，数据源内部对sql进行必要的操作，如sql改写等，然后交给各个普通的数据源去执行，将得到的结果进行合并，返回给应用。数据源代理通常也实现了JDBC规范定义的API，因此能够直接与orm框架整合。在这种方案下，用户的代码需要修改，使用这个代理的数据源，而不是直接使用c3p0、druid、dbcp这样的连接池。

数据库代理

目前的实现方案有：阿里巴巴开源的cobar，mycat团队在cobar基础上开发的mycat，mysql官方提供的mysql-proxy，奇虎360在mysql-proxy基础开发的atlas。目前除了mycat，其他几个项目基本已经没有维护。

优点：多语言支持。也就是说，不论你用的php、java或是其他语言，都可以支持。原因在于数据库代理本身就实现了mysql的通信协议，你可以就将其看成一个mysql 服务器。mysql官方团队为不同语言提供了不同的客户端却动，如java语言的mysql-connector-java，python语言的mysql-connector-python等等。因此不同语言的开发者都可以使用mysql官方提供的对应的驱动来与这个代理服务器建通信。

缺点：实现复杂。因为代理服务器需要实现mysql服务端的通信协议，因此实现难度较大。

数据源代理

目前的实现方案有：阿里巴巴开源的tddl，大众点评开源的zebra，当当网开源的sharding-jdbc。需要注意的是tddl的开源版本只有读写分离功能，没有分库分表，且开源版本已经不再维护。大众点评的zebra开源版本代码已经很久更新，基本上处于停滞的状态。当当网的sharding-jdbc目前算是做的比较好的，代码时有更新，文档资料比较全。

优点：更加轻量，可以与任何orm框架整合。这种方案不需要实现mysql的通信协议，因为底层管理的普通数据源，可以直接通过mysql-connector-java驱动与mysql服务器进行通信，因此实现相对简单。

缺点：仅支持某一种语言。例如tddl、zebra、sharding-jdbc都是使用java语言开发，因此对于使用其他语言的用户，就无法使用这些中间件。版本升级困难，因为应用使用数据源代理就是引入一个jar包的依赖，在有多个应用都对某个版本的jar包产生依赖时，一旦这个版本有bug，所有的应用都需要升级。而数据库代理升级则相对容易，因为服务是单独部署的，只要升级这个代理服务器，所有连接到这个代理的应用自然也就相当于都升级了。

4 端到端监控

端到端的监控，一端指的是应用服务器，另一端指的是数据库服务器，一次端到端过程，就是一次完整的请求响应过程，中间经历两次来回网络的开销。

端到端监控之所以重要，因为它最能够客观的反映SQL的性能。比起MySQL服务端的监控指标，端到端监控还把来回的两次网络开销算了进去。

会经常出现在端到端监控上看到慢查询，但这条慢查询却不能够在MySQL服务器上查出，这是因为有可能这条SQL在网络上多花了开销，或者在MySQL的队列中多等待了一段时间。

5 数据源

GroupDataSource
顾明思义，是连接一个数据库服务组(数据库集群)。主要功能是读写分离、从库的负载均衡等。底层其实包个若干个SingleDataSource

ShardDataSource
顾明思义，是用来分库分表的连接池。主要功能就是分库分表。底层其实包个若干个GroupDataSource