【业务学习】简述ID生成器【业务学习】简述ID生成器

引言
大家好，好久不见，时隔一年终于又拾起了写博客这件事。
在我们日常工作中，我们常需要用全局唯一ID作为数据库主键，或者用于生成订单id，用于生成商品ID等等。本篇主要介绍我们常见的ID生成器的方式：利用数据库生成和雪花算法。
利用数据库生成ID
自增ID达成目的利用MYSQL自增主键的特性来构造ID生成器。首先生成一张ID生成器表，每次我们需要生成ID的时候在这个表里插入一行记录，获取到这行记录生成的主键id，就可以拿到一个全局唯一id，基本满足需求。

｜ id	ctime
1	2021-09-05 12:00:00
2	2021-09-05 12:01:00

尝试进阶那么有的盆友们会说了，这个方法肯定会影响性能啊，每次请求都需要去连接DB获取id，伤不起啊。没关系，我们优化一下。我们采用分段请求，即每次请求一段ID（例如20个ID）缓存到本地，这样就只需要等本地ID使用完了再去请求了，增加了性能。到这又有朋友说了，每次批量插入数据性能还是不行，而且在多业务方同时使用的时候性能更差，这怎么办呢？别着急，往下看。
我们可以将表设计成类似下表这个结构。

biz_tag（业务线）	max_id	step（每次申请ID数）	update_time
app	1000	1000	2021-09-05 12:00:00
pc	2000	1000	2021-09-05 12:00:00

从上表我们可以看出，每次我们请求ID的时候的大概流程是这样的：获取到当前的max_id -> 拿业务线标识申请（max_id，max_id + step]之间的id -> id使用完 -> 重新发起流程。这样DB的压力就会小很多，但是呢，在生产环境中也会存在一些问题：例如：

- 系统性能依赖DB的更新，如果更新DB出现尖刺，服务性能将收到影响 - 强依赖DB的可用性，DB一旦出现宕机将整个不可用

对于以上两个问题，我们有以下解决思路：

预处理，当本地队列使用百分之七十的时候就去申请后新的ID（比例根据业务需求设置）
在本地缓存一个队列作为“备胎”，当服务不可用且正常队列用完时可以使用“备胎”进行工作，并且不断的去申请新的队列。

如果我们服务的会出现突增流量的情况，我们也可以动态的调整每次申请的id数，设定适配业务的算法去调整这个step，具体的算法此处不再赘述。
当然，业界使用数据库去生成DB的方式有很多，在如何保障可用性上做了很多的优化，因为这种方式最终需要强依赖DB
雪花算法
它给每台机器分配一个唯一标识，然后通过时间戳+标识+自增实现全局唯一ID。这种方式好处在于ID生成算法完全是一个无状态机，无网络调用，高效可靠。这种方法也是我们业务中所常见的方式，下面我们来看看我们采用的的52位和64位的ID怎么生成。
64bit 42b timestamp + 8b counter + 8b countspace + 6b serverid