Sharding
随着业务发展、用户量的增长，技术团队都会遇到数据量大、查询缓慢、大数据量的存储问题。一般来说，Mysql单库超过5000万条记录，Oracle单库超过1亿条记录，DB压力就很大，当然容量大小和具体业务、字段数量、访问模式、数据内容等都有进一步关系。如果仅仅是查询缓慢，可以先从sql优化、缓存、读写分离等手段解决。当数据量增长超过单库限制时，很容易出现性能问题，会自然而想到分库分表存储数据，即sharding。
sharding分类
sharding指的是数据分片存储，和数据库的主备、读写分离不是一个问题。主备是为了提高系统的高可用性；读写分离是应对某些情况下，读性能的优化和要求。sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库上，从而缓解单一数据库的性能问题。sharding可以大概分成两类，垂直切分和水平切分。
-
垂直切分。对于海量数据的数据库，如果是因为表多而数据多，而每张表的数据量相差不大，这时候适合使用垂直切分，即把关系紧密（比如同一模块）的一些表切分出来放在一个库，从而将原来的单库切分成多个库。 -
水平切分。对于表不多、但每张表的数据非常多的情形，适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个库上。 -
通常情况下，需要同时考虑水平切分和垂直切分，甚至也可以单库内部做表拆分，实际的切分原则都需要考虑自己的实际情况。当同时进行垂直和水平切分时，切分策略会发生一些微妙的变化。比如：在只考虑垂直切分的时候，被划分到一起的表之间可以保持任意的关联关系，因此你可以按“功能模块”划分表格，但是一旦引入水平切分之后，表间关联关系就会受到很大的制约，通常只能允许一个主表（以该表ID进行散列的表）和其多个次表之间保留关联关系，也就是说：当同时进行垂直和水平切分时，在垂直方向上的切分将不再以“功能模块”进行划分，而是需要更加细粒度的垂直切分，而这个粒度与领域驱动设计中的“聚合”概念不谋而合，甚至可以说是完全一致，每个shard的主表正是一个聚合中的聚合根！这样切分下来你会发现数据库分被切分地过于分散了（shard的数量会比较多，但是shard里的表却不多），为了避免管理过多的数据源，充分利用每一个数据库服务器的资源，可以考虑将业务上相近，并且具有相近数据增长速率（主表数据量在同一数量级上）的两个或多个shard放到同一个数据源里，每个shard依然是独立的，它们有各自的主表，并使用各自主表ID进行散列，不同的只是它们的散列取模（即节点数量）必需是一致的.
sharding中需要解决的问题
-
事务问题。当同一个业务中涉及到多库时，就需要考虑分布式事务了。对于分布式事务的解决，有多种方案，比如两阶段提交、一阶段提交、Best Efforts 1PC模式和事务补偿机制等。 -
数据迁移，容量规划，扩容等问题。建议利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。 -
跨节点sql。如跨节点join、count、order by、group by以及聚合函数等。只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。因为它们都需要基于全部数据集合进行计算。count、group by等问题，一般的解决方案是分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。 -
分布式唯一ID问题。BIGINT型可以使用Twitter的分布式自增ID算法Snowflake，VARCHAR类型可以考虑UUID。但是Snowflake也会有自己的问题，比如某些场景，生成的值大部分都是偶数。 -
sharding的时候还需要考虑自身的业务。比如根据用户ID分订单表，有些用户根本不下单，但是可能有些用户的订单量占比超过总量的80%，如果这些用户被sharding在了同一个库和表中，实际的sharding效果就会很差。这种情况就需要自定义分表规则。
中间件
对于Java服务来讲，很大的一个优势就是生态完善，组件齐全。sharding也是如此。sharding的中间件大概可以分成两大类，一种是基于jdbc的lib组件，一种是基于代理(Proxy)的中间件。基于jdbc的lib组件，好处在于易于和Java服务集成、轻量；易于上手，无运维成本；业务直接到数据库，少一层proxy理论上性能更好。基于Proxy的中间件，需要在所有的数据源中间搭一个Proxy服务，Java的数据源只连接到Proxy上，由Proxy负责底层的分库分表，以及请求路由，优势在于解耦性比较高；可以找专门的DBA负责和运维Proxy，分库分表操作对于Java程序员透明化；易于实现监控、数据迁移、连接管理等功能；劣势就是运维成本的增加，小公司可能没有预算请专门的DBA和运维人员来做这个解耦工作。
lib组件包括：当当网sharding-sphere、蘑菇街TSharding；
基于Proxy的中间件：TDDL、DBProxy、Atlas、oneproxy、vitess、mycat、cobar等。此处就不做各个中间件的对比了。
代码
https://github.com/chxfantasy/dynamic-datasource-with-sharding-starter
这里实现了一个支持多库路由、分库分表的spring-boot-starter，基于baomidou/dynamic-datasource-spring-boot-starter 和 sharding-sphere
dynamic-datasource本身是为了在同一个系统中支持多库，包括主备、读写分离、多库等，多个读库时，支持定义负载均衡算法；sharding-sphere是基于lib的分库分表组件，可以根据配置的规则动态路由到相关库和表。在我的代码中，sharding-sphere做一个dynamic-datasource的一个数据源。
一个问题：既然sharding-shpere本身已经支持多库、分库和分表，为何还要再将它集成到dynamic-datasource中？有两方面原因：首先，sharding-sphere原理是对sql语句进行改造，然后路由到相应的数据源和表，这就导致它对某些sql语句不支持，比如distinct，在分库分表的场景下就无法使用distinct关键字，但是对于未sharding的表，也无法使用distinct，这时候就可以使用dynamic-datasource来为未sharding的表做一个新的数据源；其次，某些系统，可能需要挂载很多数据库(比如后台管理系统需要挂载5个库)，而其中只有1个库涉及到sharding，而其他4个库不涉及，这时候就只能用dynamic-datasource来管理另外的4个库和数据源。
代码中有example，仅供参考。
