今天看了一篇如题所示的相关文章 干货 | 分布式架构系统生成全局唯一序列号的一个思路，很有收获，特来简书分享，加深印象。
通常我们不推荐使用自增主键作为程序的业务字段使用，所以只要保证单表有序且唯一就可以满足大多数场景了。但是如果未来涉及到数据库迁移和分库分表的逻辑变更，那么使用全局唯一且有序的id会给我们减少许多不必要的麻烦。
就唯一性来说，uuid是一个不错的选择，但是uuid本身毫无意义，也无序。
就有序来说，mysql的自增也只是对单库单表有效。
大多数人可能会想到用redis，既满足高并发场景，其原子性操作又能保证唯一。
比如我们搭建一个redis集群，有5台机器。将每个redis节点的初始值分别设置为1,2,3,4,5，step步长不小于redis节点数，假设为5，获取id时使用redis的incr进行累加，便可得到如下表：
| redis节点 | id |
|---|---|
| A | 1,6,11,16,21... |
| B | 2,7,12,17,22... |
| C | 3,8,13,18,23... |
| D | 4,9,14,19,24... |
| E | 5,10,15,20,25... |
所示的有序且唯一id。
使用redis生成全局唯一有序id方式的详细讲解和优缺点可以参见顶部原文。
文章中主要讲解的是基于flicker优化改进的方案。具体实现是，单表递增，内存缓存号段的方式。
首先我们新建一张表unique_id_tab，结构如下：
| 字段名 | 类型 | 描述 |
|---|---|---|
| id | int | 主键，自增 |
| host | varchar | 唯一索引，保存服务器ip |
这里记录ip是为了服务器隔离。假设有5台服务器：192.168.1.1，192.168.1.2，192.168.1.3，192.168.1.4，192.168.1.5
首先，在mysql中执行：
REPLACE INTO unique_id_tab(host) VALUES('192.168.1.n')
得到 192.168.1.n 对应的主键 p;
REPLACE INTO 的用法是首先匹配要插入的值是否存在，如果存在则删除已存在的那条记录，插入新记录，如不存在，直接插入。但要插入的值必须包含主键或唯一索引。
得到主键 p后，将p乘以1000，得到p*1000，以此数作为该批id区间的起始id，(p+1)*1000作为此区间的结束id，并记录在程序内存中。
第一次初始化后，理论上表unique_id_tab的数据为（ip顺序不一定）：
| id | host |
|---|---|
| 1 | 192.168.1.1 |
| 2 | 192.168.1.2 |
| 3 | 192.168.1.3 |
| 4 | 192.168.1.4 |
| 5 | 192.168.1.5 |
对应的该批次的id区间应该是（注意闭合条件）：
| id | id区间 |
|---|---|
| 192.168.1.1 | [1000,2000) |
| 192.168.1.2 | [2000-3000) |
| 192.168.1.3 | [3000-4000) |
| 192.168.1.4 | [4000-5000) |
| 192.168.1.5 | [5000-6000) |
每次请求进来，先去内存中取id，如果id小于区间最大id，直接返回使用，如果id等于最大id，则需要再次申请新的id区间。假设192.168.1.1这台机器的id分配完了，此时执行：
REPLACE INTO unique_id_tab(host) VALUES('192.168.1.1')
表unique_id_tab的数据变为：
| id | host |
|---|---|
| 2 | 192.168.1.2 |
| 3 | 192.168.1.3 |
| 4 | 192.168.1.4 |
| 5 | 192.168.1.5 |
| 6 | 192.168.1.1 |
于是新的id区间为 [6000,7000)。同理，其他机器也用此种方式申请新的id区间。
更多详细讲解请参见原文
