分布式系统全局唯一id的生成

在实际项目中，本人在做需求时遇到了以下场景需要生成全局唯一id：

1，为解决mq消息可能乱序的问题，我们需要一个全局且自增的id来标识消息

2，数据库分库分表也需要一个全局唯一升序的id

所以下面总结下生成全局唯一id的思路:

方法1：使用数据库提供的自增sequence

以Oracle为例,我们可以新建一个序列seq_common,使用sql:select seq_common.nextval from dual，来生成一个全局唯一id，但缺点也很明显，一是单点，可靠性没法保证，二是如果每次为了获取id就访问数据库一次，在高并发下会有性能问题

方法2：针对方法1中存在的问题，针对性能问题，我们可以一次批量获取多个id，这样可以大大降低访问数据库的频率，针对可靠性问题，我们可以建立多个序列，分布在不同的库中，以两个序列为例，比如序列1产生0,2,4,6,8..，序列2产生1,3,5,7,9...但是这个方案也有点小问题，id总体来看是升序的，但是在某次获取的id可能不是绝对升序，需要看实际的场景是否允许。

方法3：jdk提供了生成UUID的方法，可以直接拿来用，不过也有缺点，一是uuid是string类型的，长度较长，作为主键时索引效率可能较低，二是无法保证升序

方法4：利用时间戳生成id，System.currentTimeMillis即可，但是当并发超过1000，那么就可能出现重复的id（jdk中目前也没见提供更为精确的时钟,nanotime只是用于计时，其返回值还可能是负数）

方法5：twitter的解决方案，其思路主要是：一个long型的id，共64位，其中41位的时间序列（精确到毫秒，41位的长度可以使用69年），10位的机器标识（10位的长度最多支持部署1024个节点），12位的计数顺序号（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号） 最高位是符号位，始终为0，这个算法单机每秒内理论上最多可以生成1000*(2^12)，也就是400W的ID，完全能满足业务的需求。实际使用中，我么可以借鉴这个方案，结合自己的业务实现自己的分布式ID生成算法。举个例子，比如我们的需求如下：

a，单机并发在1w左右，未来单机并发量不超过5w，预计运行10年

b，机器目前200台，未来预计不超过500台

c，业务线小于10个

首先要运行10年，那么一共有10*365*24*3600毫秒，我们预留40bit完全足够了，单机并发量不超过5w，那说明一毫秒的并发量不超过50，只需要6bit即可，业务线用4bit，机器节点用9bit表示，其结构如下:

上面的方案还是有个问题，不能保证某次获取到的id是绝对升序的，只能保证总体升序。

回到我们的两个场景，第一个场景，因为要全局唯一且每次必须是升序，我们只能考虑从数据库序列入手了，因为目前我们的访问量不大，所以可以采用单点一次批量获取的模式，长远考虑来看，为了保证可靠性，可以采用数据库双主的模式，如果单点宕机了，另一个主顶上。

第二个场景的话应该上面的几种思路都可以，但考虑到可以不要求绝对升序，只需要保证总体升序即可，可以按照我们上面的方法5，结合具体业务场景生成全局唯一id。