本文探讨了分库分表中主键生成的各种策略，包括UUID、SNOWFLAKE算法、基于数据库自增ID、数据库集群模式以及基于Redis的自增ID。分析了各自优缺点，如UUID对性能的影响，SNOWFLAKE对时钟回拨的处理，数据库集群的ID重复问题及解决方案，以及Redis持久化带来的挑战。还提及了百度、美团和滴滴的开源ID生成方案。
分库分表主键生成策略
最近，项目单表数据量剧增，使用Sharedingsphere进行了分库分表，分表的过程，就必须考虑主键id的生成策略，要保证全局唯一。
1.UUID
UUID是SharedingSphere预置主键生成策略，看到代码后，我惊呆了，返回居然是32位字符串，暂且类型的问题。单单无序性，在insert数据时主键无序就会导致频繁的页分裂，严重影响性能，显然不适合作为作为常规表的主键。
2.SNOWFLAKE
SNOWFLAKE(雪花算法)，也是SharedingSphere预置主键生成策略，会生成一个64bit的Long长整型的值，相较于UUID，更加适用于主键ID；
其中，第一bit为符号位0，不作为数据记录，后续的41bit作为时间戳，2的41次幂 大约69年的时间，额，应该够用了，再后续的10bit为机器id，再分布式的系统中可以使用机器的ip地址做一层映射到具体的编号，后续的12bit，作为序列号位，处理同一毫秒生成的id数，理论上支撑409.6w的QPS。
优点：由于时间bit排在前面，所以在时间层面生成的id为整体上递增的。并且在分布式的系统中不会产生ID碰撞。另外，雪花算法也提供一中生成id的思路，可以根据实际应用的场景&
最低0.47元/天 解锁文章
857
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
