在分布式里面,数据库的自增ID机制的主要原理是:数据库自增ID和mysql数据库的replace_into()函数实现的。这里的replace数据库自增ID和mysql数据库的replace_into()函数实现的。这里的replace into跟insert功能相似,不一样点在于:replace into首先尝试插入数据列表中,若是发现表中已经有此行数据(根据主键或惟一索引判断)则先删除,再插入。不然直接插入新数据。html
首先表结构以下所示mysql
create table t_test(
id bigint(20) unsigned not null auto_increment PRIMARY KEY,
stub char(1) not null default '',
unique key stub (stub)
)
复制代码
而后咱们插入的sql语句和查询的语句以下所示算法
replace into t_test (stub) values('b');
select last_insert_id();
复制代码
此时能够看到看到咱们刚刚插入的id值是1 sql
既然是分布式id,那么最少要使用两个数据库,这里咱们使用3台来说解,为了保证每一台数据库里面的id自增的时候不会重复,那么咱们就要给每一台数据库设置auto-increment-increment和auto-increment-offset这两个属性值(auto-increment-increment表示每一台数据库的起始id值,而后auto-increment-offset表示每一台数据库每一次的增长数字),设置值以下所示数据库
Server1:
auto-increment-increment = 1
auto-increment-offset = 3
Server2:
auto-increment-increment = 2
auto-increment-offset = 3
Server2:
auto-increment-increment = 3
auto-increment-offset = 3
复制代码
那么若是咱们有n台数据库的话,那么上面的auto-increment-increment和auto-increment-offset这两个属性值应该怎么设计呢,咱们给每一台数据库设置初始值分别为1,2,3...N,而后每一台数据库自增步长为机器的台数N,以下图所示 segmentfault
那数据库自增ID机制适合做分布式ID吗?答案是不太适合,为何呢,我总结了下面两个缘由:并发
1:系统水平扩展比较困难,好比定义好了步长和机器台数以后,若是要添加机器该怎么作?假设如今只有一台机器发号是1,2,3,4,5(步长是1),这个时候须要扩容机器一台。能够这样作:把第二台机器的初始值设置得比第一台超过不少,好比14(注意这里设置14的前提是:在扩容期间第一台机器的ID不可能增长到14),同时设置步长为2,那么这台机器下发的号码都是14之后的偶数。而后把第一台机器的ID值保留为奇数,好比7,而后修改第一台的步长为2。让它符合咱们定义的号段标准。扩容方案看起来复杂吗?貌似还好,如今想象一下若是咱们线上有100台机器,这个时候要扩容该怎么作?简直是噩梦。因此系统水平扩展方案复杂难以实现。 2:数据库压力仍是很大,每次获取ID都得读写一次数据库,很是影响性能,不符合分布式ID里面的延迟低和要高QPS的规则(在高并发下,若是都去数据库里面获取id,那是很是影响性能的)分布式
原文连接函数
其余分布式ID系列快捷键:高并发
分布式ID系列(1)——为何须要分布式ID以及分布式ID的业务需求
分布式ID系列(3)——数据库自增ID机制适合作分布式ID吗
分布式ID系列(4)——Redis集群实现的分布式ID适合作分布式ID吗
分布式ID系列(5)——Twitter的雪法算法Snowflake适合作分布式ID吗
大佬网址