vlambda博客
学习文章列表

分库分表的手段

手动路由

如果没有复杂的操作，手动路由相对来说是简单的方式。比如你的操作只根据分片键操作，那么通过分片键你可以计算出这条数据的库和表，从而将你的SQL路由到指定的库进行执行。

这里主要是要在执行SQL的时候，动态获取对应的数据源，获取到数据源之后就用这个数据源进行SQL的执行。至于SQL在哪张表即SQL拼接的时候就已经知道了。

这也是最简单的实现分库分表的方式，但是实际业务中，我们不可能只根据分片键进行查询，假设有非分片键的查询，就还涉及到数据聚合，分页的问题，如果每个业务都要自己处理，这复杂度就太高了，所以我们需要一款中间件来支撑分库分表的需求。

中间件

分库分表中间件的出现，降低了分库分表的门槛，也极大的提升了开发效率。中间件内部会回SQL进行校验，解析，路由，聚合等逻辑。同时也会考虑到可用性，易用性等方面。

目前中间件主要分为两种类型，一种是Client方式的中间件，比如Sharding-JDBC，Ctrip DAL，TSharding等优秀的中间件。

一种是Proxy方式的中间件，比如ShardingSphere，Mycat等优秀的中间件。

Client和Proxy方式对比

Client方式是指分库分表的逻辑都在应用本地进行控制，应用本地会直连多个数据库进行操作，然后本地进行数据的聚合汇总等操作逻辑。

Proxy方式是指挥有一个独立的应用，这个应用实现了MySQL的协议，可以对外提供服务。业务方的应用不需要直接连接数据库，而是连接这个Proxy的应用，把这个Proxy就当做一个数据库使用。Proxy会将SQL分发到具体的数据库进行执行，并返回结果。

性能方面比较

从性能这块去比较多的话，Client方式性能更好。Client方式采用的是应用直连数据库的形式，一条SQL直达数据库，拿到结果直接就可以用了，基本上跟我们没分库分表之前差不了多少。

Proxy方式在性能方法会有一点损耗，因为中间多了一次路由操作。就是SQL由应用到Proxy，Proxy再将SQL路由到具体的数据库，拿到结果，再响应给应用。

内存方面比较

从内存占用这块去比较的话，Client方式不是很好。Client方式拿到数据库响应的内容后要在应用本地进行聚合操作，内存，cpu等都是占用当前应用的资源。

Proxy方式也是会占用内存，但是它的内存不是当前应用的内存，而是Proxy这个应用的内存，Proxy应用是单独部署的，所以是隔离的状态。同时Proxy是会集群部署的，所以会更好点。

连接数方面比较

Client方式在连接数方面会占用的比较多，每个应用都会直接连接每个库，每个库也就是一个连接池。

Proxy方式连接数会相对较少一点，每个库只需要一个连接池即可。应用连接Proxy占用的就不是数据库的连接了。当然如果Proxy集群的节点多的话，连接数也是会相应的增多。

架构复杂度比较

Client方式在架构方面比较简单，通常是依赖一个Jar包，不会出现单点故障问题。

Proxy方式需要单独部署一个独立的服务，并且这个服务也要考虑高可用，整体的架构复杂度还是比较高的，所以小团队建议大家用Client方式。

从升级方面比较

Client方式每个项目都要依赖Jar包，一但版本有什么问题，出了新的修复版本，所有项目都得跟着升级。小公司还好，就那么几个项目，大公司的项目成百上千，而且都是属于不同团队下的，这种中间件是属于基础架构团队的，要推动业务团队升级其实很困难的，没个半年基本上很难全部都升级完。

Proxy方式在这方面的优势就提现出来了，有什么新功能或者修复了什么Bug，只需要Proxy集群重新发布一遍即可，使用方完全不需要关心，也就不存在推动升级的问题了。但是需要做好一点：发布过程中必须无损。这边应用时刻都在执行SQL，你发布不能导致应用执行SQL报错。

统一管控方面比较

Client方式要做统一管控，必须得进行升级，但是升级又是一个很耗时的推动过程。

Proxy方式在统一管控方式就容易的多，比如对SQL的限流，监控，告警等管控，是不需要客户端关心的。除了这些管控，还有一些其他的管控，比如异地多活场景下的禁写，禁读操作，都是管控的点。如果用Client方式确实不太好统一处理。

总结

今天主要给大家介绍了如何进行分库分表中间件的选型，不同的阶段其实适合不同的中间件。规模不大时建议用Client方式的中间件，使用简单，也没什么维护成本。规模大了后建议用Proxy方式的中间件，更方便统一管控和维护。