Cobar 初体验——系统概要设计

     最近在学习分布式数据库的中间件，大概收集了解了大厂的做法，比如阿里的Cobar和TDDL，这里先讨论Cobar。Cobar是阿里巴巴B2B的产物，其github地址为： https://github.com/alibaba/cobar （相关文档皆在github），本篇是了解了其基本设计后的总结，难免有错误及遗漏之处。

    通常，如果一个互联网产品有幸从小到大，那么它的数据库演变历程一般如下：

    单实例单库，基本上没有数据压力，全部表放置在一个数据库中，如果考虑到HA（high availability），可以加入主从复制。

    如果产品有幸存活，用户量越来越大，发现系统之前的某些单表数据量过大，需要对单表进行水平扩容，便有了分表，分表策略一般是针对某一字段进行哈希取模，比如分1024个表，一般就%1024。不过，一般所有的分表还是放在同一个库中。也可以使用多个库，不同库负责储存不同数据，不过这多个库还是在同个数据库实例中。

    再后来，产品发展越来越好，用户量达到百万/千万级别，系统访问压力巨大，数据量也巨大，考虑到跨IDC访问，数据存放在一个数据库实例显然承受不住压力，需要扩容系统的数据承受能力。

    Cobar就是这样场景下的产物，在阿里传统的小型机+Oracle存储承受不住系统巨大压力时，他们有三种解决方案：

    （1）升级小型机硬件

    （2）多台小型机分散业务

    （3）普通PC + 开源软件 + 分布式解决方案

    最后他们选择了第三种，事实证明这也是互联网企业都选择的路线，也是正确的路线。Cobar的最初的设计目标有如下：

    （1）集中式改为分布式

    （2）failover，容灾是必须的

    （3）解决连接数过大问题

    （4）对业务代码入侵尽量少

    在系统早期设计阶段，设立系统目标是很有必要的，有了目标才可以探索通过什么方式去实现最终目标。

Cobar的实现方案：

    （1）路由算法：

    

    路由算法采用了一致性哈希算法，我们知道一致性哈希算法尽可能解决了分布式缓存系统由于增、删节点引起的部分失效问题，之所以说是尽可能解决，是因为一致性哈希并没有完全解决缓存失效问题。在根据拆分字段进行一致性哈希后，再根据哈希结果决定存储的目的数据库实例。所以在扩容时，还是会存在数据的迁移，比如从四个数据库实例扩容到八个数据库实例，与缓存不同，数据库不允许数据失效，所以这时就会存在部分数据的迁移。不过对比其他算法，一致性哈希算法在这里还是有优势的，使得扩容数据移动较少且在局部移动。

    路由算法实现了上述第一点集中式改为分布式的目标。

（2）数据源层次

    在使用多个数据库实例后，数据有两种：sharding和replica，sharding和replica在分布式系统是很常见的，sharding是一分为几的概念，当数据无法在一个实例或者机器上存储时，我们必须对其分片。replica是副本的概念，就是备份，为了数据的高可用，避免单点问题，我们需要对其进行备份，也就是replica。

    

    上图的M就是Master，S是Slave，之间的同步，Cobar并没有使用Mysql的同步，这里需要说一下背景，Mysql5.5以前使用的是异步复制，在Mysql5.5后新增了半同步复制，Cobar早期考虑到异步复制的数据一致性延迟问题，并没有采用Mysql自身的复制工具（最新的Cobar是否有使用Mysql自身的复制工具，这个有待阅读源码）。所以笔者在看到Github上的相关文档时，replica与Master之间的复制是Cobar根据Mysql本身的replication协议完成。

    Cobar与每一个分片DateNode维持心跳，一旦发现Master不可用，将会自动切换到另一个replica。

    心跳策略和冗余备份策略实现了上述第二点failover的目标。

（3）解决连接数过大问题

    假设没有Cobar这个中间件，应用层与数据层直接的关系是如下图：

    

    Cobar的引入，新增了连接复用，如下图：

    Cobar Proxy引入了连接复用，解决了上述第三点连接数过多的问题。

    

    至于对业务代码入侵较少，Cobar采用Mysql协议，与原生Mysql交互的方式基本一样。这一篇属于系统设计概要范畴，下一篇学习一下Cobar的系统实现，是如何让需要在多个实例执行的Sql，让用户感觉就操作一个实例一样。