SQLServer數據庫中的分布式唯一ID是如何生成的以及生產方式是怎樣的

這期內容當中小編將會給大家帶來有關SQLServer數據庫中的分布式唯一ID是如何生成，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

當我們需要在多個數據庫間進行數據的復制自動增長型字段可能造成數據合并時的主鍵沖突。設想一個數據庫中的Order表向另一個庫中的Order表復制數據庫時，OrderID到底該不該自動增長呢？

數據庫自增長ID和無序的UUID方案的不足之處：

1）、采用數據庫自增序列：數據遷移合并等比較麻煩。

2)、UUID隨機數：采用無意義字符串，沒有排序UUID使用字符串形式存儲，數據量大時查詢效率比較低。（主要是索引查詢銷量不是最高的）

如果非要使用非自主增長列作為主鍵的話(分布式系統分庫分表中)，推使用有序UUID和有序的整長的Rowid(雪花算法snowflake和MongoDB之ObjectId)。

SQL Server分布式唯一ID生成實戰演練

唯一ID可以標識數據的唯一性，在分布式系統中生成唯一ID的方案有很多，常見的方式大概有以下三種：

2.1、依賴數據庫，使用SQL SERVER無序UUID和有序UUID。

1)、無序UUID：

SELECT newid() --生成36位的GUID

SELECT REPLACE(newid(), '-', '')  -- 生成32 位的GUID

2）、有序UUID：

SQLServer 2005已經解決了這個問題,使用的是NEWSEQUENTIALID()

create table jobs

(

id UNIQUEIDENTIFIER ROWGUIDCOL PRIMARY KEY  NOT NULL

CONSTRAINT [DF_jobs_id] DEFAULT (NEWSEQUENTIALID()),

account varchar(64) not null,

password varchar(64) not null

)

go

insert jobs (account,password) values ('tudou','123')

insert jobs (account,password) values ('ntudou','123')

insert jobs (account,password) values ('atudou','123')

insert jobs (account,password) values ('btudou','123')

insert jobs (account,password) values ('ctudou','123')

select * from jobs

參考資料：

SQL Server 的 主鍵 解決方案 NEWID() ， 自增ID - 王占波 - 博客園 https://www.cnblogs.com/wangzhanbo/articles/8807125.html

2.2、無序隨機UUID和有序UUID。

1)、無序UUID：

string guid = Guid.NewGuid().ToString();

string guid = Guid.NewGuid().ToString("N");

缺點：索引性能差。

2）、有序UUID：

C# 生成 UUID （有序GUID）Windows系統

https://www.cnblogs.com/lovewl2/p/10334987.html

C#根據時間產生有序的GUID編碼

https://www.cnblogs.com/shiningrise/p/5690016.html

.NET Core分布式唯一ID常見的幾種生成方式

唯一ID劃分需要根據單體應用還是分布式應用來進行區分。特別是在分布式系統中，有一些需要使用全局唯一ID的場景，這種時候為了防止ID沖突可以使用36位的UUID，但是UUID有一些缺點，首先他相對比較長，另外UUID一般是無序的。有些時候我們希望能使用一種簡單一些的ID，并且希望ID能夠按照時間有序生成。

1、基于時間戳+隨機數方式來生成唯一ID

基于時間戳：DateTime.Now.ToString("yyyyMMddHHmmssfffffff")—這種情況很容易出現重復的編號。

基于時間戳+隨機數:DateTime.Now.ToString("yyyyMMddHHmmssfffffff")+Random隨機數。

這種方式比較適合針對單體應用并發不高的業務系統，生成方式并不是嚴格意義上的唯一ID。

2、C#仿造Snowflake雪花算法設計

有這么一種說法，自然界中并不存在兩片完全一樣的雪花的。每一片雪花都擁有自己漂亮獨特的形狀、獨一無二。雪花算法也表示生成的ID如雪花般獨一無二。而twitter的snowflake解決了這種需求。 

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

關于雪花算法的組成部分：

雪花算法會生成一個64位的二進制數據，為一個Long型。(轉換成字符串后長度最多19位) ，其基本結構：

第一位：為未使用

第二部分：41位為毫秒級時間(41位的長度可以使用69年)

第三部分：5位datacenterId和5位workerId(10位的長度最多支持部署1024個節點）

第四部分：最后12位是毫秒內的計數（12位的計數順序號支持每個節點每毫秒產生4096個ID序號）

snowflake生成的ID整體上按照時間自增排序，并且整個分布式系統內不會產生ID碰撞（由datacenter和workerId作區分），并且效率較高。經測試snowflake每秒能夠產生26萬個ID。

C# 分布式自增ID算法snowflake（雪花算法） - 五維思考 - 博客園

https://www.cnblogs.com/zhaoshujie/p/12010052.html

3、C#仿造mongodb的分布式主鍵ObjectId設計

MongoDB中_id(ObjectId)組成的12個字節按照如下方式生成

前四位是時間戳，可以提供秒級別的唯一性。

接下來三位是所在主機的唯一標識符，通常是機器主機名的散列值。

接下來兩位是產生 ObjectId 的 PID，確保同一臺機器上并發產生的 ObjectId 是唯一的。

前九位保證了同一秒鐘不同機器的不同進程產生的 ObjectId 時唯一的。

最后三位是自增計數器，確保相同進程同一秒鐘產生的 ObjectId 是唯一的。

上述就是小編為大家分享的SQLServer數據庫中的分布式唯一ID是如何生成了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。