基於Java程式碼實現遊戲伺服器生成全域性唯一ID的方法彙總

NO IMAGE

在伺服器系統開發時,為了適應資料大併發的請求,我們往往需要對資料進行非同步儲存,特別是在做分散式系統時,這個時候就不能等待插入資料庫返回了取自動id了,而是需要在插入資料庫之前生成一個全域性的唯一id,使用全域性的唯一id,在遊戲伺服器中,全域性唯一的id可以用於將來合服方便,不會出現鍵衝突。也可以將來在業務增長的情況下,實現分庫分表,比如某一個使用者的物品要放在同一個分片內,而這個分片段可能是根據使用者id的範圍值來確定的,比如使用者id大於1000小於100000的使用者在一個分片內。目前常用的有以下幾種:

1,Java 自帶的UUID.

UUID.randomUUID().toString(),可以通過服務程式本地產生,ID的生成不依賴資料庫的實現。

優勢:

本地生成ID,不需要進行遠端呼叫。

全域性唯一不重複。

水平擴充套件能力非常好。

劣勢:

ID有128 bits,佔用的空間較大,需要存成字串型別,索引效率極低。

生成的ID中沒有帶Timestamp,無法保證趨勢遞增,資料庫分庫分表時不好依賴

2,基於Redis的incr方法

Redis本身是單執行緒操作的,而incr更保證了一種原子遞增的操作。而且支援設定遞增步長。

優勢:

部署方便,使用簡單,只需要呼叫一個redis的api即可。

可以多個伺服器共享一個redis服務,減少共享資料的開發時間。

Redis可以群集部署,解決單點故障的問題。

劣勢:

如果系統太龐大的話,n多個服務同時向redis請求,會造成效能瓶頸。

3,來自Flicker的解決方案

這個解決方法是基於資料庫自增id的,它使用一個單獨的資料庫專門用於生成id。詳細的大家可以網上找找,個人覺得使用挺麻煩的,不建議使用。

4,Twitter Snowflake

snowflake是twitter開源的分散式ID生成演算法,其核心思想是:產生一個long型的ID,使用其中41bit作為毫秒數,10bit作為機器編號,12bit作為毫秒內序列號。這個演算法單機每秒內理論上最多可以生成1000*(2^12)個,也就是大約400W的ID,完全能滿足業務的需求。

根據snowflake演算法的思想,我們可以根據自己的業務場景,產生自己的全域性唯一ID。因為Java中long型別的長度是64bits,所以我們設計的ID需要控制在64bits。

優點:高效能,低延遲;獨立的應用;按時間有序。

缺點:需要獨立的開發和部署。

比如我們設計的ID包含以下資訊:

| 41 bits: Timestamp | 3 bits: 區域 | 10 bits: 機器編號 | 10 bits: 序列號 |

產生唯一ID的Java程式碼:


/**
* 自定義 ID 生成器
* ID 生成規則: ID長達 64 bits
*
* | 41 bits: Timestamp (毫秒) | 3 bits: 區域(機房) | 10 bits: 機器編號 | 10 bits: 序列號 |
*/
public class GameUUID{
// 基準時間
private long twepoch = 1288834974657L; //Thu, 04 Nov 2010 01:42:54 GMT
// 區域標誌位數
private final static long regionIdBits = 3L;
// 機器標識位數
private final static long workerIdBits = 10L;
// 序列號識位數
private final static long sequenceBits = 10L;
// 區域標誌ID最大值
private final static long maxRegionId = -1L ^ (-1L << regionIdBits);
// 機器ID最大值
private final static long maxWorkerId = -1L ^ (-1L << workerIdBits);
// 序列號ID最大值
private final static long sequenceMask = -1L ^ (-1L << sequenceBits);
// 機器ID偏左移10位
private final static long workerIdShift = sequenceBits;
// 業務ID偏左移20位
private final static long regionIdShift = sequenceBits   workerIdBits;
// 時間毫秒左移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);
}
/**
* 實際產生程式碼的
*
* @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();
}
}
//如果上次生成時間和當前時間相同,在同一毫秒內
if (lastTimestamp == timestamp) {
//sequence自增,因為sequence只有10bit,所以和sequenceMask相與一下,去掉高位
sequence = (sequence   1) & sequenceMask;
//判斷是否溢位,也就是每毫秒內超過1024,當為1024時,與sequenceMask相與,sequence就等於0
if (sequence == 0) {
//自旋等待到下一毫秒
timestamp = tailNextMillis(lastTimestamp);
}
} else {
// 如果和上次生成時間不同,重置sequence,就是下一毫秒開始,sequence計數重新從0開始累加,
// 為了保證尾數隨機性更大一些,最後一位設定一個隨機數
sequence = new SecureRandom().nextInt(10);
}
lastTimestamp = timestamp;
return ((timestamp - twepoch) << timestampLeftShift) | (paddingnum << regionIdShift) | (workerId << workerIdShift) | sequence;
}
// 防止產生的時間比之前的時間還要小(由於NTP回撥等問題),保持增量的趨勢.
private long tailNextMillis(final long lastTimestamp) {
long timestamp = this.timeGen();
while (timestamp <= lastTimestamp) {
timestamp = this.timeGen();
}
return timestamp;
}
// 獲取當前的時間戳
protected long timeGen() {
return System.currentTimeMillis();
}
}

使用自定義的這種方法需要注意的幾點:

為了保持增長的趨勢,要避免有些伺服器的時間早,有些伺服器的時間晚,需要控制好所有伺服器的時間,而且要避免NTP時間伺服器回撥伺服器的時間;在跨毫秒時,序列號總是歸0,會使得序列號為0的ID比較多,導致生成的ID取模後不均勻,所以序列號不是每次都歸0,而是歸一個0到9的隨機數。

上面說的這幾種方式我們可以根據自己的需要去選擇。在遊戲伺服器開發中,根據自己的遊戲型別選擇,比如手機遊戲,可以使用簡單的redis方式,簡單不容易出錯,由於這種遊戲單服併發新建id量並不太大,完全可以滿足需要。而對於大型的世界遊戲伺服器,它本身就是以分散式為主的,所以可以使用snowflake的方式,上面的snowflake程式碼只是一個例子,需要自己根據自己的需求去定製,所以有額外的開發量,而且要注意上述所說的注意事項。

以上所述是小編給大家介紹的基於Java程式碼實現遊戲伺服器生成全域性唯一ID的方法彙總,希望對大家有所幫助,如果大家有任何疑問請給我留言,小編會及時回覆大家的。在此也非常感謝大家對指令碼之家網站的支援!

您可能感興趣的文章:

Java遊戲俄羅斯方塊的實現例項java實現簡單的彈球遊戲java版實現2048遊戲功能java貪吃蛇遊戲編寫程式碼java版簡單的猜數字遊戲例項程式碼JAVA collection集合之撲克牌遊戲例項Java俄羅斯方塊小遊戲Java程式設計實現五子棋人人對戰程式碼示例