Web服务架构之路---分布式Id制造器之id_maker

问题介绍

在传统做法中，我们使用关系型数据库提供的自增字段进行自增来产生记录的唯一id，但是存在两个重大的问题

1. 值是相对于表不重复的，在分SET的情况下，我们必须另起炉灶独立出来

2. 大量并发写的情况下，采用自增来制造id本身会给MySQL等产生极大的负载压力

为了解决上述的问题，提高集群性能，便定义了现在使用的id_maker。

系统架构

       

1. id_list用于存放从Dao中获取的Id列表块，块与块之间多数是不连续的

2. 每个使用进程背后存在一个统一的更新线程，如果id_list中存在的id数量小于配置的每次分配深度的10%，则会进行新块的填充

3. Dao用于从DB中分配每种类型的制造器全局唯一的id列表块 

其特点就像水池子，每个使用的类型都有一个池子，每次防水都会填充很大一片水位，当水位出现不足情况时进行水位的更新。

统一配置

1. 类型：用于区分不同的业务需求

2. 目前水位： 告知当前使用的Id情况

3. 每次分配深度： 每次获取块的大小，该配置决定了每次填充的水位高度。业务量较小的时候该值可以配置较小，当量大的时候适当增加该配置值即可。

4. 初始水位： 在第一次增加配置时，会有初始水位项。主要用于初始数据导入时，不要和已有的数据重复。

接口定义

[java]  view plain  copy

1. public abstract class IdMaker {  
2.     public abstract long createId() throws IdException;  
3.       
4.     public int createIdIntSafe() throws IdException;  
5. }  
6.   
7. public class IdMakerFactory {  
8.         public IdMaker getIdMaker(int type);  
9. }  

总结

1. IdMaker适用于大部分产生Id的场景，每次获取Id就只是简单的取一个本地的整数， 产生速度快。

2. 只保证唯一，不保证连续性

3. 存在id丢失的情况。每次进程重启后，会丢掉在池子里面的id。

4. 分配深度决定着请求到的频度（这是代价最大的一步）和每次重启进程丢失的id数目。制造id的请求量较大时，增大分配深度是最好的选择。