分布式唯一ID取号方案

对于分布式的系统而言，如何生成一个唯一的ID是基本的。比如分库分表时各个表的主键ID必须唯一，并且必须是递增的。还有各种业务订单的订单编号，这个也必须是唯一的。
对于这种取唯一号，并且需要递增的场景。目前我们公司采取的方案是这样的：
1.建立一个取号表。表里有下个取号的号码大小，每次取数的步长。
2.每次取数时，将下个取号的号码以及步长加载进内存中。
3.每次取号都直接从缓存中取号，如果取号完毕，则再更新数据库，重新将下一个区段的号加载进缓存中。
但是这个方法有个很大的性能问题。如果取号完毕，进行数据库更新重新取号，那么这个数据库取号必须加分布式锁。即每次只能有一个线程进行取号。其他线程必须全部等待。
因为这个原因。导致经常性的效率的瓶颈在我们的取号服务里。这个我们必须寻找一个合适的方案来替换掉我们原来的取号服务。
目前市面上比较常规的取号方案有如下几种：
1.UUID
这种方案直接不考虑，因为他无法递增，并且是字符串，不能作为表的主键
2.多台mysql主键自增的方案
这种方案就是每次从数据库中按步长读取数据，每个数据库的起点不一致，比如我有A,B两台数据库实例。A的起点为1，步长为4，那A的取号就是1，5，9，13等等。B的起点为2，那B的取号就是2，6，10，14等等。但是这种效率不高，比我们目前用的效率更低
3.雪花算法。
这个方案是twitter使用的取号算法。它生成的取号字段是64位的整数。构成结构如下：
1位的固定数字0+41位的时间戳+5位的机房id+5位的机器id+12位的序号
这就是说同一时间，同一机房同一机器，同一毫秒之内可以生成2^12-1=4095个数据。
但是这个算法有个问题就是严重依赖机器的时钟，如果一旦机器发生时钟回拨的操作，则生成的ID就可能会重复。而且64位数据的话，作为表的主键还是比较大的，主键这么大，对表的查询效率影响很大。
4.利用redis生成id
但是这种方案的话，就非常依赖于redis的性能，而且对带宽的要求比较高。一旦网络延迟，就会导致系统直接僵死
5.美团的双buffer方案
这个方案跟我们最开始使用的取号服务方案非常类似，不过我们是单buffer。每次取完这个buffer后，必须等待数据库返回下一个buffer的数据才行。双buffer方案，就是同时存在A,B2个buffer，
A buffer取号如果达到一个阈值，比如百分之10，那就会启动线程去看看B buffer的数据是否已经加载，如果没有加载就进行加载。A buffer取完后，直接可以用B buffer的数据，并且在B buffer取到百分之10的时候，再加载A buffer。这样的话，就是每次的从数据库取数据的服务都不会堵塞正在取号的线程。这个取号服务目前看来没有非常严重的短板，生成的id不是那么长，而且效率高，不会堵塞。
美团的取号服务的文章地址：https://tech.meituan.com/2017/04/21/mt-leaf.html

最后编辑于：2020.05.12 00:17:44