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

阿飞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源码，根据