0. sharding-jdbc源码之分析准备工作

本文探讨了阅读sharding-jdbc源码的原因,它作为一款轻量级分库分表中间件,因其代码简洁及独特优化备受青睐。作者介绍了准备工作的几个关键步骤,包括对源码模块的分析,依赖的技术栈如lombok和guava,以及如何进行架构理解和调试。通过源码分析,将聚焦分片规则、SQL解析、路由、改写、执行和结果合并等核心功能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

阿飞Javaer,转载请注明原创出处,谢谢!

为什么阅读sharding-jdbc源码

回答这个问题之前,先回答为什么要阅读某个分库分表中间件的源码,互联网行业海量的数据,导致单库单表远不能承受业务需求,很多互联网产品的单日订单量就已经突破了1000w。海量数据既然单表无法承受,那么就必须要分库分表;目前主流数据库主要基于Proxy和client两种架构:proxy以阿里的corba为代表,client以当当的sharding-jdbc为代表(或者阿里内部的TDDL)。但是不管哪种架构,其最核心的数据处理,都是一样的,即:解析,重写,路由,执行,结果归并;

而之所以选择sharding-jdbc,是因为他的代码足够精炼;其核心源码只有不到3w行(不包括测试用例和配置文件)。而且sharding-jdbc在很多地方有非常独到的优化处理。另外一个私人原因,sharding-jdbc的作者张亮大神比较接地气,有什么疑问可以直接@他请教,哈,另外笔者也认识两个sharding-jdbc的committer同学^^;

可能部分同学会想到分区,然而分区在互联网行业使用的比较少,尤其是核心业务,例如订单表,用户表;因为分区表的能力上限还是单库单表,严重受到连接,IO,网络等制约而无法扩展;而分库分表则不一样;可以将数据保存到N个数据库的N张表中;即使部分数据库宕机且短时间无法修复,也只是影响一部分用户的体验,这是最坏的情况;分区表也不是一无是处,如果QPS要求不高,例如日志表,就很适合用分区表来处理;

sharding-jdbc源码分析准备工作

接下来对sharding-jdbc源码的分析基于tag为1.5.4.1源码,根据

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值