資訊專欄INFORMATION COLUMN
摘要：為什么需要發(fā)號器在分布式系統(tǒng)中，經(jīng)常需要對大量的數(shù)據(jù)消息請求等進(jìn)行唯一標(biāo)識，例如對于分布式系統(tǒng)，服務(wù)間相互調(diào)用需要唯一標(biāo)識，調(diào)用鏈路分析，日志追蹤的時候需要使用這個唯一標(biāo)識。
原文鏈接：何曉東 博客
文章起源于 康神交流群的 panda大佬和boss li關(guān)于發(fā)號器的一些交流，特此感謝讓我們學(xué)到了新知識。為什么需要發(fā)號器
在分布式系統(tǒng)中，經(jīng)常需要對大量的數(shù)據(jù)、消息、http 請求等進(jìn)行唯一標(biāo)識，例如：對于分布式系統(tǒng)，服務(wù)間相互調(diào)用需要唯一標(biāo)識，調(diào)用鏈路分析，日志追蹤的時候需要使用這個唯一標(biāo)識。此時需要一個全局唯一的 ID。
需要什么樣子的發(fā)號器持久化
要滿足長期全局唯一，持久化是必須的，肯定不能讓已經(jīng)使用的再次產(chǎn)生一遍，同時需要強(qiáng)一致性?？捎眠x擇存儲在 Redis 或者 Etcd 中。
高可用
這個時候需要提供發(fā)號器服務(wù)的機(jī)器主從同步，能夠在主服務(wù)器宕機(jī)的時候，自動選擇從服務(wù)器，切換過程中，發(fā)號器生成的 ID 可能不連續(xù)，服務(wù)正常就可以。
其他特性
主要是看具體業(yè)務(wù)了，需要認(rèn)證和權(quán)限控制都是可選的，可用在請求層限制來源 IP,只允許固定的 IP 訪問。發(fā)號器的幾種常用方案
UUID 是 Universally Unique Identifier 的縮寫，它是在一定的范圍內(nèi)(從特定的名字空間到全球)唯一的機(jī)器生成的標(biāo)識符，UUID 是16字節(jié)128位長的數(shù)字，通常以36字節(jié)的字符串表示，比如：3F2504E0-4F89-11D3-9A0C-0305E82C3301。
UUID經(jīng)由一定的算法機(jī)器生成，為了保證 UUID 的唯一性，規(guī)范定義了包括網(wǎng)卡 MAC 地址、時間戳、名字空間(Namespace)、隨機(jī)或偽隨機(jī)數(shù)、時序等元素，以及從這些元素生成 UUID 的算法。UUID 的復(fù)雜特性在保證了其唯一性的同時，意味著只能由計(jì)算機(jī)生成。
優(yōu)缺點(diǎn)： 本地生成，性能高，延遲低，位數(shù)長，不適用當(dāng)作索引字段，同時是無序的，難以根據(jù)特征分析趨勢。
snowflake是twitter開源的分布式ID生成算法，其核心思想為，一個long型的ID：
41bit作為毫秒數(shù) - 10bit作為機(jī)器編號 - 12bit作為毫秒內(nèi)序列號
算法單機(jī)每秒內(nèi)理論上最多可以生成1000*(2^12)，也就是400W的ID，
優(yōu)缺點(diǎn)： 整個 ID 都是自增的，這個非常適合查看趨勢，同時生成不依賴于第三方系統(tǒng)，可靠性很高，可調(diào)整性也很高。缺點(diǎn)就是嚴(yán)重依賴機(jī)器時鐘。
字段設(shè)置 auto_increment_increment 和 auto_increment_offset 來保證 ID 自增，每次業(yè)務(wù)使用下列 SQL 讀寫 MySQL 得到 ID。
begin;
REPLACE INTO Tickets64 (stub) VALUES ("a");
SELECT LAST_INSERT_ID();
commit;
為了保證高可用，需要有多臺 MySQL 機(jī)器，也需要為每臺機(jī)器設(shè)置不同的自增起始值和步長，例如：
# TicketServer1: auto-increment-increment = 2 auto-increment-offset = 1 # TicketServer2: auto-increment-increment = 2 auto-increment-offset = 2
優(yōu)缺點(diǎn)： 簡單可靠，成本很小，由專業(yè) DBA 進(jìn)行維護(hù)就可以的。ID 單調(diào)遞增，有合適的業(yè)務(wù)是最好的。缺點(diǎn)就是強(qiáng)依賴于數(shù)據(jù)庫，修改起點(diǎn)和步長優(yōu)點(diǎn)困難，同時也需要額外保證數(shù)據(jù)庫的穩(wěn)定可用。每次請求都去額外讀寫數(shù)據(jù)庫的情況下，造成數(shù)據(jù)庫壓力很大，需要消耗很多資源。
以上就是最常用的三種全局唯一 ID 生成方案，采用較多的是類 snowflake 的方案，如果請求數(shù)列不是很高，可以調(diào)低時間的精度等，靈活性很高。生成的 ID 時間趨勢自增，甚至可以用來做索引字段，占用空間較小。后期對數(shù)據(jù)進(jìn)行分析的時候也很方便。生產(chǎn)環(huán)境唯一ID的使用
類 snowflake 的方案，會采用請求時生成的方式，無法提前生成。
基于 MySQL 的發(fā)號器，或者 uuid 模式的，可用提前生成一大批數(shù)據(jù)，根據(jù)業(yè)務(wù)去定生成數(shù)量，放到內(nèi)存，MQ 或者 Redis List中，業(yè)務(wù)申請唯一 ID 的時候，直接從其中彈一個出來。同時加一個異步定時任務(wù)，固定時間計(jì)算一下隊(duì)列中剩余的唯一 ID 數(shù)量，數(shù)量不足時及時的再次生成一大批，加入到備選隊(duì)列。
Go snowflake的demo:
參考文章：
有贊技術(shù)團(tuán)隊(duì)文章 - 發(fā)號器
CSDN文章
美團(tuán)分布式ID生成
Go snowflake包
一如既往，推薦幾個 高質(zhì)量課程，你學(xué)到新東西，我賺點(diǎn)傭金，大家都是贏家。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/31787.html
摘要：出于以上兩個原因，我們需要自己的發(fā)號器來產(chǎn)生。與此同時，為了保證執(zhí)行，具有原子性，我們使用來進(jìn)行實(shí)現(xiàn)。由于能力和水平有限，難免會有紕漏，希望及時指出。參考文章分布式生成器實(shí)現(xiàn)上實(shí)現(xiàn)原理 1、為什么要實(shí)現(xiàn)發(fā)號器 很多地方我們都需要一個全局唯一的編號，也就是uuid。舉一個常見的場景，電商系統(tǒng)產(chǎn)生訂單的時候，需要有一個對應(yīng)的訂單編號。在composer上我們也可以看到有很多可以產(chǎn)生uuid...
摘要：映射機(jī)制對每個長鏈接，使用一個小于億的整數(shù)標(biāo)記。短鏈接不夠用或者雖然我們的短鏈接可以表示億個資源，貌似很多，但是對于大型系統(tǒng)，如銀行，搜索引擎等等，還是非常少的。解決既然位短鏈接不夠用，那可以多使用幾位，比如位，大概等于億但是，總是有限的。 引用、參考：短 URL 系統(tǒng)是怎么設(shè)計(jì)的？iammutex的回答 什么是短鏈接 表示較短的URL（是不是廢話？....） 為什么需要短鏈接 不同...
摘要：舉個例子，第一個進(jìn)來的鏈接發(fā)號器發(fā)號，對應(yīng)的短鏈接為，第二個進(jìn)來的鏈接發(fā)號器發(fā)號，對應(yīng)的短鏈接為，以此類推。這樣一來會導(dǎo)致一條長鏈接對應(yīng)多條短鏈接的情況出現(xiàn)，不僅浪費(fèi)存儲空間，又浪費(fèi)發(fā)號器資源。 1. 什么是短鏈接 顧名思義，短鏈接即是長度較短的網(wǎng)址。通過短鏈接技術(shù)，我們可以將長度較長的鏈接壓縮成較短的鏈接。并通過跳轉(zhuǎn)的方式，將用戶請求由短鏈接重定向到長鏈接上去。短鏈接主要用在諸如微博...
閱讀 1937·2021-11-11 16:55
閱讀 808·2019-08-30 15:53
閱讀 3667·2019-08-30 15:45
閱讀 796·2019-08-30 14:10
閱讀 3326·2019-08-30 12:46
閱讀 2182·2019-08-29 13:15
閱讀 2083·2019-08-26 13:48
閱讀 988·2019-08-26 12:23
