分布式id生成方案

分布式id生成方案

常见的分布式id方案

数据库自增主键

专门有一个数据库，数据库中搞一张表，专门用来进行生成主键id，进行insert一条数据，会返回给你一个主键，然后用这个主键作为数据的id进行插入的操作.
优点: 实现简单，落实方便 只需要一个数据库就可以进行实现
缺点: 单库单表，并发能力不高，不停往表里插入数据需要进行定时清理数据。

UUID

优点：本地生成，并发能力高，不依赖别的中间件
缺点：太长了，作为主键插入数据库的时候，会造成数据库的频繁分页的操作

Twitter开源的Snowflake方案

核心思想：64个bit位，41位放时间（最多使用69年），10位放机器标识（最多把snowflake程序部署在1024台机器上），12位放序号（每毫秒，每台机器，可以顺序生成4096个ID），最高位1个bit是0

snowflake程序分布式部署在多台机器上，每台机器生成的每个ID，都是这一毫秒、机器id、序号，每台机器每毫秒最多4096个ID，绝对够用了，分布式方案可以抗高并发，大不了加机器，最多1024台机器，纯基于内存生成，性能很高

优点：高性能，高并发，可伸缩
缺点：有时钟回拨的问题，需要进行独立部署和维护

Redis自增机制

redis的incrby 命令 redis 单线程 效率高
优点：redis 单线程 效率高 一般公司都会用redis
缺点：客户端需要自己进行封装 不易进行扩容，

基于时间+业务id

比方说 一些打车软件，可以使用时间戳+起点编号+车牌号 作为主键id 业务上就不会有重复的逻辑。
优点：实现简单，没有并发，扩容之类的问题
缺点：只能针对一些特定业务，别的一些业务可能就无法进行使用这个逻辑

flickr公司的方案

CREATE TABLE uid_sequence (
id bigint(20) unsigned NOT NULL auto_increment,
stub char(1) NOT NULL default ‘’,
PRIMARY KEY (id),
UNIQUE KEY stub (stub)
) ENGINE=MyISAM;

REPLACE INTO uid_sequence (stub) VALUES (‘test’);
SELECT LAST_INSERT_ID();
是用replace into 代替insert into 免表行数过大，一张表就一行数据，然后再select获取这个表的最新id，last_insert_id()函数是connection级别的，就你这个连接的最近insert生成的id，多个客户端之间没影响

美团开源的leaf框架

可以参考https://tech.meituan.com/2017/04/21/mt-leaf.html