分布式系统ID的生成方法之UUID、数据库、算法、Redis、Leaf方案

编辑:十大棋牌游戏 时间:2020-11-05 热度:8771℃ 来源:棋牌游戏人气排行榜 责编: 十大棋牌游戏

一般单机或者单数据库的项目可能规模比较小,适应的场景也比较有限,平十大棋牌游戏排行榜台的访问量和业务量都较小,业务ID的生成方式比较原始但是够用,它并没有给这样的系统带来问题和瓶颈,所以这种情况下我们并没有对此给予太多的关注。但是对于大厂的那种大规模复杂业务、分布式高并发的应用场景,显然这种ID的生成方式不会像小项目一样仅仅依靠简单的数据自增序列来完成,而且在分布式环境下这种方式已经无法满足业务的需求,不仅无法完成业务能力,业务ID生成的速度或者重复问题可能给系统带来严重的故障。所以这一次,我们看看大厂都是怎么分析和解决这种ID生成问题的,同时,我也将我之前使用过的方式拿出来对比,看看有什么问题,从中能够得到什么启发。

分布式ID的生成特性

在分析之前,我们先明确一下业务ID的生成特性,在此特性的基础上,我们能够对下面的这几种生成方式有更加深刻的认识和感悟。

全局唯一,这是基本要求,不能出现重复。数字类型,趋势递增,后面的ID必须比前面的大,这是从MySQL存储引擎来考虑的,需要保证写入数据的性能。长度短,能够提高查询效率,这也是从MySQL数据库规范出发的,尤其是ID作为主键时。信息安全,如果ID连续生成,势必会泄露业务信息,甚至可能被猜出,所以需要无规则不规则。高可用低延时,ID生成快,能够扛住高并发,延时足够低不至于成为业务瓶颈。分布式ID的几种生成办法

下面介绍几种我积累的分布式ID生成办法,网络上都能够找得到,我通过学习积累并后期整理加上自己的感悟分享于此。虽然平时可能因为项目规模小而用不着,但是这种提出方案的思想还是很值得学习的,尤其是像美团的Leaf方案,我感觉特别的酷。

目录:

基于UUID

基于数据库主键自增

基于数据库多实例主键自增

基于类Snowflake算法

基于Redis生成办法

基于美团的Leaf方案

基于UUID

这是很容易想到的方案,毕竟UUID全球唯一的特性深入人心,但是,但凡熟悉MySQL数据库特性的人,应该不会用此来作为业务ID,它不可读而且过于长,在此不是好主意,除非你的系统足够小而且不讲究这些,那就另说了。下面我们简要总结下使用UUID作为业务ID的优缺点,以及这种方式适用的业务场景。

优点

代码实现足够简单易用。本地生成没有性能问题。因为具备全球唯一的特性,所以对于数据库迁移这种情况不存在问题。

缺点

每次生成的ID都是无序的,而且不是全数字,且无法保证趋势递增。UUID生成的是字符串,字符串存储性能差,查询效率慢。UUID长度过长,不适用于存储,耗费数据库性能。ID无一定业务含义,可读性差。

转载请注明来源:“ http://www.yhbygd.com/yanqing/2020/1105/3136.html ”。