高并发分布式系统如何做到唯一Id
又一个多月没冒泡了,其实最近学了些东西,但是没有安排时间整理成博文,后续再奉上。最近还写了一个发邮件的组件以及性能测试请看 《NET开发邮件发送功能的全面教程(含邮件组件源码)》 ,还弄了个MSSQL参数化语法生成器,会在9月整理出来,有兴趣的园友可以关注下我的博客。
分享原由,最近公司用到,并且在找最合适的方案,希望大家多参与讨论和提出新方案。我和我的小伙伴们也讨论了这个主题,我受益匪浅啊……
博文示例:
今天分享的主题是:如何在高并发分布式系统中生成全局唯一Id。
但这篇博文实际上是“半分享半讨论”的博文:
1) 半分享是我将说下我所了解到的关于今天主题所涉及的几种方案。
2) 半讨论是我希望大家对各个方案都说说自己的见解,更加希望大家能提出更好的方案。(我还另外提问在此:http://q.cnblogs.com/q/53552/上面已有几位园友回复(感谢dudu站长的参与),若你们有见解和新方案就在本博文留言吧,方便我整理更新到博文中,谢谢!)
我了解的方案如下……………………………………………………………………
1、 使用数据库自增Id
优势:编码简单,无需考虑记录唯一标识的问题。
缺陷:
1) 在大表做水平分表时,就不能使用自增Id,因为Insert的记录插入到哪个分表依分表规则判定决定,若是自增Id,各个分表中Id就会重复,在做查询、删除时就会有异常。
2) 在对表进行高并发单记录插入时需要加入事物机制,否则会出现Id重复的问题。
3) 在业务上操作父、子表(即关联表)插入时,需要在插入数据库之前获取max(id)用于标识父表和子表关系,若存在并发获取max(id)的情况,max(id)会同时被别的线程获取到。
4) 等等。
结论:适合小应用,无需分表,没有高并发性能要求。
2、 单独开一个数据库,获取全局唯一的自增序列号或各表的MaxId
1) 使用自增序列号表
专门一个数据库,生成序列号。开启事物,每次操作插入时,先将数据插入到序列表并返回自增序列号用于做为唯一Id进行业务数据插入。
注意:需要定期清理序列表的数据以保证获取序列号的效率;插入序列表记录时要开启事物。
使用此方案的问题是:每次的查询序列号是一个性能损耗;如果这个序列号列暴了,那就杯具了,你不知道哪个表使用了哪个序列,所以就必须换另一种唯一Id方式如GUID。
2) 使用MaxId表存储各表的MaxId值
专门一个数据库,记录各个表的MaxId值,建一个存储过程来取Id,逻辑大致为:开启事物,对于在表中不存在记录,直接返回一个默认值为1的键值,同时插入该条记录到table_key表中。而对于已存在的记录,key值直接在原来的key基础上加1更新到MaxId表中并返回key。
使用此方案的问题是:每次的查询MaxId是一个性能损耗;不过不会像自增序列表那么容易列暴掉,因为是摆表进行划分的。
详细可参考:《使用MaxId表存储各表的MaxId值,以获取全局唯一Id》
我截取此文中的sql语法如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
第一步:创建表 create table table_key ( table_name varchar (50) not null primary key , key_value int not null ) 第二步:创建存储过程来取自增ID create procedure up_get_table_key ( @table_name varchar (50), @key_value int output ) as begin begin tran declare @ key int --initialize the key with 1 set @ key =1 --whether the specified table is exist if not exists( select table_name from table_key where table_name=@table_name) begin insert into table_key values (@table_name,@ key ) --default key vlaue:1 end -- step increase else begin select @ key =key_value from table_key with (nolock) where table_name=@table_name set @ key =@ key +1 --update the key value by table name update table_key set key_value=@ key where table_name=@table_name end --set ouput value set @key_value=@ key --commit tran commit tran if @@error>0 rollback tran end |
感谢园友的好建议:
- (@辉_辉)建议给table_key中为每个表初始化一条key为1的记录,这样就不用每次if来判断了。
- (@乐活的CodeMonkey)建议给存储过程中数据库事物隔离级别提高一下,因为出现在CS代码层上使用如下事物代码会导致并发重复问题.
1
2
3
4
5
6
7
8
|
TransactionOptions option = new TransactionOptions(); option.IsolationLevel = IsolationLevel.ReadUncommitted; option.Timeout = new TimeSpan(0, 10, 0); using (TransactionScope transaction = new TransactionScope(TransactionScopeOption.RequiresNew, option)) { //调用存储过程 } |
在咨询过DBA后,这个存储过程提高数据库隔离级别会加大数据库访问压力,导致响应超时问题。所以这个建议我们只能在代码编写宣导上做。
- (@土豆烤肉)存储过程中不使用事物,一旦使用到事物性能就急剧下滑。直接使用UPDATE获取到的更新锁,即SQL SERVER会保证UPDATE的顺序执行。(已在用户过千万的并发系统中使用)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
create procedure [dbo].[up_get_table_key] ( @table_name varchar (50), @key_value int output ) as begin SET NOCOUNT ON ; DECLARE @maxId INT UPDATE table_key SET @maxId = key_value,key_value = key_value + 1 WHERE table_name=@table_name SELECT @maxId end |
结论:适用中型应用,此方案解决了分表,关联表插入记录的问题。但是无法满足高并发性能要求。同时也存在单点问题,如果这个数据库cash掉的话……
我们目前正头痛这个问题,因为我们的高并发常常出现数据库访问超时,瓶颈就在这个MaxId表。我们也有考虑使用分布式缓存(eg:memcached)缓存第一次访问MaxId表数据,以提高再次访问速度,并定时用缓存数据更新一次MaxId表,但我们担心的问题是:
a) 倘若缓存失效或暴掉了,那缓存的MaxId没有更新到数据库导致数据丢失,必须停掉站点来执行Select max(id)各个表来同步MaxId表。
b) 分布式缓存不是一保存下去,其他服务器上就立马可以获取到的,即数据存在不确定性。(其实也是缓存的一个误用,缓存应该用来存的是频繁访问并且很少改动的内容)
改进方案:
整体思想:建立两台以上的数据库ID生成服务器,每个服务器都有一张记录各表当前ID的MaxId表,但是MaxId表中Id的增长步长是服务器的数量,起始值依次错开,这样相当于把ID的生成散列到每个服务器节点上。例如:如果我们设置两台数据库ID生成服务器,那么就让一台的MaxId表的Id起始值为1(或当前最大Id+1),每次增长步长为2,另一台的MaxId表的ID起始值为2(或当前最大Id+2),每次步长也为2。这样就将产生ID的压力均匀分散到两台服务器上,同时配合应用程序控制,当一个服务器失效后,系统能自动切换到另一个服务器上获取ID,从而解决的单点问题保证了系统的容错。(Flickr思想)
但是要注意:1、多服务器就必须面临负载均衡的问题;2、倘若添加新节点,需要对原有数据重新根据步长计算迁移数据。
结论:适合大型应用,生成Id较短,友好性比较好。(强烈推荐)
3、 Sequence特性
这个特性在SQL Server 2012、Oracle中可用。这个特性是数据库级别的,允许在多个表之间共享序列号。它可以解决分表在同一个数据库的情况,但倘若分表放在不同数据库,那将共享不到此序列号。(eg:Sequence使用场景:你需要在多个表之间公用一个流水号。以往的做法是额外建立一个表,然后存储流水号)
相关Sequence特性资料:
SQL Server2012中的SequenceNumber尝试
SQL Server 2012 开发新功能——序列对象(Sequence)
Difference between Identity and Sequence in SQL Server 2012
结论:适用中型应用,此方案不能完全解决分表问题,而且无法满足高并发性能要求。同时也存在单点问题,如果这个数据库cash掉的话……
4、 通过数据库集群编号+集群内的自增类型两个字段共同组成唯一主键
优点:实现简单,维护也比较简单。
缺点:关联表操作相对比较复杂,需要两个字段。并且业务逻辑必须是一开始就设计为处理复合主键的逻辑,倘若是到了后期,由单主键转为复合主键那改动成本就太大了。
结论:适合大型应用,但需要业务逻辑配合处理复合主键。
5、 通过设置每个集群中自增 ID 起始点(auto_increment_offset),将各个集群的ID进行绝对的分段来实现全局唯一。当遇到某个集群数据增长过快后,通过命令调整下一个 ID 起始位置跳过可能存在的冲突。
优点:实现简单,且比较容易根据 ID 大小直接判断出数据处在哪个集群,对应用透明。缺点:维护相对较复杂,需要高度关注各个集群 ID 增长状况。
结论:适合大型应用,但需要高度关注各个集群 ID 增长状况。
6、 GUID(Globally Unique Identifier,全局唯一标识符)
GUID通常表示成32个16进制数字(0-9,A-F)组成的字符串,如:{21EC2020-3AEA-1069-A2DD-08002B30309D},它实质上是一个128位长的二进制整数。
GUID制定的算法中使用到用户的网卡MAC地址,以保证在计算机集群中生成唯一GUID;在相同计算机上随机生成两个相同GUID的可能性是非常小的,但并不为0。所以,用于生成GUID的算法通常都加入了非随机的参数(如时间),以保证这种重复的情况不会发生。
优点:GUID是最简单的方案,跨平台,跨语言,跨业务逻辑,全局唯一的Id,数据间同步、迁移都能简单实现。
缺点:
1) 存储占了32位,且无可读性,返回GUID给客户显得很不专业;
2) 占用了珍贵的聚集索引,一般我们不会根据GUID去查单据,并且插入时因为GUID是无需的,在聚集索引的排序规则下可能移动大量的记录。
有两位园友主推GUID,无须顺序GUID方案原因如下:
@徐少侠 GUID无序在并发下效率高,并且一个数据页内添加新行,是在B树内增加,本质没有什么数据被移动,唯一可能的,是页填充因子满了,需要拆页。而GUID方案导致的拆页比顺序ID要低太多了(数据库不是很懂,暂时无法断定,大家自己认识)
@无色 我们要明白id是什么,是身份标识,标识身份是id最大的业务逻辑,不要引入什么时间,什么用户业务逻辑,那是另外一个字段干的事,使用base64(guid,uuid),是通盘考虑,完全可以更好的兼容nosql,key-value存储。
(推荐),但是倘若你系统一开始没有规划一个业务Id,那么将导致大量的改动,所以这个方案的最佳状态是一开始就设计业务Id,当然业务Id的唯一性也是我们要考虑的。
结论:适合大型应用;生成的Id不够友好;占据了32位;索引效率较低。
改进:
1) (@dudu提点)在SQL Server 2005中新增了NEWSEQUENTIALID函数。
详细请看:《理解newid()和newsequentialid()》
在指定计算机上创建大于先前通过该函数生成的任何 GUID 的 GUID。 newsequentialid 产生的新的值是有规律的,则索引B+树的变化是有规律的,就不会导致索引列插入时移动大量记录的问题。
但一旦服务器重新启动,其再次生成的GUID可能反而变小(但仍然保持唯一)。这在很大程度上提高了索引的性能,但并不能保证所生成的GUID一直增大。SQL的这个函数产生的GUID很简单就可以预测,因此不适合用于安全目的。
a) 只能做为数据库列的DEFAULT VALUE,不能执行类似SELECT NEWSEQUENTIALID()的语句.
b) 如何获得生成的GUID.
如果生成的GUID所在字段做为外键要被其他表使用,我们就需要得到这个生成的值。通常,PK是一个IDENTITY字段,我们可以在INSERT之后执行 SELECT SCOPE_IDENTITY()来获得新生成的ID,但是由于NEWSEQUENTIALID()不是一个INDETITY类型,这个办法是做不到了,而他本身又只能在默认值中使用,不可以事先SELECT好再插入,那么我们如何得到呢?有以下两种方法:
1
2
3
4
5
6
7
8
9
10
11
12
|
--1. 定义临时表变量 DECLARE @outputTable TABLE (ID uniqueidentifier) INSERT INTO TABLE1(col1, col2) OUTPUT INSERTED.ID INTO @outputTable VALUES ( 'value1' , 'value2' ) SELECT ID FROM @outputTable --2. 标记ID字段为ROWGUID(一个表只能有一个ROWGUID) INSERT INTO TABLE1(col1, col2) VALUES ( 'value1' , 'value2' ) --在这里,ROWGUIDCOL其实相当于一个别名 SELECT ROWGUIDCOL FROM TABLE1 |
结论:适合大型应用,解决了GUID无序特性导致索引列插入移动大量记录的问题。但是在关联表插入时需要返回数据库中生成的GUID;生成的Id不够友好;占据了32位。
2) “COMB”(combined guid/timestamp,意思是:组合GUID/时间截)
(感谢:@ ethan-luo ,@lcs-帅 )
COMB数据类型的基本设计思路是这样的:既然GUID数据因毫无规律可言造成索引效率低下,影响了系统的性能,那么能不能通过组合的方式,保留GUID的10个字节,用另6个字节表示GUID生成的时间(DateTime),这样我们将时间信息与GUID组合起来,在保留GUID的唯一性的同时增加了有序性,以此来提高索引效率。
在NHibernate中,COMB型主键的生成代码如下所示:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
/// <summary> /// Generate a new <see cref="Guid"/> using the comb algorithm. /// </summary> private Guid GenerateComb() { byte [] guidArray = Guid.NewGuid().ToByteArray(); DateTime baseDate = new DateTime(1900, 1, 1); DateTime now = DateTime.Now; // Get the days and milliseconds which will be used to build //the byte string TimeSpan days = new TimeSpan(now.Ticks - baseDate.Ticks); TimeSpan msecs = now.TimeOfDay; // Convert to a byte array // Note that SQL Server is accurate to 1/300th of a // millisecond so we divide by 3.333333 byte [] daysArray = BitConverter.GetBytes(days.Days); byte [] msecsArray = BitConverter.GetBytes(( long ) (msecs.TotalMilliseconds / 3.333333)); // Reverse the bytes to match SQL Servers ordering Array.Reverse(daysArray); Array.Reverse(msecsArray); // Copy the bytes into the guid Array.Copy(daysArray, daysArray.Length - 2, guidArray, guidArray.Length - 6, 2); Array.Copy(msecsArray, msecsArray.Length - 4, guidArray, guidArray.Length - 4, 4); return new Guid(guidArray); } |
结论:适合大型应用。即保留GUID的唯一性的同时增加了GUID有序性,提高了索引效率;解决了关联表业务问题;生成的Id不够友好;占据了32位。(强烈推荐)
3) 长度问题,使用Base64或Ascii85编码解决。(要注意的是上述有序性方案在进行编码后也会变得无序)
如:
GUID:{3F2504E0-4F89-11D3-9A0C-0305E82C3301}
当需要使用更少的字符表示GUID时,可能会使用Base64或Ascii85编码。Base64编码的GUID有22-24个字符,如:
7QDBkvCA1+B9K/U0vrQx1A
7QDBkvCA1+B9K/U0vrQx1A==
Ascii85编码后是20个字符,如:
5:$Hj:Pf\4RLB9%kU\Lj
代码如:
Guid guid = Guid.NewGuid();
byte[] buffer = guid.ToByteArray();
var shortGuid = Convert.ToBase64String(buffer);
结论:适合大型应用,缩短GUID的长度。生成的Id不够友好;索引效率较低。
7、 GUID TO Int64
对于GUID的可读性,有园友给出如下方案:(感谢:@黑色的羽翼)
1
2
3
4
5
6
7
8
|
/// <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: 5717212979449746068 (友好性还行)
不过我的小伙伴说ToInt64后就不唯一了。因此我专门写了个并发测试程序,后文将给出测试结果截图及代码简单说明。
(唯一性、业务适合性是可以权衡的,这个唯一性肯定比不过GUID的,一般程序上都会安排错误处理机制,比如异常后执行一次重插的方案……)
结论:适合大型应用,生成相对友好的Id(纯数字)------因简单和业务友好性而推荐。
8、 自己写编码规则
优点:全局唯一Id,符合业务后续长远的发展(可能具体业务需要自己的编码规则等等)。
缺陷:根据具体编码规则实现而不同;还要考虑倘若主键在业务上允许改变的,会带来外键同步的麻烦。
我这边写两个编码规则方案:(可能不唯一,只是个人方案,也请大家提出自己的编码规则)
1) 12位年月日时分秒+5位随机码+3位服务器编码 (这样就完全单机完成生成全局唯一编码)---共20位
缺陷:因为附带随机码,所以编码缺少一定的顺序感。(生成高唯一性随机码的方案稍后给给出程序)
2) 12位年月日时分秒+5位流水码+3位服务器编码 (这样流水码就需要结合数据库和缓存)---共20位 (将影响顺序权重大的“流水码”放前面,影响顺序权重小的服务器编码放后)
缺陷:因为使用到流水码,流水码的生成必然会遇到和MaxId、序列表、Sequence方案中类似的问题
(为什么没有毫秒?毫秒也不具备业务可读性,我改用5位随机码、流水码代替,推测1秒内应该不会下99999[五位]条语法)
结论:适合大型应用,从业务上来说,有一个规则的编码能体现产品的专业成度。(强烈推荐)
GUID生成Int64值后是否还具有唯一性测试
测试环境
主要测试思路:
- 根据内核数使用多线程并发生成Guid后再转为Int64位值,放入集合A、B、…N,多少个线程就有多少个集合。
- 再使用Dictionary字典高效查key的特性,将步骤1中生成的多个集合全部加到Dictionary中,看是否有重复值。
示例注解:测了 Dictionary<long,bool> 最大容量就在5999470左右,所以每次并发生成的唯一值总数控制在此范围内,让测试达到最有效话。
主要代码:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
for ( int i = 0; i <= Environment.ProcessorCount - 1; i++) { ThreadPool.QueueUserWorkItem( (list) => { List< long > tempList = list as List< long >; for ( int j = 1; j < listLength; j++) { byte [] buffer = Guid.NewGuid().ToByteArray(); tempList.Add(BitConverter.ToInt64(buffer, 0)); } barrier.SignalAndWait(); }, totalList[i]); } |
测试数据截图:
数据一(循环1000次,测试数:1000*5999470)
数据二(循环5000次,测试数:5000*5999470)--跑了一个晚上……
感谢@Justany_WhiteSnow的专业回答:(大家分析下,我数学比较差,稍后再说自己的理解)
GUID桶数量:(2 ^ 4) ^ 32 = 2 ^ 128
Int64桶数量: 2 ^ 64
倘若每个桶的机会是均等的,则每个桶的GUID数量为:
(2 ^ 128) / (2 ^ 64) = 2 ^ 64 = 18446744073709551616
也就是说,其实重复的机会是有的,只是概率问题。
楼主测试数是29997350000,发生重复的概率是:
1 - ((1 - (1 / (2 ^ 64))) ^ 29997350000) ≈ 1 - ((1 - 1 / (2 ^ 64)) ^ (2 ^ 32)) < 1 - 1 + 1 / (2 ^ 32) = 1 / (2 ^ 32) ≈ 2.3283064e-10
(唯一性、业务适合性是可以权衡的,这个唯一性肯定比不过GUID的,一般程序上都会安排错误处理机制,比如异常后执行一次重插的方案……)
(唯一性、业务适合性是可以权衡的,这个唯一性肯定比不过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()生成的唯一性较高。
一些精彩评论(部分更新到原博文对应的地方)
一、
数据库文件体积只是一个参考值,可水平扩展系统性能(如nosql,缓存系统)并不和文件体积有高指数的线性相关。
如taobao/qq的系统比拼byte系统慢,关键在于索引的命中率,缓存,系统的水平扩展。
如果数据库很少,你搞这么多byte能提高性能?
如果数据库很大,你搞这么多byte不兼容索引不兼容缓存,不是害自已吗?
如果数据库要求伸缩性,你搞这么多byte,需要不断改程序,不是自找苦吗?
如果数据库要求移植性,你搞这么多byte,移植起来不如重新设计,这是不是很多公司不断加班的原因?
不依赖于数据存储系统是分层设计思想的精华,实现战略性能最大化,而不是追求战术单机性能最大化。
不要迷信数据库性能,不要迷信三范式,不要使用外键,不要使用byte,不要使用自增id,不要使用存储过程,不要使用内部函数,不要使用非标准sql,存储系统只做存储系统的事。当出现系统性能时,如此设计的数据库可以更好的实现迁移数据库(如mysql->oracle),实现nosql改造((mongodb/hadoop),实现key-value缓存(redis,memcache)。
二、
很多程序员有对性能认识有误区,如使用存储过程代替正常程序,其实使用存储过程只是追求单服务器的高性能,当需要服务器水平扩展时,存储过程中的业务逻辑就是你的噩运。
三、
除数字日期,能用字符串存储的字段尽量使用字符串存储,不要为节省那不值钱的1个g的硬盘而使用类似字节之类的字段,进而大幅牺牲系统可伸缩性和可扩展性。
不要为了追求所谓的性能,引入byte,使用byte注定是短命和难于移植,想想为什么html,email一直流行,因为它们使用的是字符串表示法,只要有人类永远都能解析,如email把二进制转成base64存储。除了实时系统,视频外,建议使用字符串来存储数据,系统性能的关键在于分布式,在于水平扩展。
本次博文到此结束,希望大家对本次主题“如何在高并发分布式系统中生成全局唯一Id”多提出自己宝贵的意见。另外看着感觉舒服,还请多帮推荐…推荐……
高并发分布式系统如何做到唯一Id的更多相关文章
- PHP uniqid 高并发生成不重复唯一ID
http://www.51-n.com/t-4264-1-1.html PHP uniqid()函数可用于生成不重复的唯一标识符,该函数基于微秒级当前时间戳.在高并发或者间隔时长极短(如循环代码)的情 ...
- 如何在高并发分布式系统中生成全局唯一Id
月整理出来,有兴趣的园友可以关注下我的博客. 分享原由,最近公司用到,并且在找最合适的方案,希望大家多参与讨论和提出新方案.我和我的小伙伴们也讨论了这个主题,我受益匪浅啊…… 博文示例: 1. ...
- 如何在高并发分布式系统中生成全局唯一Id(转)
http://www.cnblogs.com/heyuquan/p/global-guid-identity-maxId.html 又一个多月没冒泡了,其实最近学了些东西,但是没有安排时间整理成博文, ...
- (转)如何在高并发分布式系统中生成全局唯一Id
又一个多月没冒泡了,其实最近学了些东西,但是没有安排时间整理成博文,后续再奉上.最近还写了一个发邮件的组件以及性能测试请看 <NET开发邮件发送功能的全面教程(含邮件组件源码)> ,还弄了 ...
- 高并发分布式系统中生成全局唯一(订单号)Id js返回上一页并刷新、返回上一页、自动刷新页面 父页面操作嵌套iframe子页面的HTML标签元素 .net判断System.Data.DataRow中是否包含某列 .Net使用system.Security.Cryptography.RNGCryptoServiceProvider类与System.Random类生成随机数
高并发分布式系统中生成全局唯一(订单号)Id 1.GUID数据因毫无规律可言造成索引效率低下,影响了系统的性能,那么通过组合的方式,保留GUID的10个字节,用另6个字节表示GUID生成的时间(D ...
- 多线程模式下高并发的环境中唯一确保单例模式---DLC双端锁
DLC双端锁,CAS,ABA问题 一.什么是DLC双端锁?有什么用处? 为了解决在多线程模式下,高并发的环境中,唯一确保单例模式只能生成一个实例 多线程环境中,单例模式会因为指令重排和线程竞争的原因会 ...
- 高并发分布式系统中生成全局唯一Id汇总
数据在分片时,典型的是分库分表,就有一个全局ID生成的问题.单纯的生成全局ID并不是什么难题,但是生成的ID通常要满足分片的一些要求: 1 不能有单点故障. 2 以时间为序,或者ID里包含时间 ...
- 分布式系统-主键唯一id,订单编号生成-雪花算法-SnowFlake
分布式系统下 我们每台设备(分布式系统-独立的应用空间-或者docker环境) * SnowFlake的优点是,整体上按照时间自增排序,并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作 ...
- 高并发情况下分布式全局ID
1.高并发情况下,生成分布式全局id策略2.利用全球唯一UUID生成订单号优缺点3.基于数据库自增或者序列生成订单号4.数据库集群如何考虑数据库自增唯一性5.基于Redis生成生成全局id策略6.Tw ...
随机推荐
- 理解和使用 Promise.all 和 Promise.race
一.Pomise.all的使用 Promise.all可以将多个Promise实例包装成一个新的Promise实例.同时,成功和失败的返回值是不同的,成功的时候返回的是一个结果数组,而失败的时候则返回 ...
- 2013夏,iDempiere来了 - v1.0c Installers (Devina LTS Release) 2013-06-27
怀揣着为中小企业量身定做一整套开源软件解决方案的梦想开始了一个网站的搭建.http://osssme.org/ iDempiere来了 - v1.0c Installers (Devina LTS R ...
- MySQL-sqlmap常用参数的中文解释
#HiRoot's BlogOptions(选项):--version 显示程序的版本号并退出-h, --help 显示此帮助消息并退出-v VERBOSE 详细级别:0-6(默认为1) Target ...
- PHP-PHP程序员的技术成长规划(By黑夜路人)
按照了解的很多PHP/LNMP程序员的发展轨迹,结合个人经验体会,抽象出很多程序员对未来的迷漫,特别对技术学习的盲目和慌乱,简单梳理了这个每个阶段PHP程序员的技术要求,来帮助很多PHP程序做对照设定 ...
- ajax 异步 通信 小例子 servlet与 jsp异步 post方法
post请求 url后面加参数 接收不到的,必须 放到send("use"=user)形式 还要加上 xhr.setRequestHeader("Content-Type ...
- Linux常用指令总结
概述 因为平时不是经常使用Linux系统,每次用到都需要重新温习一遍,这里对自己平时经常使用到的指令做个小结,方便后面直接查阅. 常用指令 登陆root指令 sudo su - 安装软件及卸载指令 d ...
- centos7(vmware install) 安装EMQ注意事项 ---控制台远程访问
若想远端访问控制台,需打开对于端口 TCP 服务端口占用 EMQ 2.0 消息服务器默认占用的 TCP 端口包括: 1883 MQTT 协议端口 8883 MQTT/SSL 端口 8083 MQTT/ ...
- swift -变量的定义与使用
使⽤用let来声明常量,使⽤用var来声明变量. ⼀一个常量的值在编译时并不须要获取,可是你仅仅能为它赋值⼀一次.也就是说你能够⽤用常量来表⽰示这样⼀一个值:你仅仅须要决定⼀一次,可是须要使⽤用非常多 ...
- linux 查看可执行文件动态链接库相关信息(转)
转自 http://blog.sina.com.cn/s/blog_67eb1f2f0100mgd8.html ldd <可执行文件名> 查看可执行文件链接了哪些 系统动态链 ...
- 阿里云ECS网站备案流程
首先登录阿里云账号-->点击选项卡中的备案专区-->开始备案选项卡-->增加网站 然后是一大堆信息核查,之后填写网站备案信息,这里注意,有个文件审批号的选项可以不填(选择“请选择”) ...