在服務(wù)器系統(tǒng)開發(fā)時(shí)，為了適應(yīng)數(shù)據(jù)大并發(fā)的請求，我們往往需要對數(shù)據(jù)進(jìn)行異步存儲，特別是在做分布式系統(tǒng)時(shí)，這個(gè)時(shí)候就不能等待插入數(shù)據(jù)庫返回了取自動(dòng)id了，而是需要在插入數(shù)據(jù)庫之前生成一個(gè)全局的唯一id，使用全局的唯一id，在游戲服務(wù)器中，全局唯一的id可以用于將來合服方便，不會出現(xiàn)鍵沖突。也可以將來在業(yè)務(wù)增長的情況下，實(shí)現(xiàn)分庫分表，比如某一個(gè)用戶的物品要放在同一個(gè)分片內(nèi)，而這個(gè)分片段可能是根據(jù)用戶id的范圍值來確定的，比如用戶id大于1000小于100000的用戶在一個(gè)分片內(nèi)。目前常用的有以下幾種：
1，Java 自帶的UUID.
UUID.randomUUID().toString()，可以通過服務(wù)程序本地產(chǎn)生，ID的生成不依賴數(shù)據(jù)庫的實(shí)現(xiàn)。
優(yōu)勢：
本地生成ID，不需要進(jìn)行遠(yuǎn)程調(diào)用。
全局唯一不重復(fù)。
水平擴(kuò)展能力非常好。
劣勢：
ID有128 bits,占用的空間較大，需要存成字符串類型，索引效率極低。
生成的ID中沒有帶Timestamp，無法保證趨勢遞增，數(shù)據(jù)庫分庫分表時(shí)不好依賴
2，基于Redis的incr方法
Redis本身是單線程操作的，而incr更保證了一種原子遞增的操作。而且支持設(shè)置遞增步長。
優(yōu)勢：
部署方便，使用簡單，只需要調(diào)用一個(gè)redis的api即可。
可以多個(gè)服務(wù)器共享一個(gè)redis服務(wù)，減少共享數(shù)據(jù)的開發(fā)時(shí)間。
Redis可以群集部署，解決單點(diǎn)故障的問題。
劣勢：
如果系統(tǒng)太龐大的話，n多個(gè)服務(wù)同時(shí)向redis請求，會造成性能瓶頸。
3，來自Flicker的解決方案
這個(gè)解決方法是基于數(shù)據(jù)庫自增id的，它使用一個(gè)單獨(dú)的數(shù)據(jù)庫專門用于生成id。詳細(xì)的大家可以網(wǎng)上找找，個(gè)人覺得使用挺麻煩的，不建議使用。
4，Twitter Snowflake
snowflake是twitter開源的分布式ID生成算法，其核心思想是：產(chǎn)生一個(gè)long型的ID，使用其中41bit作為毫秒數(shù)，10bit作為機(jī)器編號，12bit作為毫秒內(nèi)序列號。這個(gè)算法單機(jī)每秒內(nèi)理論上最多可以生成1000*(2^12)個(gè)，也就是大約400W的ID，完全能滿足業(yè)務(wù)的需求。
根據(jù)snowflake算法的思想，我們可以根據(jù)自己的業(yè)務(wù)場景，產(chǎn)生自己的全局唯一ID。因?yàn)镴ava中l(wèi)ong類型的長度是64bits，所以我們設(shè)計(jì)的ID需要控制在64bits。
優(yōu)點(diǎn)：高性能，低延遲；獨(dú)立的應(yīng)用；按時(shí)間有序。
缺點(diǎn)：需要獨(dú)立的開發(fā)和部署。
比如我們設(shè)計(jì)的ID包含以下信息：
| 41 bits: Timestamp | 3 bits: 區(qū)域 | 10 bits: 機(jī)器編號 | 10 bits: 序列號 |
產(chǎn)生唯一ID的Java代碼：
|
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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
/*** 自定義 ID 生成器* ID 生成規(guī)則: ID長達(dá) 64 bits** | 41 bits: Timestamp (毫秒) | 3 bits: 區(qū)域（機(jī)房） | 10 bits: 機(jī)器編號 | 10 bits: 序列號 |*/public class GameUUID{// 基準(zhǔn)時(shí)間private long twepoch = 1288834974657L; //Thu, 04 Nov 2010 01:42:54 GMT// 區(qū)域標(biāo)志位數(shù)private final static long regionIdBits = 3L;// 機(jī)器標(biāo)識位數(shù)private final static long workerIdBits = 10L;// 序列號識位數(shù)private final static long sequenceBits = 10L;// 區(qū)域標(biāo)志ID最大值private final static long maxRegionId = -1L ^ (-1L << regionIdBits);// 機(jī)器ID最大值private final static long maxWorkerId = -1L ^ (-1L << workerIdBits);// 序列號ID最大值private final static long sequenceMask = -1L ^ (-1L << sequenceBits);// 機(jī)器ID偏左移10位private final static long workerIdShift = sequenceBits;// 業(yè)務(wù)ID偏左移20位private final static long regionIdShift = sequenceBits + workerIdBits;// 時(shí)間毫秒左移23位private final static long timestampLeftShift = sequenceBits + workerIdBits + regionIdBits;private static long lastTimestamp = -1L;private long sequence = 0L;private final long workerId;private final long regionId;public GameUUID(long workerId, long regionId) {// 如果超出范圍就拋出異常if (workerId > maxWorkerId || workerId < 0) {throw new IllegalArgumentException("worker Id can't be greater than %d or less than 0");}if (regionId > maxRegionId || regionId < 0) {throw new IllegalArgumentException("datacenter Id can't be greater than %d or less than 0");}this.workerId = workerId;this.regionId = regionId;}public GameUUID(long workerId) {// 如果超出范圍就拋出異常if (workerId > maxWorkerId || workerId < 0) {throw new IllegalArgumentException("worker Id can't be greater than %d or less than 0");}this.workerId = workerId;this.regionId = 0;}public long generate() {return this.nextId(false, 0);}/*** 實(shí)際產(chǎn)生代碼的** @param isPadding* @param busId* @return*/private synchronized long nextId(boolean isPadding, long busId) {long timestamp = timeGen();long paddingnum = regionId;if (isPadding) {paddingnum = busId;}if (timestamp < lastTimestamp) {try {throw new Exception("Clock moved backwards. Refusing to generate id for " + (lastTimestamp - timestamp) + " milliseconds");} catch (Exception e) {e.printStackTrace();}}//如果上次生成時(shí)間和當(dāng)前時(shí)間相同,在同一毫秒內(nèi)if (lastTimestamp == timestamp) {//sequence自增，因?yàn)閟equence只有10bit，所以和sequenceMask相與一下，去掉高位sequence = (sequence + 1) & sequenceMask;//判斷是否溢出,也就是每毫秒內(nèi)超過1024，當(dāng)為1024時(shí)，與sequenceMask相與，sequence就等于0if (sequence == 0) {//自旋等待到下一毫秒timestamp = tailNextMillis(lastTimestamp);}} else {// 如果和上次生成時(shí)間不同,重置sequence，就是下一毫秒開始，sequence計(jì)數(shù)重新從0開始累加,// 為了保證尾數(shù)隨機(jī)性更大一些,最后一位設(shè)置一個(gè)隨機(jī)數(shù)sequence = new SecureRandom().nextInt(10);}lastTimestamp = timestamp;return ((timestamp - twepoch) << timestampLeftShift) | (paddingnum << regionIdShift) | (workerId << workerIdShift) | sequence;}// 防止產(chǎn)生的時(shí)間比之前的時(shí)間還要小（由于NTP回?fù)艿葐栴}）,保持增量的趨勢.private long tailNextMillis(final long lastTimestamp) {long timestamp = this.timeGen();while (timestamp <= lastTimestamp) {timestamp = this.timeGen();}return timestamp;}// 獲取當(dāng)前的時(shí)間戳protected long timeGen() {return System.currentTimeMillis();}} |
使用自定義的這種方法需要注意的幾點(diǎn)：
為了保持增長的趨勢，要避免有些服務(wù)器的時(shí)間早，有些服務(wù)器的時(shí)間晚，需要控制好所有服務(wù)器的時(shí)間，而且要避免NTP時(shí)間服務(wù)器回?fù)芊?wù)器的時(shí)間;在跨毫秒時(shí)，序列號總是歸0，會使得序列號為0的ID比較多，導(dǎo)致生成的ID取模后不均勻，所以序列號不是每次都?xì)w0，而是歸一個(gè)0到9的隨機(jī)數(shù)。
上面說的這幾種方式我們可以根據(jù)自己的需要去選擇。在游戲服務(wù)器開發(fā)中，根據(jù)自己的游戲類型選擇，比如手機(jī)游戲，可以使用簡單的redis方式，簡單不容易出錯(cuò)，由于這種游戲單服并發(fā)新建id量并不太大，完全可以滿足需要。而對于大型的世界游戲服務(wù)器，它本身就是以分布式為主的，所以可以使用snowflake的方式，上面的snowflake代碼只是一個(gè)例子，需要自己根據(jù)自己的需求去定制，所以有額外的開發(fā)量，而且要注意上述所說的注意事項(xiàng)。
以上所述是小編給大家介紹的基于Java代碼實(shí)現(xiàn)游戲服務(wù)器生成全局唯一ID的方法匯總，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時(shí)回復(fù)大家的。在此也非常感謝大家對服務(wù)器之家網(wǎng)站的支持！
原文鏈接：http://www.cnblogs.com/wgslucky/archive/2016/10/27/6006157.html
