建站
咨詢
售后
建站咨詢
新聞中心
在后端系統(tǒng)中，每條記錄都需要一個唯一的ID來進行標識。
淶水網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、APP開發(fā)、響應式網(wǎng)站等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)2013年至今到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設就選創(chuàng)新互聯(lián)。
雖然一開始聽起來可能很瑣碎，但在高度分布式的環(huán)境中生成全局唯一標識符實際上是一個具有挑戰(zhàn)性的任務。
在本文中，讓我們來看一下一些常見的已知ID生成算法。
Ticket 服務 - 集中式數(shù)據(jù)庫
使用自增功能生成ID
Ticket 服務解決方案利用 SQL 數(shù)據(jù)庫中的自增功能來生成唯一的ID。
使用集中式數(shù)據(jù)庫服務器，Web 服務器插入一個新記錄到數(shù)據(jù)庫中以生成一個自增的ID。
CREATE TABLE `ID` (
`id` bigint(20) unsigned NOT NULL auto_increment,
`stub` char(1) NOT NULL default '',
PRIMARY KEY (`id`),
UNIQUE KEY (stub)
);
REPLACE INTO ID (stub) VALUES ('a');
SELECT LAST_INSERT_ID();與使用 INSERT INTO 命令不同，我們可以使用 REPLACE INTO 命令來減少數(shù)據(jù)庫中的記錄數(shù)量。
REPLACE INTO 命令以原子方式原地更新單行，并獲取自增的主 ID，而無需創(chuàng)建新記錄。
優(yōu)點：
- 實現(xiàn)簡單
- 生成的ID是64位的
- ID是順序且可排序的
缺點：
- 只能使用1個表。多個表或數(shù)據(jù)庫將導致ID沖突
- 由于只使用了1個表，數(shù)據(jù)庫成為了單點故障
- 如果每秒的寫入數(shù)量巨大，將會有寫入瓶頸
Ticket 服務 - 集群式數(shù)據(jù)庫
使用輪詢路由請求
與使用一個數(shù)據(jù)庫不同，我們可以使用多個具有偏移量的數(shù)據(jù)庫，以避免單點故障和寫入瓶頸。
偏移量 用于防止ID沖突。每個數(shù)據(jù)庫通過 k，k 是正在使用的數(shù)據(jù)庫服務器數(shù)量，增加其ID。
如上所示，如果使用了三個數(shù)據(jù)庫，每次生成ID時，自增的ID增加3。
優(yōu)點：
- 相對容易實現(xiàn)
- 生成的ID是64位的
- 能夠在沒有單點故障的情況下處理高吞吐量
缺點：
- 由于使用了多個數(shù)據(jù)庫，生成的ID不能保證是可排序的
- 難以水平擴展。添加新數(shù)據(jù)庫很棘手，因為它會影響偏移量。
Twitter Snowflake
Snowflake方法在不依賴數(shù)據(jù)庫的情況下生成 64位的ID。
64位的ID被分成5個主要部分
ID分為5個主要部分：
- 時間戳（41位）
- 數(shù)據(jù)中心ID（5位）
- 機器ID（5位）
- 序列號（12位）
- 符號位（1位）
時間戳。自紀元以來的毫秒數(shù)。41位大約會在70年內(nèi)溢出，對于大多數(shù)項目的壽命來說是安全的。
數(shù)據(jù)中心ID。服務器所在的數(shù)據(jù)中心。如果兩個服務器在相同的時間收到相同的請求，則可以防止ID沖突。
機器ID。機器的ID。如果兩臺服務器在相似的數(shù)據(jù)中心中的相同時間收到相同的請求，則可以防止沖突。
序列號。對于在同一服務器上生成的每個ID，序列號會遞增1，并在每毫秒重置為0。這可以防止在同一服務器上的ID沖突。
優(yōu)點：
- ID大致是有序的
- 能夠在沒有單點故障的情況下處理高吞吐量
- 能夠在機器之間無需協(xié)調(diào)地生成ID
- 能夠水平擴展。
缺點：
- ID不是完全有序的
- 未來的ID是可預測的。對于安全要求較高的應用程序可能不理想
- 需要一個Zookeeper來跟蹤機器ID。
MongoDB ObjectID
MongoDB為每個新文檔創(chuàng)建一個唯一的對象ID。
對象ID由 MongoDB驅(qū)動程序生成而不是數(shù)據(jù)庫。這意味著可以在服務器上生成對象ID，而不依賴于MongoDB數(shù)據(jù)庫。
MongoDB對象ID是一個96位的ID
與Snowflake方法類似，MongoDB對象ID分為4個部分。對象ID是一個96位的ID。
- 時間戳（32位）
- 機器ID（24位）
- 進程ID（16位）
- 計數(shù)器（24位）
大部分字段與Snowflake方法中提到的字段相似。
由于同一臺機器上可能運行多個線程或進程，因此進程ID可以區(qū)分在不同進程中由同一臺機器生成的對象ID。
優(yōu)點：
- 能夠在沒有單點故障的情況下處理高吞吐量
- 能夠在機器之間無需協(xié)調(diào)地生成ID
- 能夠水平擴展。
缺點：
- 依賴第三方數(shù)據(jù)庫解決方案
- ID的長度為96位，而不是64位，需要更多的存儲空間。
UUID（通用唯一標識符）
128位UUID的示例
通用唯一標識符是一個128位的數(shù)字，包括多個部分，例如時間、節(jié)點的MAC地址或MD5哈希的命名空間。
有一組標準化的算法用于生成UUID，多年來已經(jīng)發(fā)布了5個不同版本的UUID，以適應不同的需求。
這些算法相當冗長，因此我們不會詳細介紹它們。我們將更多地關注它的優(yōu)缺點。
優(yōu)點：
- 它是一個128位的ID，保證是唯一的
- 可以獨立生成，無需依賴任何第三方服務
- 它是隨機的和安全的。下一個ID是不可預測的。
缺點：
- 它很大，在MySQL中索引不佳
- 它不是有序的
結(jié)論
在分布式環(huán)境中實現(xiàn)高度可擴展和可用的ID生成器并不是微不足道的。
網(wǎng)頁標題：分布式系統(tǒng)中的唯一ID有哪些生成方式
文章鏈接：http://m.5511xx.com/article/cdhcejg.html
