分布式环境下生成全局唯一ID？看看美团怎么做！

大家好，我是程序员牛肉。

生成全局唯一ID在分布式系统中是一项很核心的技术。全局唯一ID保证了分布式系统下数据的唯一性，避免了很多问题。

而探讨如何高效的生成全局唯一ID一直都是一个热门话题，各个大厂也给出了自己的解决方案。

今天我们来看一看美团在自己公开的技术文档中分享的一个方案：“LEAF数据库方案”

美团的生成方案的底层是在数据库中进行生成全局唯一ID。因此在之前我们要先简单讲一下数据库生成全局唯一ID。

我们可以设计这样一个表来在数据库中生成全局唯一ID：

create table order_test.order_id
(
    id   int auto_increment
        primary key,
    name varchar(20) null,
    constraint name
        unique (name)
);

那么我们就得到了这样一张表：

在查询的时候，我们使用这样一条语句：

begin ;
replace into order_id (name) values ("order_id");
SELECT last_insert_id();
COMMIT ;

这样我们基于name的唯一性，就做到了对id的自增：

而这种简单的使用一张表来维护全局唯一ID的方式并不安全：

在高并发环境下，万一这张表崩掉怎么办？

所以为了优化，我们又采用了多表的思想，例如我们可以用两张表，一个表维护订单id为偶数，一个表维护订单id为奇数。

这样的话，我们就是实现了减轻单表压力。而且这种思想是可以不断的改进的，我们可以通过让表维护不同类型的数字来不断的拆表，减轻单表压力。

而且这种方式如果要抵抗高并发的话，就要不断的去加数据库，对维护数字进行分类。因此这种方式其实缺点还是比较明显的。

但其实基于数据库构造全局唯一ID是有成熟的方案的：美团的LEAF数据库方案。

LEAF数据库方案简而言之就一句话：批量获取ID进行处理。

在上文我们简单的对数据库进行优化的时候，优化方向基本都来源于高并发下数据库高频的读写操作。

而LEAF数据库方案也是针对这个方面进行优化的。

我们可以把图中的leaf简单的理解为是一个生成全局唯一ID的服务。那么整个LEAF数据库的思想就是：leaf服务提前就拿好一批号端，例如从0-1000。那么我在生成唯一ID的时候，压力就从数据库转到了Leaf这个服务里面。

优点：

1.leaf只是一个简单的web服务，方便进行扩展。

2.ID号也满足趋势递增的要求

3.容灾性高，由于生成唯一ID的是leaf服务，而且内部有号段缓存，因此即使数据库挂了，短时间内也可以正常对外提供服务

缺点：

当所有的leaf用完自己的号段之后，就会向数据库再次请求号段，此时leaf服务是不可用的。而如果此时有大量的请求leaf服务，就会引发一段尖刺。

解决方案：

我们并不会等到号段全部用完之后再去请求新的号段。美团给出的技术方案是当号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。

一开始先用A号段，等 A号段消耗到10%的时候，就向数据库请求新号段。之后当前号段消耗完之后就可以进行快速的切换。如此循环往复。

相信通过我的介绍，你已经了解什么是“LEAF数据库方案”。希望我的文章可以帮到你。