下次自动登录
现在的位置:
& 综合 & 正文
如何在高并发分布式系统中生成全局唯一Id
又一个多月没冒泡了，其实最近学了些东西，但是没有安排时间整理成博文，后续再奉上。最近还写了一个发邮件的组件以及性能测试会在这个月整理出来，还弄了个MSSQL参数化语法生成器，会在9月整理出来，有兴趣的园友可以关注下我的博客。
分享原由，最近公司用到，并且在找最合适的方案，希望大家多参与讨论和提出新方案。我和我的小伙伴们也讨论了这个主题，我受益匪浅啊……
今天分享的主题是：如何在高并发分布式系统中生成全局唯一Id。
但这篇博文实际上是“半分享半讨论”的博文：
半分享是我将说下我所了解到的关于今天主题所涉及的几种方案。
半讨论是我希望大家对各个方案都说说自己的见解，更加希望大家能提出更好的方案。
我了解的方案如下……………………………………………………………………
使用数据库自增Id
优势：编码简单，无需考虑记录唯一标识的问题。
在大表做水平分表时，就不能使用自增Id，因为Insert的记录插入到哪个分表依分表规则判定决定，若是自增Id，各个分表中Id就会重复，在做查询、删除时就会有异常。
在对表进行高并发单记录插入时需要加入事物机制，否则会出现Id重复的问题。
在业务上操作父、子表（即关联表）插入时，需要在插入数据库之前获取max(id)用于标识父表和子表关系，若存在并发获取max(id)的情况，max(id)会同时被别的线程获取到。
结论：适合小应用，无需分表，没有高并发性能要求。
单独开一个数据库，获取全局唯一的自增序列号或各表的MaxId
使用自增序列号表
专门一个数据库，生成序列号。开启事物，每次操作插入时，先将数据插入到序列表并返回自增序列号用于做为唯一Id进行业务数据插入。
注意：需要定期清理序列表的数据以保证获取序列号的效率；插入序列表记录时要开启事物。
使用此方案的问题是：每次的查询序列号是一个性能损耗；如果这个序列号列暴了，那就杯具了，你不知道哪个表使用了哪个序列，所以就必须换另一种唯一Id方式如GUID。
使用MaxId表存储各表的MaxId值
专门一个数据库，记录各个表的MaxId值，建一个存储过程来取Id，逻辑大致为：开启事物，对于在表中不存在记录，直接返回一个默认值为1的键值，同时插入该条记录到table_key表中。而对于已存在的记录，key值直接在原来的key基础上加1更新到MaxId表中并返回key。
使用此方案的问题是：每次的查询MaxId是一个性能损耗；不过不会像自增序列表那么容易列暴掉，因为是摆表进行划分的。
详细可参考：
我截取此文中的sql语法如下：
第一步：创建表
create table table_key
table_name
varchar(50)
not null primary key,
第二步：创建存储过程来取自增ID
create procedure up_get_table_key
@table_name
varchar(50),
@key_value
int output
begin tran
declare @key
--initialize the key with 1
set @key=1
--whether the specified table is exist
not exists(select table_namefrom table_key
where table_name=@table_name)
insert into table_keyvalues(@table_name,@key)
key vlaue:1
-- step increase
select @key=key_valuefrom table_key
with (nolock)
where table_name=@table_name
set @key=@key+1
--update the key value by table name
update table_keyset key_value=@key where table_name=@table_name
--set ouput value
set @key_value=@key
--commit tran
commit tran
if @@error&0
rollback tran
感谢园友的好建议：
（）建议给table_key中为每个表初始化一条key为1的记录，这样就不用每次if来判断了。
（）建议给存储过程中提高一下，因为出现在CS层上使用如下事物代码会导致并发重复问题.
TransactionOptions option =
new TransactionOptions();
option.IsolationLevel = IsolationLevel.ReadU
option.Timeout = new TimeSpan(0, 10, 0);
using (TransactionScope transaction =new TransactionScope(TransactionScopeOption.RequiresNew,
//调用存储过程
在咨询过DBA后，这个存储过程提高数据库隔离级别会加大数据库访问压力，导致响应超时问题。所以这个建议我们只能在代码编写宣导上做。
结论：适用中型应用，此方案解决了分表，关联表插入记录的问题。但是无法满足高并发性能要求。同时也存在单点问题，如果这个数据库cash掉的话……
我们目前正头痛这个问题，因为我们的高并发常常出现数据库访问超时，瓶颈就在这个MaxId表。我们也有考虑使用分布式缓存（eg：memcached）缓存第一次访问MaxId表数据，以提高再次访问速度，并定时用缓存数据更新一次MaxId表，但担心的问题是：倘若缓存失效或暴掉了，那缓存的MaxId没有更新到数据库导致数据丢失，必须停掉站点来执行Select
max(id)各个表来同步MaxId表。
网上找到的特别妙的改进方案，帅呆了……
整体思想：建立两台以上的数据库ID生成服务器，每个服务器都有一张记录各表当前ID的MaxId表，但是MaxId表中Id的增长步长是服务器的数量，起始值依次错开，这样相当于把ID的生成散列到每个服务器节点上。例如：如果我们设置两台数据库ID生成服务器，那么就让一台的MaxId表的Id起始值为1（或当前最大Id+1），每次增长步长为2，另一台的MaxId表的ID起始值为2（或当前最大Id+2），每次步长也为2。这样就将产生ID的压力均匀分散到两台服务器上，同时配合应用控制，当一个服务器失效后，系统能自动切换到另一个服务器上获取ID，从而解决的单点问题保证了系统的容错。（Flickr思想）
结论：适合大型应用，生成Id较短，友好性比较好。（强烈推荐）
Sequence特性
这个特性在SQL Server 2012、Oracle中可用。这个特性是数据库级别的，允许在多个表之间共享序列号。它可以解决分表在同一个数据库的情况，但倘若分表放在不同数据库，那将共享不到此序列号。（eg：Sequence使用场景：你需要在多个表之间公用一个流水号。以往的做法是额外建立一个表，然后存储流水号）
相关Sequence特性资料：
结论：适用中型应用，此方案不能完全解决分表问题，并且存在“单独开一个数据库，获取全局唯一的自增序列号或各表的MaxId”方案中不能解决的问题
通过数据库集群编号+集群内的自增类型两个字段共同组成唯一主键
优点：实现简单，维护也比较简单。
缺点：关联表操作相对比较复杂，需要两个字段。并且业务逻辑必须是一开始就设计为处理复合主键的逻辑，倘若是到了后期，由单主键转为复合主键那改动成本就太大了。
结论：适合大型应用，但需要业务逻辑配合处理复合主键。
通过设置每个集群中自增 ID 起始点（auto_increment_offset），将各个集群的ID进行绝对的分段来实现全局唯一。当遇到某个集群数据增长过快后，通过命令调整下一个 ID 起始位置跳过可能存在的冲突。
优点：实现简单，且比较容易根据 ID 大小直接判断出数据处在哪个集群，对应用透明。缺点：维护相对较复杂，需要高度关注各个集群 ID 增长状况。
结论：适合大型应用，但需要高度关注各个集群 ID 增长状况。
优点：GUID是最简单的方案，全局唯一的Id，数据间同步、迁移都能简单实现。
缺点：存储占了32位，且无可读性，返回GUID给客户显得很不专业；还占用了珍贵的聚集索引，一般我们不会根据GUID去查单据，并且插入时因为GUID是无需的，在聚集索引的排序规则下可能移动大量的记录。
结论：适合大型应用，生成的Id不够友好。（推荐）
改进：（建议）在SQL
Server 2005中新增了NEWSEQUENTIALID函数。
详细请看：
在指定计算机上创建大于先前通过该函数生成的任何 GUID 的 GUID。 newsequentialid 产生的新的值是有规律的，则索引B+树的变化是有规律的。就不会导致索引列插入移动大量记录的问题
只能做为数据库列的DEFAULT VALUE，不能执行类似SELECT NEWSEQUENTIALID()的语句.
只有当计算机有网卡时，生成的GUID才是全球唯一.
如何获得生成的GUID.
如果生成的GUID所在字段做为外键要被其他表使用，我们就需要得到这个生成的值
通常，PK是一个IDENTITY字段，我们可以在INSERT之后执行 SELECT SCOPE_IDENTITY()来获得新生成的ID
但是由于NEWSEQUENTIALID()不是一个INDETITY类型，这个办法是做不到了，而他本身又只能在默认值中使用，不可以事先SELECT好再插入，那么我们如何得到呢？有以下两种方法：
--1. 定义临时表变量
DECLARE @outputTableTABLE(ID uniqueidentifier)
INSERT INTO TABLE1(col1, col2)
OUTPUT INSERTED.IDINTO @outputTable
VALUES('value1','value2')
SELECT IDFROM @outputTable
--2. 标记ID字段为ROWGUID（一个表只能有一个ROWGUID）
INSERT INTO TABLE1(col1, col2)
VALUES('value1','value2')
--在这里，ROWGUIDCOL其实相当于一个别名
SELECT ROWGUIDCOLFROM TABLE1
结论：适合大型应用，并解决了GUID中无序导致索引列插入移动大量记录的问题。（推荐）
GUID TO Int64
对于GUID的可读性，有园友给出如下方案：（感谢：）
/// &summary&
/// 根据GUID获取19位的唯一数字序列
/// &/summary&
public static long GuidToLongID()
byte[] buffer = Guid.NewGuid().ToByteArray();
return BitConverter.ToInt64(buffer, 0);
即将GUID转为了19位数字，数字反馈给客户可以一定程度上缓解友好性问题。EG:
GUID: cfdab168-211d-41e6-8634-ef5ba6502a22
（不友好）
Int64: 9746068
（友好性还行）
不过我的小伙伴说ToInt64后就不唯一了。因此我专门写了个并发测试程序，后文将给出测试结果截图及代码简单说明。
（唯一性是可以权衡的，这个唯一性肯定比不过GUID的，一般程序上都会安排错误处理机制，比如异常后执行一次重插的方案……）
结论：适合大型应用，并且经我测试程序跑了一个晚上没有出现重复Id问题。（推荐）
自己写编码规则
优点：全局唯一Id，符合业务后续长远的发展（可能具体业务需要自己的编码规则等等）。
缺陷：根据具体编码规则实现而不同。
我这边写两个编码规则方案：（可能不唯一，只是个人方案，也请大家提出自己的编码规则）
12位年月日时分秒+3位服务器编码+3位表编码+5位随机码
（这样就完全单机完成生成全局唯一编码）---共23位
缺陷：因为附带随机码，所以编码缺少一定的顺序感。（生成高唯一性随机码的方案稍后给给出程序）
12位年月日时分秒+3位服务器编码+3位表编码+5位流水码
（这样流水码就需要结合数据库和缓存）---共23位
缺陷：因为使用到流水码，流水码的生成必然会遇到和MaxId、序列表、Sequence方案中类似的问题
（为什么没有毫秒？毫秒也不具备业务可读性，我改用5位随机码、流水码代替，推测1秒内应该不会下99999[五位]条语法）
结论：适合大型应用，从业务上来说，有一个规则的编码能体现产品的专业成度。（强烈推荐）
GUID生成Int64值后是否还具有唯一性测试
主要测试思路：
根据内核数使用多线程并发生成Guid后再转为Int64位值，放入集合A、B、…N，多少个线程就有多少个集合。
再使用Dictionary字典高效查key的特性，将步骤1中生成的多个集合全部加到Dictionary中，看是否有重复值。
示例注解：测了 Dictionary&long,bool& 最大容量就在5999470左右，所以每次并发生成的唯一值总数控制在此范围内，让测试达到最有效话。
主要代码：
for (int i = 0; i &= Environment.ProcessorCount - 1; i++)
ThreadPool.QueueUserWorkItem(
List&long& tempList = listas List&long&;
for (int j = 1; j & listL j++)
byte[] buffer = Guid.NewGuid().ToByteArray();
tempList.Add(BitConverter.ToInt64(buffer, 0));
barrier.SignalAndWait();
}, totalList[i]);
测试数据截图：
数据一（循环1000次）
数据二（循环5000次）--跑了一个晚上……
（唯一性是可以权衡的，这个唯一性肯定比不过GUID的，一般程序上都会安排错误处理机制，比如异常后执行一次重插的方案……）
结论：GUID转为Int64值后，也具有高唯一性，可以使用与项目中。
Random生成高唯一性随机码
我使用了五种Random生成方案，要Random生成唯一主要因素就是种子参数要唯一。（这是比较久以前写的测试案例了，一直找不到合适的博文放，今天终于找到合适的地方了）
不过该测试是在单线程下的，多线程应使用不同的Random实例，所以对结果影响不会太大。
使用Environment.TickCount做为Random参数（即Random的默认参数），重复性最大。
使用DateTime.Now.Ticks做为Random参数，存在重复。
使用unchecked((int)DateTime.Now.Ticks)做为Random参数，存在重复。
使用Guid.NewGuid().GetHashCode()做为random参数，测试不存在重复（或存在性极小）。
使用RNGCryptoServiceProvider做为random参数，测试不存在重复（或存在性极小）。
static int GetRandomSeed()
byte[] bytes = new byte[4];
System.Security.Cryptography.RNGCryptoServiceProvider rng
= new System.Security.Cryptography.RNGCryptoServiceProvider();
rng.GetBytes(bytes);
return BitConverter.ToInt32(bytes, 0);
测试结果：
结论：随机码使用RNGCryptoServiceProvider或Guid.NewGuid().GetHashCode()生成的唯一性较高。
&&&&推荐文章:
【上篇】【下篇】如何在高并发分布式系统中生成全局唯一Id_百度知道
如何在高并发分布式系统中生成全局唯一Id
提问者采纳
　　注意。而对于已存在的记录，直接返回一个默认值为1的键值：需要定期清理序列表的数据以保证获取序列号的效率，那就杯具了。　　详细可参考。　　使用此方案的问题是，所以就必须换另一种唯一Id方式如GUID。　　4)
等等，对于在表中不存在记录、删除时就会有异常，因为Insert的记录插入到哪个分表依分表规则判定决定。开启事物。祝你愉快。　　2，无需分表，逻辑大致为：　　1)
在大表做水平分表时　　我了解的方案如下……………………………………………………………………　　1：每次的查询序列号是一个性能损耗，因为是摆表进行划分的;0
rollback tranend　　转载仅供参考，各个分表中Id就会重复：每次的查询MaxId是一个性能损耗。　　2)
在对表进行高并发单记录插入时需要加入事物机制，生成序列号：《使用MaxId表存储各表的MaxId值、
单独开一个数据库，你不知道哪个表使用了哪个序列，max(id)会同时被别的线程获取到，无需考虑记录唯一标识的问题，key值直接在原来的key基础上加1更新到MaxId表中并返回key。　　结论，没有高并发性能要求，同时插入该条记录到table_key表中、子表（即关联表）插入时：创建表create table table_key(
table_name
varchar(50)not null primary key，否则会出现Id重复的问题。　　使用此方案的问题是，若是自增Id，记录各个表的MaxId值：适合小应用：编码简单、
使用数据库自增Id　　优势,
@key_value
int output)asbegin
begin tran
declare @key
--initialize the key with 1
set @key=1
--whether the specified table is exist
if not exists(selecttable_name from table_key wheretable_name=@table_name)
insert into table_keyvalues(@table_name:1
-- step increase
select @key=key_valuefrom table_key with (nolock) where table_name=@table_name
set @key=@key+1
--update the key value by table name
update table_key setkey_value=@key where table_name=@table_name
--set ouput value
set @key_value=@key
--commit tran
commit tran
if @@error&gt，以获取全局唯一Id》　　我截取此文中的sql语法如下，建一个存储过程来取Id，若存在并发获取max(id)的情况；不过不会像自增序列表那么容易列暴掉，先将数据插入到序列表并返回自增序列号用于做为唯一Id进行业务数据插入。　　缺陷；如果这个序列号列暴了，需要在插入数据库之前获取max(id)用于标识父表和子表关系：开启事物：　　　　第一步。　　3)
在业务上操作父：创建存储过程来取自增IDcreate procedure up_get_table_key(
@table_name
varchar(50)；插入序列表记录时要开启事物，每次操作插入时。　　2)
使用MaxId表存储各表的MaxId值　　专门一个数据库，在做查询,
not null)第二步，版权属于原作者，获取全局唯一的自增序列号或各表的MaxId　　1)
使用自增序列号表　　专门一个数据库,@key)
--default key vlaue，就不能使用自增Id
来自团队：
其他类似问题
为您推荐：
分布式系统的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁主题信息（必填）
主题描述（最多限制在50个字符）
申请人信息（必填）
申请信息已提交审核，请注意查收邮件，我们会尽快给您反馈。
如有疑问，请联系
如今的编程是一场程序员和上帝的竞赛，程序员要开发出更大更好、傻瓜都会用到软件。而上帝在努力创造出更大更傻的傻瓜。目前为止，上帝是赢的。个人网站：。个人QQ群：、
全栈攻城狮不知道是怎么炼成的
一只文艺范的软件攻城狮，Keep Learn，Always.
个人大数据技术博客：
人生得意须尽欢，莫使金樽空对月。}