ID生成器——雪花算法

分库分表中经常遇到需要保证多个分库或分表中的id唯一性，为区分同一个表不同分库中的id，通常需要引入ID生成器中间件来保证id唯一性。当id作为分库分表参数时，有时会希望属于同一类别的数据存入到一个库中，便于查询、维护，此时id本身则需要包含某些用于识别。文中用场景——“用户发帖”来介绍雪花算法ID生成器的实现。

为什么需要ID生成器

mysql数据库记录主键id一般有两种方法：自增或UUID，如果数据表定义没有主键id，数据库会在添加数据时自动生成隐藏主键id。数据记录是基于B+树组织的，主键则是B+树的节点索引，为保证数据有序性及性能，所以数据表定义时主键一般不采用UUID，UUID会导致树结构在插入时由于排序引起页分裂、页重组等性能问题。

然而在分库分表中时，采用自增方式无法保证不同库表中同类数据唯一性，当然我们可以添加一个具有唯一性标识的普通列如uuid，但这样对于存储来讲是一种浪费，在某些查询如uuid范围查询时，性能可能不如人意。

引入ID生成器中间件，在添加数据时，从中间件获取相应的id，并作为分库分表参考值。ID生成器须保证ID唯一性、有序、良好性能。

几种实现方法

数据库自增

比较简单的办法是采用数据库作为ID生成器，建立一个表用于存储ID，当申请ID时，则表中的对应的ID记录自增+1即可。

id	service_key	id_generator_value
1	blog	10002
2	user	20087

上表t_id_generator是一个demo，当blog表或服务需要添加记录时，第一条记录id_gererator_value字段自增+1，更新库并返回给申请者即可。每个表或服务都可在表中注册一行记录，用于区别不同的表或业务。

这种方式比较简单也很容易实现，并且还可以在表中加入其它字段进行区分或组合。这种方式在申请ID的时候需要与数据库交互，所以实时性并不太好，容易受网络、磁盘IO等影响。

Redis缓存自增

另一种方法是采用Redis缓存替代数据库，同样也是采用集中式存储，redis性能及自带的INCR命令能完美支持。但同样避免不了网络影响，并且当Redis宕机时可能会导致部分数据丢失导致id重复。

雪花算法

雪花算法是由Twitter公布的分布式主键生成算法，它能够保证不同进程主键的不重复性，以及相同进程主键的有序性。

在同一个进程中，它首先是通过时间位保证不重复，如果时间相同则是通过序列位保证。 同时由于时间位是单调递增的，且各个服务器如果大体做了时间同步，那么生成的主键在分布式环境可以认为是总体有序的，这就保证了对索引字段的插入的高效性。

使用雪花算法生成的主键，二进制表示形式包含4部分，从高位到低位分表为：1bit符号位（固定为0）、41bit时间戳位、10bit工作进程位以及12bit序列号位。

41bit时间戳位：当前时间戳与时间纪元差值，41位可以容纳的毫秒数是 2^41，结果约等于69年，可以满足很多系统或表的业务要求了。

10bit工作进程位：这段主要应用在分布式中，主要保存集群分布式ID键生成时，不同机器或应用生成的ID在这10bit中不一样，应有所区分，保证不同机器上同一业务生成的ID不一样。

12bit序列号位：该序列是用来在同一个毫秒内生成不同的ID。如果在这个毫秒内生成的数量超过4096(2的12次幂)，那么生成器会等待到下个毫秒继续生成。

雪花算法ID生成器可以在服务内部生成，不需要像上述两种方法依赖专门的服务机器。服务集群中各机器区分工作进程位，不同节点在相同毫秒段产生的ID也是不一样的。

改进的雪花算法

上述雪花算法所采用的位数并不是固定的，例如可采用8bit的工作进程位，14bit的序列号位，这样一个毫秒内可生成16384(2的14次幂)，可产生更多的ID，这些都可以根据业务要求灵活调整。

考虑这样一个场景——用户发帖，帖子表t_blog采用分库，需要根据发帖的用户user_id来分库，这样同一用户的帖子数据就分布在同一库中，便于查询、维护。业务较频繁的场景是：根据帖子id或用户user_id来查询。

分库方案

1. 根据帖子id分库。当根据帖子id查询时可以定位到对应库，但如果采用user_id来查询关联的帖子，则需要查询所有库然后进行整合，这个会很影响效率。所以一般都会将user_id与帖子id映射出来mapping(user_id, blog_id)存储到其它数据库或缓存中，这样当需要用user_id查询时则先查询mapping(user_id, blog_id)然后再定位到对应的帖子库t_blog.

2. 根据用户user_id分库。这个与以上类似，同样需要一个中间mapping(blog_id, user_id)存储来定位对应的帖子库。

上述两种方案都需要中间存储，在数据量较大，查询并发较高的情况下，由于需要查询mapping层，会对查询性能有影响。

基因算法可以兼容这两种场景，而且也不需要引入mapping存储。其主要原理就是在blog_id中融合user_id生成的id，这个id包含帖子和用户两重信息，因此有称之为基因算法。

将上述雪花算法的各bit段进行改造：1bit符号位、41bit时间戳位、10bit工作进程位、12bit序列号位+业务号位。

将12bit序列号位拆成 序列号位+业务号位，即序列号位+业务号位总长是12bit.假设业务号位长是 n_s bit，那么分库的最大数量不能超过2的n_s次幂，分库数量最好是2的幂关系。

假设我们采用的业务号位长是4bit，那么序列号位长是8bit，雪花算法就演变成：1bit符号位41bit时间戳位、10bit工作进程位、8bit序列号位、4bit业务号位。这4bit业务号位存储的是user_id的后4位，分库数量不超过16(2的4次幂)，那么在分库时，其实是基于id的后4位进行分库，这后4位同时也是user_id的后4位，这样就相当于同时基于blog_id（帖子id）和user_id分库，这样可同时满足根据帖子id或用户user_id来查询两种场景。

代码实现

/**
 * 雪花算法实现
 * 1个符号位 + 41 bit时间戳 + 10位工作进程bit + 12 bit (序列号+业务号)
 * 12 bit序列号 = customServiceIdBit + 序列号 sequence
 */
public class SnowFlowerIdGenerator implements IdGenerator{
   
    
    /**
     * Start time intercept (2020/9/30 20:00:00)
     * 占41位
     */
    public static final long EPOCH = 1601460000000L;
    
    private static final Logger logger = LoggerFactory.getLogger(SnowFlowerIdGenerator.class);