分布式全局唯一ID
方案一、UUID
UUID的方式能生成一串唯一随机32位长度数据,它是无序的一串数据,按照开放软件基金会(OSF)制定的标准计算,UUID的生成用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字。UUID的底层是由一组32位数的16进制数字构成。
优点:实现简单,全局唯一,不需要考虑冲突的问题,适合标示用户的场景。
缺点:UUID长度过程,mysql建议主键字段长度越短越好,而且UUID包含MAC地址信息,有可能会造成MAC地址泄露。UUID由于是无序的,所以插入性能不是很好,适合写频率较低的场景,因为在数据库设计中,主键一般都是聚集索引,而索引一般是B+树,B+对于有序的插入是分裂追加节点,而对于无序节点的插入,需要移动后续所有节点,性能表现较差。
方案二、自增主键
这个方案就是利用了MySQL的主键自增auto_increment,默认每次ID加n。在分布式的情况下,需要设置每个库的初始值和步长,避免主键冲突。
优点:递增主键,读写效率高,具有一定的业务可读性。
缺点:步长一旦设置,后期无法扩容。
方案三、雪花snowflake算法
雪花算法生成64位的二进制正整数,然后转换成10进制的数。64位二进制数由如下部分组成:
优点:整个ID有序递增,此方案每秒能够产生409.6万个ID,性能好、
缺点:依赖机器的时钟同步,如果出现时钟回调,有可能会主键重复。
方案四:Redis生产方案
利用redis的incr原子性操作自增来生产ID,一般算法为:年份 + 天数 + 小时 + redis自增
优点:ID递增,可读性强。
缺点:需要多发一次网络请求,对性能要求不高的可以考虑。
方案五:Sequence特性
这个特性在SQL Server 2012、Oracle中可用。这个特性是数据库级别的,允许在多个表之间共享序列号。
优点:没什么明显的优点
缺点:只能在SQL Server、Oracle使用
方案五:通过数据库集群编号+集群内的自增类型两个字段共同组成唯一主键
优点:实现简单,维护简单
缺点:需要业务逻辑处理复合主键,且该方法只能一开始就使用,不能从别的方案切换过来。
待续……