数据库在做了分库分表之后,关于ID主键,我认为需要考虑这几点:
生成算法当我们的数据库是单台的时候,是不用太操心主键的生成,但是当数据库进行了分库分表之后,那么主键的生成就需要注意了,至少不能使用数据库内部的自增长序列了,通常要引入分布式唯一标识码的生成算法。
利用数据库生成:先说最笨的方法,利用数据库的自增长序列生成,数据库内唯一,有人会说,刚说完不能用数据库的自增长序列,这么快就要被打脸了么?其实这个的意思是,先利用(额外)的一台数据库,通过其自增长序列得到主键,然后作为分库分表的主键;
利用Redis/MongoDB/zookeeper生成:Redis的单线程的,利用incr和increby;MongoDB的ObjectId;ZK通过znode数据版本;都可以生成全局的唯一标识码;
UUID:生成唯一标识码最常用的算法之一;
Snowflake:Twitter开源,基于zk,41位时间戳(毫秒数)+10位机器的ID+12位毫秒内的流水号+1位符号位(永远是0);
UidGenerator:百度开源,基于snowflake算法;
Leaf:美团开源,能保证全局唯一性、高可用、趋势递增(不太安全,比如泄露公司订单数量)、单调递增等。
扩容会比较麻烦分库分表通常的方案都用主键mod分表的数量,来把数据路由到某一个数据库分片上。例如分了10张表,那么就是ID%10,得到结果0-9,代表不同的表;但是当数据量进一步增多的时候,单库的数据量达到了一定的级别之后,那么就需要分更多的表,那么这时候有哪些处理方案呢?
做数据迁移:最简单暴力,也是最麻烦的一个方案;因为当分表(分库)数量增多的时候,因为分片规则的变化,每个表的数据都要被重新分配到多个新的表;
如果id是一个增长的全局序列,当前有十张表,那么分表的算法为:id%10,根据0-9路由到10个表中;当表扩到20张的时候,扩容那一刻取max_id,那么未来分库的算法也就变成了:
if(id<max_id){id%10} else {id%20};有些分表的算法本身就带时间戳,可以基于id中的时间戳来实现,比如Snowflake算法(见上文),这个算法是一个64位的Long值,前42位就是一个精确到毫秒的时间戳,那么我们的分库算法也就可以以某个时间点来判断:
if(id中的时间<增加分表那一刻的时间){id%10} else {id%20};我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。Copyright © 广州京杭网络科技有限公司 2005-2024 版权所有 粤ICP备16019765号
广州京杭网络科技有限公司 版权所有