分库分表——Sharding-Sphere

目前分库分表除了应用层基于业务逻辑的方式，在技术层面主要两种方式：一种是中间件代理，例如mycat和sharding-proxy，对于应用是比较透明的，支持的语言也多；第二种是侵入式，也就是数据库直连，例如sharding-jdbc。sharding-proxy和sharding-jdbc已经整合到sharding-Sphere里，官方文档：http://shardingsphere.apache.org/index_zh.html

Sharding-Sphere的不足之处：

（1）shrdingkey粘连，例如sharding-jdbc里面需要指出分库键和分表键，如果业务很复杂，意味着要建立很多shrdingkey；增删改查都必须带上这个shrdingkey才能路由到具体的数据表。

（2）要根据业务设计具体的数据均衡算法，如果要实现数据冷热均衡、高可用复杂，那算法的复杂度就会更高。一般分表分库数据，热点数据就需要设计非常复杂的算法，提前规划好几张库几张表；例如购物记录表，设计2个库，每个库水平切4张表，再为这些表设计一套均衡的数据分流，但是人员表你最多一个库两张表，再为这种业务维度设计一套数据均衡。最后，你要为这些来个主从、读写分离保证高可用。

（3）扩容非常困难，扩容要考虑数据均衡算法。

（4）sql不支持关联查询、分布式事务复杂度高、一致性差。不过这些都是关系型数据库在分布式场景下的通病。

案例：美团《大众点评订单系统分库分表》