全局唯一ID可以是整型或者字符串。如果是字符串,可以用UUID。缺点是字符串作为ID占用空间大,索引效率比整型低。如果是整型,可以用数据库自增ID,整型ID首先排除掉32位int类型,因为范围太小,必须使用64位long型。
UUID
比如version1。生成一个包含32个16进制字符串(结合机器识别码(全局唯一的IEEE机器识别号,如果有网卡,从网卡MAC地址获得,没有网卡以其他方式获得),当前时间,一个随机数)。不仅能保证分布式集群的全局唯一性,还能保证全球唯一性(mac地址48bit,全球每个设备mac地址唯一)。
优点是简单粗暴,直接本地生成,不需要协调各节点。
缺点是长度大,存储开销大,而且无序(非单调递增)
Go生成uuid方法:https://github.com/satori/go.uuid
数据库自增ID
数据库自增ID从1开始,连续递增,能够保证数据表唯一。
优点:简单。
缺点:数据插入数据表之后才生成自增ID(如果需要用到这个ID,需要再查表返回这个自增ID)。且数据库自增ID不适用于ID有可能需要改变的场景。(数据表主键最好不要修改,特别是数据量大的时候,否则会导致大规模的数据记录物理位置调整)此外,数据库自增ID只能保证数据表唯一,不能保证多个数据表之间唯一,有一定的限制。
集中式ID生成器
比如借助redis和zookeeper生成全局唯一ID,缺点是严重依赖外部应用,增加复杂程度(最好不要引入系统中原本不需要的组件)。
Redis
Redis的所有命令是单线程的,可以利用Redis的原子操作INCR(让key中存储的value值+1),来生成全局唯一的ID。比如利用Redis来生成每天从0开始的流水号,如订单号=日期+当日自增长号。可以每天在Redis中生成一个Key,适用INCR进行累加。
优点是性能高,缺点是redis宕机后数据丢失。
zookeeper
通过创建zookeeper的顺序模式的znode节点,可以生成全局唯一的ID。节点创建完成后,会返回节点的完整的层次路径和生成的序号,可以通过截取路径末尾的数字,作为新生成的ID。由于zookeeper保证了同一时刻只有一个节点能够在zookeeper上创建znode节点,所以能够保证此序号是全局唯一的。
缺点是高并发场景下速度慢。