分库分表（三）-- Sharding-Jdbc基本原理
Sharding-Jdbc定位为轻量级Java框架，以jar包形式提供服务，完全兼容各种ORM框架，如mybatis整合sharding-jdbc后datasource实例为ShardingJdbcDatasource，从datasource中获取的connection实例为ShardingJdbcConnection
ShardingJdbcConnection实例中会维护真正的数据库连接，当commit（同理rollback、close）时会遍历底层所有真正的数据库连接，一个个进行commit操作，如果任何一个出现了异常，直接捕获异常，但是也只是捕获而已，然后接着下一个连接的commit，这也就很好的说明了，如果在执行任何一条sql语句出现了异常，整个操作是可以原子性回滚的，因为此时所有连接都不会执行commit，但如果已经到了commit这一步的话，如果有连接commit失败了，是不会影响到其他连接的
publicclass ShardingJdbcConnection {
//这里存放的是真正的连接
private List<Connection> connectionList;
public void commit() throws SQLException {
Collection<SQLException> exceptions = new LinkedList<>();
for (Connection each : connectionList) {
try {
each.commit();
} catch (final SQLException ex) {
exceptions.add(ex);
}
}
throwSQLExceptionIfNecessary(exceptions);
}
}
Sharding-Jdbc之弱事务
弱事务也叫本地事务，因为存在数据不一致的情况，所以叫弱事务
1）完全支持非跨库事务，例如：仅分表，或分库但是路由的结果在单库（connectionList中只有一个连接）。
2）完全支持因逻辑异常导致的跨库事务（connectionList有多个连接），例如在spring管理的事务中service方法里跨两个库更新，更新完毕后，service方法中抛出空指针，则两个库的内容都能回滚。
3）不支持因网络、硬件异常导致的跨库事务（connectionList有多个连接）。
例如在spring管理的事务中service方法里跨两个库更新，更新完毕后，service正常出栈，事务拦截器执行commit时，第一个库宕机，则只有第二个库数据提交，这种情况就会出现数据的不一致性问题
Sharding-Jdbc之强事务
强事务是相对弱事务而言的，也就是不会出现数据不一致的情况，强事务就是两阶段提交协议(2pc)，Sharding-jdbc强事务需使用@ShardingTransactionType(TransactionType.XA)注解
分库分表配置(这里只是个例子供参考)
读写分离配置(这里只是个例子供参考)