一、全局ID

分布式环境数据库可以拆分，单个表的自增ID只能保证该表唯一，会在数据合并、迁移时候引发ID冲突问题，基本无解；
常见方案：
1、UUID
好处：API简单
坏处：占用空间大、可读性差；
2、ID生成表
集中的id生产表，典型Flicker案例，利用集中的一个表生产自增ID再分配，为保证高可用，设置两台机器，从不同起始值和步长来生产奇偶数ID；
缺点：使用了Mysql独特的语法Replace into；
3、Snowflake
Twitter把存储系统从Mysql迁移到Cassandra过程中由于Cassandra没有顺序的ID生产机制，而开发的一套全局ID生产服务；
41位时间序列+10位机器标识+12位计数顺序号；
4、结合缓存的方案
对ID生产表方案的扩展，取一定数进行缓存到本地缓存中；
优点：高性能，低延迟；
缺点：ID不连贯；
5、UidGenerator
百度开源的一个分布式ID服务，基于Snowflake算法的唯一ID生成器，进行了改良；

二、哈希取模

哈希是最常见的数据分布方式，可以用业务ID或者key，通过hash计算求余，余数作为处理该数据的服务器编号；
好处：算法简单，
缺点：id不均匀，会出现数据分布倾斜，另外节点扩容，数据迁移麻烦；
扩容问题：
新增的节点如果是缓存服务，那么会命中不了，数据库数据也是一样；解决方案是预设足够多的逻辑库，随着物理负载增加，做逻辑库和新增物理库的替换即可，相当于在应用和物理数据库间增加了一层映射关系；

三、一致性哈希

主要解决单调和分散性问题，单调性保证原有已分配的内容可以被映射到原有缓冲中去，避免节点增减过程中不能命中；
虚拟节点位解决均匀的分布节点和数据到一致性哈希值域环上，解决平衡性问题，使得所哟缓冲空间得到利用；

四、路由表

在需要全局计算的场景，比如抽奖，每个预算分片中的额度是一定的，各个预算分片都记录在路由表中，在高并发情况下比较对热点记录进行拆分到不同逻辑数据库中，由路由表识别哪些是否用完预算，无预算则不再路由。
缺点：路由数据是集中管理的，存在单点风险，规模小或者有备份机制则可行；

五、分库分表

1、分表
单表数据量大到500万甚至1000万时候，sql性能会下降，保证单个表数据量可控，提高SQL性能；
2、分库
一个库一般我们经验而言，最多支撑到并发 2000，一定要扩容了，而且一个健康的单库并发值你最好保持在每秒 1000 左右，不要太大。那么你可以将一个库的数据拆分到多个库中，访问的时候就访问一个库好了。
3、常用中间件：

cobar、TDDL、atlas、mycat、sharding-jdbc

sharding-jdbc 目前推出到了 2.0 版本，支持分库分表、读写分离、分布式 id 生成、柔性事务（最大努力送达型事务、TCC 事务）。
sharding-jdbc 这种 client 层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合 sharding-jdbc 的依赖；
mycat 这种 proxy 层方案的缺点在于需要部署，自己运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。
4、拆分策略
可以进行垂直分，也可以进行水平分，垂直拆比如一个大表拆成订单表、订单支付表，订单商品表，水平拆分则各个表结构一致，数据不一样，合起来为原来的表的全量数据；

参考：

1、《深入分布式缓存从原理到实践》
2、分库分表技术演进暨最佳实践 https://www.jianshu.com/p/f29e73b97794
3、UidGenerator：百度开源的分布式ID服务 https://www.jianshu.com/p/5509cc1b9a94