MySQL优化之--水平拆分的成熟解决方案

逃离我推掉我的手 2024-03-23 12:12 3阅读 0赞

前面简单介绍了MySQL的几种架构优化方向，随着数据库的日益增大， 水平拆分不可避免了。

本次介绍下大数据量下的水平拆分成熟的解决方案。

9de7bb31d0644e7393039222babfed10

由于水平拆分牵涉的逻辑比较复杂,当前也有了不少比较成熟的解决方案. 这些方案分为两大类:

*  客户端架构
 *  代理架构

### 客户端架构 ###

通过修改数据访问层,如 JDBC, Data Source, MyBatis,通过配置来管理多个数据源,直连数据库,并在模块内完成数据的分片整合,一般以 Jar 包的方式呈现

**客户端架构的优点是:**

应用直连数据库,降低外围系统依赖所带来的宕机风险

集成成本低,无需额外运维的组件

**客户端架构的缺点是:**

限于只能在数据库访问层上做文章,扩展性一般,对于比较复杂的系统可能会力不从心

将分片逻辑的压力放在应用服务器上,造成额外风险

### 代理架构 ###

通过独立的中间件来统一管理所有数据源和数据分片整合,后端数据库集群对前端应用程序透明,需要独立部署和运维代理组件

代理组件为了分流和防止单点,一般以集群形式存在,同时可能需要 Zookeeper 之类的服务组件来管理

**代理架构的优点是:**

能够处理非常复杂的需求,不受数据库访问层原来实现的限制,扩展性强

对于应用服务器透明且没有增加任何额外负载

**代理架构的缺点是:**

需部署和运维独立的代理中间件,成本高

应用需经过代理来连接数据库,网络上多了一跳,性能有损失且有额外风险

### 方案比较 ###

<table> 
 <thead> 
  <tr> 
   <th>框架</th> 
   <th>出品方</th> 
   <th>架构模型</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>MySQL Fabric</td> 
   <td>MySQL官方</td> 
   <td>代理架构</td> 
  </tr> 
  <tr> 
   <td>Cobar</td> 
   <td>阿里巴巴</td> 
   <td>代理架构</td> 
  </tr> 
  <tr> 
   <td>Cobar Client</td> 
   <td>阿里巴巴</td> 
   <td>客户端架构</td> 
  </tr> 
  <tr> 
   <td>TDDL</td> 
   <td>淘宝</td> 
   <td>客户端架构</td> 
  </tr> 
  <tr> 
   <td>Atlas</td> 
   <td>奇虎360</td> 
   <td>代理架构</td> 
  </tr> 
  <tr> 
   <td>Heisenberg</td> 
   <td>百度熊照</td> 
   <td>代理架构</td> 
  </tr> 
  <tr> 
   <td>Tribedb</td> 
   <td>个人</td> 
   <td>代理架构</td> 
  </tr> 
  <tr> 
   <td>Sharding JDBC</td> 
   <td>当当</td> 
   <td>客户端架构</td> 
  </tr> 
  <tr> 
   <td>Shark</td> 
   <td>个人</td> 
   <td>客户端架构</td> 
  </tr> 
  <tr> 
   <td>KingShard</td> 
   <td>个人</td> 
   <td>代理架构</td> 
  </tr> 
  <tr> 
   <td>Oneproxy</td> 
   <td>平民软件</td> 
   <td>代理架构</td> 
  </tr> 
  <tr> 
   <td>Mycat</td> 
   <td>社区</td> 
   <td>代理架构</td> 
  </tr> 
  <tr> 
   <td>vitess</td> 
   <td>Youtube</td> 
   <td>代理架构</td> 
  </tr> 
  <tr> 
   <td>Mixer</td> 
   <td>个人</td> 
   <td>代理架构</td> 
  </tr> 
  <tr> 
   <td>Jetpants</td> 
   <td>Tumblr</td> 
   <td>客户端架构</td> 
  </tr> 
  <tr> 
   <td>hibernateShard</td> 
   <td>Hibernate</td> 
   <td>客户端架构</td> 
  </tr> 
  <tr> 
   <td>MybatisShard</td> 
   <td>MakerSoft</td> 
   <td>客户端架构</td> 
  </tr> 
  <tr> 
   <td>Gizzard</td> 
   <td>Twitter</td> 
   <td>代理架构</td> 
  </tr> 
 </tbody> 
</table>

### 方案总结 ###

如此多的方案,如何进行选择？可以按以下思路来考虑:

确定是使用代理架构还是客户端架构. 中小型规模或是比较简单的场景倾向于选择客户端架构,复杂场景或大规模系统倾向选择代理架构

具体功能是否满足,比如需要跨节点 ORDER BY,那么支持该功能的优先考虑

不考虑一年内没有更新的产品,说明开发停滞,甚至无人维护和技术支持

最好按大公司 -> 社区 -> 小公司 -> 个人这样的出品方顺序来选择

选择口碑较好的,比如 GitHub 星数, 使用者数量质量和使用者反馈

开源的优先,往往项目有特殊需求可能需要改动源代码

按照上述思路,推荐以下选择:

客户端架构: ShardingJDBC

代理架构: MyCat 或 Atlas