生成分布式id的核心就是:1. 全局唯一 2. 顺序递增
1)简单,使用数据库已有的功能
2)能够保证唯一性
3)能够保证递增性
4)步长固定
1)可用性难以保证:数据库常见架构是一主多从+读写分离,生成自增ID是写请求,主库挂了就玩不转了
2)扩展性差,性能有上限:因为写入是单点,数据库主库的写性能决定ID的生成性能上限,并且难以扩展
1)增加主库,避免写入单点
2)数据水平切分,保证各主库生成的ID不重复
由1个写库变成3个写库,每个写库设置不同的auto_increment初始值,以及相同的增长步长,以保证每个数据库生成的ID是不同的(上图中库0生成0,3,6,9…,库1生成1,4,7,10,库2生成2,5,8,11…)
3)改进后的缺点:
(1)丧失了ID生成的“绝对递增性”:先访问库0生成0,3,再访问库1生成1,可能导致在非常短的时间内,ID生成不是绝对递增的(这个问题不大,我们的目标是趋势递增,不是绝对递增)
(2)数据库的写压力依然很大,每次生成ID都要访问数据库
数据库使用双master保证可用性,数据库中只存储当前ID的最大值,例如0。ID生成服务假设每次批量拉取6个ID,服务访问数据库,将当前ID的最大值修改为5,这样应用访问ID生成服务索要ID,ID生成服务不需要每次访问数据库,就能依次派发0,1,2,3,4,5这些ID了,当ID发完后,再将ID的最大值修改为11,就能再次派发6,7,8,9,10,11这些ID了,于是数据库的压力就降低到原来的1/6了
1)保证了ID生成的绝对递增有序
2)大大的降低了数据库的压力,ID生成可以做到每秒生成几万几十万个
1)服务仍然是单点
2)如果服务挂了,服务重启起来之后,继续生成ID可能会不连续,中间出现空洞(服务内存是保存着0,1,2,3,4,5,数据库中max-id是5,分配到3时,服务重启了,下次会从6开始分配,4和5就成了空洞,不过这个问题也不大)
3)虽然每秒可以生成几万几十万个ID,但毕竟还是有性能上限,无法进行水平扩展
单点服务的常用高可用优化方案是“备用服务”,也叫“影子服务”,所以我们能用以下方法优化上述缺点(1)
对外提供的服务是主服务,有一个影子服务时刻处于备用状态,当主服务挂了的时候影子服务顶上。这个切换的过程对调用方是透明的,可以自动完成,常用的技术是vip+keepalived
string ID =GenUUID();
1)本地生成ID,不需要进行远程调用,时延低
2)扩展性好,基本可以认为没有性能上限
1)无法保证趋势递增
2)uuid过长,往往用字符串表示,作为主键建立索引查询效率低,常见优化方案为“转化为两个uint64整数存储”或者“折半存储”(折半后不能保证唯一性)
uint64 ID = GenTimeMS();
1)本地生成ID,不需要进行远程调用,时延低
2)生成的ID趋势递增
3)生成的ID是整数,建立索引后查询效率高
1)如果并发量超过1000,会生成重复的ID(致命性)
snowflake是Twitter开源的分布式ID生成算法,结果是一个long型的ID。其核心思想是:使用41bit作为毫秒数,10bit作为机器的ID(5个bit是数据中心,5个bit的机器ID),12bit作为毫秒内的流水号(意味着每个节点在每毫秒可以产生 4096 个 ID),最后还有一个符号位,永远是0
1)不依赖于数据库,灵活方便,且性能优于数据库
2)ID按照时间在单机上是递增的
1)在单机上是递增的,但是由于涉及到分布式环境,每台机器上的时钟不可能完全同步,也许有时候也会出现不是全局递增的情况
当使用数据库来生成ID性能不够要求的时候,我们可以尝试使用Redis来生成ID。这主要依赖于Redis是单线程的,所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。可以使用Redis集群来获取更高的吞吐量。假如一个集群中有5台Redis。可以初始化每台Redis的值分别是1,2,3,4,5,然后步长都是5
1)不依赖于数据库,灵活方便,且性能优于数据库
2)数字ID天然排序,对分页或者需要排序的结果很有帮助
1)如果系统中没有Redis,还需要引入新的组件,增加系统复杂度
2)需要编码和配置的工作量比较大
【分布式全局ID】细聊分布式ID生成方法
分布式系统唯一ID生成方案汇总
分布式全局ID生成器设计
注:文章是经过参考其他的文章然后自己整理出来的,有可能是小部分参考,也有可能是大部分参考,但绝对不是直接转载,觉得侵权了我会删,我只是把这个用于自己的笔记,顺便整理下知识的同时,能帮到一部分人。
ps : 有错误的还望各位大佬指正,小弟不胜感激