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方式的中间件,更方便统一管控和维护。