分布式ID

应用场景

微博id和订单id。这两种业务的共同点是：短时间内高并发。希望能生成一个全局唯一id做数据库主键，且能根据时间排序。

其中的核心诉求是：id必须全局唯一，并且趋势有序。

生成唯一id常见方法

1. Mysql之auto_increment，Redis之incrby。

优势：均能满足全局唯一且完全有序，单点部署可全局唯一。

劣势：Mysql | Redis资源将成为瓶颈，容易单点故障；假如分布式部署Mysql则需要配置服务器的初始值和步长。

2. uuid，方案较为成熟。

优势：无性能瓶颈。

劣势：无法保证有序。

3. twitter的snowflake算法

优势：能满足全局唯一且完全有序。

劣势：需要独立的开发和部署。

微博是如何做的

微博使用类snowflake算法。并根据微博特殊情况优化。

微博id使用了秒级的时间，用了30bit，Sequence 用了15位，理论上可以搞定3.2w/s的速度。用4bit来区分IDC，也就是可以支持16个 IDC，对于核心机房来说够了。剩下的有2bit 用来区分业务，由于当前发号服务是机房中心式的，1bit 来区分热备。