摘要:序本文主要來聊聊分布式的生成方案。分布式的生成,以為代表的,系列算法采用的就是劃分命名空間并行生成的思路。
序
本文主要來聊聊分布式id的生成方案。
目標業務系統需要什么樣的ID生成器中提出了幾點目標:
唯一性
時間相關
粗略有序
可反解
可制造
主要思路對于每個標識,都需要有一個命名空間(namespace),來保證其相對唯一性。
分布式的ID生成,以Twitter Snowflake為代表的, Flake 系列算法采用的就是劃分命名空間并行生成的思路。
UUID(Universally Unique Identifier)的標準型式包含32個16進制數字(每個字符0-F的字符代表4bit,共128bit),以連字號分為五段,形式為8-4-4-4-12的32+4個字符。
比如bc96c351-bea3-4e53-b0a8-d9806763dd69。
主要的格式如下:
時間戳+UUID版本號,分三段占16個字符(60bit+4bit),
Clock Sequence號與保留字段,占4個字符(13bit+3bit),
節點標識占12個字符(48bit),
version 4 基于隨機數的算法,也是JDK里的算法,不管原來各個位的含義了,除了少數幾個位必須按規范填,其余全部用隨機數表達。
mongo object id通過“時間+機器碼+pid+inc”共12個字節,通過4+3+2+3的方式最終標識成一個24長度的十六進制字符。ObjectId是一個12字節 BSON 類型數據,有以下格式:
4個字節表示的Unix timestamp
3個字節表示的機器的ID
2個字節表示的進程ID
3個字節表示的計數器
snow flake算法個64 bits的唯一long型的ID,使用其中41bit作為毫秒數,10bit作為機器編號,12bit作為毫秒內序列號。IdWorker
+---------------+----------------+----------------+ |timestamp(ms)42 | worker id(10) | sequence(12) | +---------------+----------------+----------------+ id = timestamp | workerid | sequence (eg. 1451063443347648410)
默認采用上圖字節分配方式:
第一位為未使用,接下來的41位為毫秒級時間(41位的長度可以使用69年)
5位datacenterId和5位workerId(10位的長度最多支持部署1024個節點)
12位是毫秒內的計數(12位的計數順序號支持每個節點每毫秒產生4096個ID序號)
snowflake生成的ID整體上按照時間自增排序,并且整個分布式系統內不會產生ID碰撞(由datacenter和workerId作區分),并且效率較高。這個算法單機每秒內理論上最多可以生成1000*(2^12),也就是400W的ID。
snow flake算法變種 Boundary flakeBoundary flakeID 長度擴展到 128 bits:
+---------------+----------------+----------------+ |timestamp(ms)64 | worker id(48) | sequence(16) | +---------------+----------------+----------------+ id = timestamp | workerid | sequence
最高 64 bits 時間戳;
然后是 48 bits 的 Worker 號 (和 Mac 地址一樣長);
最后是 16 bits 的 Seq Number
由于它用 48 bits 作為 Worker ID, 和 Mac 地址的長度一樣, 這樣啟動時不需要和 Zookeeper 通訊獲取 Worker ID. 做到了完全的去中心化
它這樣做的目的是用更多的 bits 實現更小的沖突概率, 這樣就支持更多的 Worker 同時工作. 同時, 每毫秒能分配出更多的 ID
simpleflake取消 Worker 號, 保留 41 bits 的 Timestamp, 同時把 sequence number 擴展到 22 bits
+---------------+----------------+ |timestamp(ms)42 | sequence(22) +---------------+----------------+ id = timestamp | sequence
Simpleflake 的特點:
sequence number 完全靠隨機產生 (這樣也導致了生成的 ID 可能出現重復)
沒有 Worker 號, 也就不需要和 Zookeeper 通訊, 實現了完全去中心化
Timestamp 保持和 Snowflake 一致, 今后可以無縫升級到 Snowflake
缺點:
生成的 ID 重復的可能. 這個生成 ID 重復的概率隨著每秒生成的 ID 數的增長而增長。
每秒生成的 ID 不能太多 (最好小于 100次/秒, 如果大于 100次/秒的場景, Simpleflake 就不適用
百度唯一idUidGenerator
+---------------+----------------+----------------+ |timestamp(ms)29 | worker id(22) | sequence(13) | +---------------+----------------+----------------+ id = sign + delta seconds | workerid | sequence
timestap
sign(1bit)固定1bit符號標識,即生成的UID為正數。
delta seconds (28 bits)前時間,相對于時間基點"2016-05-20"的增量值,單位:秒,最多可支持約8.7年
worker id (22 bits)
機器id,最多可支持約420w次機器啟動。內置實現為在啟動時由數據庫分配,默認分配策略為用后即棄,后續可提供復用策略。
sequence (13 bits)
每秒下的并發序列,13 bits可支持每秒8192個并發。
服務化框架-分布式Unique ID的生成方法一覽
Leaf——美團點評分布式ID生成系統
分布式系統中唯一 ID 的生成方法
細聊分布式ID生成方法
生成全局唯一ID的3個思路,來自一個資深架構師的總結
Announcing Snowflake
A distributed, k-sortable unique ID generation system using Redis and Lua
經典的雪花算法-springboot
一個實現 Twitter SnowFlake 算法 的 Go 分布式 UID 生成器
Java實現的, 基于Snowflake算法的唯一ID生成器
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/70301.html
摘要:編譯完成后,如果沒有報錯,那么通過命令對字節碼文件進行解釋運行,執行時不需要添加后綴總結說白了,整個程序對編寫運行有三步編寫為后綴對程序文件通過程序文件進行編譯生成文件文件名解釋運行寫代碼編譯解釋運行 前言 最近開始學習下java,畢竟web開發還是java比較完善功能也較php更加強大。學習資料參考:https://github.com/DuGuQiuBai... 此章主要記錄下...
摘要:分布式生成算法的有很多種,的就是其中經典的一種。負數的二進制表示在計算機中,負數的二進制是用補碼來表示的。 分布式id生成算法的有很多種,Twitter的SnowFlake就是其中經典的一種。 概述 SnowFlake算法生成id的結果是一個64bit大小的整數,它的結構如下圖: showImg(https://segmentfault.com/img/bVVulC?w=1021&h=...
摘要:微服務架構概述應用架構的發展應用是可獨立運行的程序代碼,提供相對完善的業務功能。阿里開源的是的典型實現。它目前由官方開發維護,基于開發,提供一套完整的微服務解決方案。 微服務與Spring Cloud 隨著互聯網的快速發展, 云計算近十年也得到蓬勃發展, 企業的IT環境和IT架構也逐漸在發生變革,從過去的單體應用架構發展為至今廣泛流行的微服務架構。 微服務是一種架構風格, 能給軟件應用...
閱讀 1382·2021-11-15 18:11
閱讀 2512·2021-08-19 10:56
閱讀 677·2021-08-09 13:42
閱讀 793·2019-08-30 15:53
閱讀 2086·2019-08-30 10:55
閱讀 3142·2019-08-29 17:18
閱讀 1435·2019-08-29 13:45
閱讀 545·2019-08-29 13:15