sharding分表后主键_分布式中的分库分表之后，ID 主键如何处理？

本文已经收录自 JavaGuide (60k+ Star【Java学习+面试指南】 一份涵盖大部分Java程序员所需要掌握的核心知识。)

本文授权转载自：https://juejin.im/post/5d6fc8eff265da03ef7a324b ，作者：1点25。

ID是数据的唯一标识，传统的做法是利用UUID和数据库的自增ID，在互联网企业中，大部分公司使用的都是Mysql，并且因为需要事务支持，所以通常会使用Innodb存储引擎，UUID太长以及无序，所以并不适合在Innodb中来作为主键，自增ID比较合适，但是随着公司的业务发展，数据量将越来越大，需要对数据进行分表，而分表后，每个表中的数据都会按自己的节奏进行自增，很有可能出现ID冲突。这时就需要一个单独的机制来负责生成唯一ID，生成出来的ID也可以叫做分布式ID，或全局ID。下面来分析各个生成分布式ID的机制。

这篇文章并不会分析的特别详细，主要是做一些总结，以后再出一些详细某个方案的文章。

数据库自增ID

第一种方案仍然还是基于数据库的自增ID，需要单独使用一个数据库实例，在这个实例中新建一个单独的表：

表结构如下：

CREATE DATABASE `SEQID`;

CREATE TABLE SEQID.SEQUENCE_ID (

id bigint(20) unsigned NOT NULL auto_increment,

stub char(10) NOT NULL default '',

PRIMARY KEY (id),

UNIQUE KEY stub (stub)

) ENGINE=MyISAM;

可以使用下面的语句生成并获取到一个自增ID

begin;

replace into SEQUENCE_ID (stub) VALUES ('anyword');

select last_insert_id();

commit;

stub字段在这里并没有什么特殊的意义，只是为了方便的去插入数据，只有能插入数据才能产生自增id。而对于插入我们用的是replace，replace会先看是否存在stub指定值一样的数据，如果存在则先delete再insert，如果不存在则直接insert。

这种生成分布式ID的机制，需要一个单独的Mysql实例，虽然可行，但是基于性能与可靠性来考虑的话都不够，业务系统每次需要一个ID时，都需要请求数据库获取，性能低，并且如果此数据库实例下线了，那么将影响所有的业务系统。

为了解决数据库可靠性问题，我们可以使用第二种分布式ID