通過本文檔你將學習到
- 為什么需要分布式全局唯一ID以及分布式ID的業(yè)務需求 ？
- ID生成規(guī)則部分硬性要求暂雹？目標出現(xiàn)了渣磷，就知道我們該怎么做了向楼。
- ID號生成系統(tǒng)的可用性要求
- 一般通用方案田炭，大部分我們都是怎么玩這個唯一ID的师抄？
- 王者玩家怎么玩的？
1 為什么需要唯一ID
復雜的分布式西戎中教硫，需要大量的數(shù)據(jù)和消息進行唯一標識叨吮，訂單號，用戶UID等等瞬矩，你需要一個全局的唯一的ID茶鉴。
2 要求
2.1 生成規(guī)則的硬性要求：
- 全局唯一
不能出現(xiàn)重復的ID號,既然是唯一標識,這是最基本的要求 - 趨勢遞增
在MySQL的innoDB引擎中使用的是聚集索引,由于多數(shù)RDBMS使用Btree的數(shù)據(jù)結(jié)構(gòu)來存儲索引數(shù)據(jù),在主鍵的選擇上面我們應該盡量使用有序的主鍵保證寫入性能。 - 單調(diào)遞增
保證下一個ID大于上一個ID,丧鸯。為什么蛤铜？ 這個可以參考InnoDB存儲引擎的特點，
關(guān)于mysql的數(shù)據(jù)底層是怎么保存數(shù)據(jù)的丛肢，B+樹又是什么？可以自己去查看《mysql必知必會》+《MySQL技術(shù)內(nèi)幕：InnoDB存儲引擎》 + 極客時間 mysql實戰(zhàn)45
《數(shù)據(jù)結(jié)構(gòu)與算法》詳細解釋了什么二三樹 AVL樹 b+樹等等
如果不怎么熟悉mysql,一上去就看經(jīng)典《高性能mysql》你會一臉懵逼剿干。
- 信息安全
如果ID是連續(xù)的,惡意用戶的扒取工作就非常容易做了,直接按照順序下載指定URL即可 所以在一些應用場景下,需要ID無規(guī)則 不規(guī)則,讓競爭對手不好猜 - 含時間戳
這樣就能在開發(fā)中快速了解分布式id的生成時間
2.2 生成系統(tǒng)的可用性要求：
- 高可用
發(fā)一個獲取分布式ID的請求,服務器就要保證99.999%的情況下給我創(chuàng)建一個唯一分布式ID - 低延遲
發(fā)一個獲取分布式ID的請求,服務器就要快,極速 - 高QPS：10萬個的請求同時過來蜂怎。
假如并發(fā)一口氣創(chuàng)建分布式ID請求同時殺過來,服務器要頂?shù)米∏乙幌伦映晒?chuàng)建10萬
3常用的幾種方案
你不要一上來就扯用雪花算法，然后分享結(jié)束置尔。這就是在扯杠步。當別人問題用什么，你只能回答看業(yè)務需求榜轿。假如一個項目只有100個用戶幽歼，你說生成UID，用雪花算法谬盐。需要么甸私？直接DB自增不就可以了么？
UUID
如果只考慮唯一性,OK 入數(shù)據(jù)庫性能差飞傀？為什么差還得看那幾本書皇型。
數(shù)據(jù)庫自增主鍵
不解釋了诬烹，低延遲什么高QPS 搞不定，
基于redis生成全局id策略 我們項目種使用的好像就是這個
單機：因為Redis是單線的天生保證原子性,可以使用原子操作INCR和INCRBY來實現(xiàn)
王者
Twitter的分布式自增ID算法snowflake
具體時間
雪花算法java源碼
http://www.reibang.com/p/2a27fbd9e71a
工作種就是把源碼粘貼一下封裝下直接用么弃鸦？不好意思绞吁，你想到到別人都想到了，直接有封裝好的工具包 maven引入搞起唬格。
糊涂工具包 就是我們每個工程里面都有一些untils包家破，這個maven引入，幾乎你想到的都有购岗。
https://github.com/looly/hutool
<dependency>
<groupId>cn.hutool</groupId>
<artifactId>hutool-captcha</artifactId>
<version>5.2.0</version>
</dependency>
核心代碼IdGeneratorSnowflake
