AI主导了棒球世界大赛的决策流程

我们需要一个ID的时候，向表中插入一条记录返回主键ID，但这种方式有一个比较致命的缺点，访问量激增时MySQL本身就是系统的瓶颈，用它来实现分布式服务风险比较大，不推荐！

优点：

•  实现简单，ID单调自增，数值类型查询速度快

缺点：

•  DB单点存在宕机风险，无法扛住高并发场景

3、基于数据库集群模式

前边说了单点数据库方式不可取，那对上边的方式做一些高可用优化，换成主从模式集群。害怕一个主节点挂掉没法用，那就做双主模式集群，也就是两个Mysql实例都能单独的生产自增ID。

那这样还会有个问题，两个MySQL实例的自增ID都从1开始，会生成重复的ID怎么办？

解决方案：设置起始值和自增步长

MySQL_1 配置：
 

UUID的生成简单到只有一行代码，输出结果 c2b8c2b9e46c47e3b30dca3b0d447718，但UUID却并不适用于实际的业务需求。像用作订单号UUID这样的字符串没有丝毫的意义，看不出和订单相关的有用信息；而对于数据库来说用作业务主键ID，它不仅是太长还是字符串，存储性能差查询也很耗时，所以不推荐用作分布式ID

优点：

•  生成足够简单，本地生成无网络消耗，具有唯一性

缺点：

•  无序的字符串，不具备趋势自增特性
•  没有具体的业务含义
•  长度过长16 字节128位，36位长度的字符串，存储以及查询对MySQL的性能消耗较大，MySQL官方明确建议主键要尽量越短越好，作为数据库主键 UUID 的无序性会导致数据位置频繁变动，严重影响性能。

2、基于数据库自增ID

基于数据库的auto_increment自增ID完全可以充当分布式ID，具体实现：需要一个单独的MySQL实例用来生成ID，建表结构如下：
 

前两天公众号有个粉丝给我留言吐槽最近面试：“四哥，年前我在公司受点委屈一冲动就裸辞了，然后现在疫情严重两个多月还没找到工作，接了几个视频面试也都没下文。好多面试官问完一个问题，紧接着说还会其他解决方法吗？能干活解决bug不就行了吗？那还得会多少种方法？”

面试官应该是对应聘者的回答不太满意，他想听到一个他认为最优的解决方案，其实这无可厚非。同样一个bug，能用一行代码解决问题的人和用十行代码解决问题的人，你会选哪个入职？显而易见的事情！所以看待问题还是要从多个角度出发，每种方法都有各自的利弊。

一、为什么要用分布式ID？

在说分布式ID的具体实现之前，我们来简单分析一下为什么用分布式ID？分布式ID应该满足哪些特征？

1、什么是分布式ID？

拿MySQL数据库举个栗子：

在我们业务数据量不大的时候，单库单表完全可以支撑现有业务，数据再大一点搞个MySQL主从同步读写分离也能对付。

但随着数据日渐增长，主从同步也扛不住了，就需要对数据库进行分库分表，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求；特别一点的如订单、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。

2、那么分布式ID需要满足那些条件？

•  全局唯一：必须保证ID是全局性唯一的，基本要求
•  高性能：高可用低延时，ID生成响应要块，否则反倒会成为业务瓶颈
•  高可用：100%的可用性是骗人的，但是也要无限接近于100%的可用性
•  好接入：要秉着拿来即用的设计原则，在系统设计和实现上要尽可能的简单
•  趋势递增：最好趋势递增，这个要求就得看具体业务场景了，一般不严格要求

二、 分布式ID都有哪些生成方式？

今天主要分析一下以下9种，分布式ID生成器方式以及优缺点：

•  UUID
•  数据库自增ID
•  数据库多主模式
•  号段模式
•  Redis
•  雪花算法（SnowFlake）
•  滴滴出品（TinyID）
•  百度 （Uidgenerator）
•  美团（Leaf）

那么它们都是如何实现？以及各自有什么优缺点？我们往下看

（编辑：南昌站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!