在高并發或者分表分庫情況下怎么保證數據id的冪等性呢？
經常用到的解決方案有以下幾種。
微軟公司通用唯一識別碼（UUID）
Twitter公司雪花算法（SnowFlake）
基于數據庫的id自增
對id進行緩存
一、SnowFlake算法
snowflake是Twitter開源的分布式ID生成算法，結果是一個long型的ID。
其核心思想是：使用41bit作為毫秒數，10bit作為機器的ID（5個bit是數據中心，5個bit的機器ID），12bit作為毫秒內的流水號，最后還有一個符號位，永遠是0。
snowflake算法所生成的ID結構，如下圖：
整個結構是64位，所以我們在JAVA中可以使用long來進行存儲。
該算法實現基本就是二進制操作,單機每秒內理論上最多可以生成1024*(2^12)，也就是409.6萬個ID(1024 X 4096 = 4194304)
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
1位標識，由于long基本類型在Java中是帶符號的，最高位是符號位，正數是0，負數是1，所以id一般是正數，最高位是0
41位時間截(毫秒級)。注意，41位時間截不是存儲當前時間的時間截，而是存儲時間截的差值（當前時間截 - 開始時間截)
這里的的開始時間截，一般是我們的id生成器開始使用的時間，由我們程序來指定的（如下面程序IdWorker類的startTime屬性）。41位的時間截，可以使用69年，年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69
10位的數據機器位，可以部署在1024個節點，包括5位datacenterId和5位workerId
12位序列，毫秒內的計數，12位的計數順序號支持每個節點每毫秒(同一機器，同一時間截)產生4096個ID序號
加起來剛好64位，為一個Long型。
SnowFlake的優點是，整體上按照時間自增排序，并且整個分布式系統內不會產生ID碰撞(由數據中心ID和機器ID作區分)，并且效率較高
經測試，SnowFlake每秒能夠產生26萬ID左右。
snowFlake算法的優點：
生成ID時不依賴于DB，完全在內存生成，高性能高可用。
ID呈趨勢遞增，后續插入索引樹的時候性能較好。
SnowFlake算法的缺點：
依賴于系統時鐘的一致性。如果某臺機器的系統時鐘回撥，有可能造成ID沖突，或者ID亂序
二、基于數據庫的id自增
字段說明：
id代表該obj本次set后的maxid
不同業務不同的ID需求可以用obj字段區分，每個obj的ID獲取相互隔離，互不影響
step 步長，代表每次獲取多長ID段到緩存
基本要求：
全局唯一性：不能出現重復的ID號，既然是唯一標識，這是最基本的要求
趨勢遞增：在MySQL InnoDB引擎使用的是聚集索引, 由于多數的RDBMS使用B-tree的數據結構來存儲索引數據，在主鍵的選擇上應該盡量使用有序的主鍵保證寫入性能
單調遞增：保證下一個ID一定大于上一個ID，例如事務版本號、IM增量消息、排序等特殊需求
信息安全：如果ID是聯系的，惡意用戶的扒取工作就非常容易做了，直接按照順序下載指定URL即可；如果是訂單號就更危險了，競爭對手可以直接知道我們一天的單量。所以在這些場景下，會需要ID無規則，不規則。
性能要求：
平均延遲和TP999延遲都要盡可能低
可用性5個9（99.999%）
高QPS
優點：
支持全局唯一、系統唯一、表級別唯一三種形式，絕對不會出現重復ID，且ID整體趨勢遞增；
大大的降低了數據庫的壓力，ID生成可以做到每秒生成幾萬幾十萬個
一定的高可用，服務采用預分配ID的方案，每次調用分配10000個id到系統緩存集群，即使MySQL宕機，也能容忍一段時間數據不可用；
接入簡單，直接通過公司的RPC服務或者HTTP調用即可使用;
缺點：
強依賴數據庫，當MySQL服務長時間不可用，那么對公司業務將是一場災難；
并發性能較低，假設公司業務量急劇增長，idgenerator服務請求并發量增高，而實際上在更新數據庫時會觸發表鎖，可能造成ID獲取失敗,導致服務不可用;
缺少服務自身監控，無法通過web層的內存數據映射界面實時觀測所有號段的下發狀態及使用情況
服務仍然是單點
如果服務掛了，服務重啟起來之后，繼續生成ID可能會不連續，中間出現空洞（服務內存是保存著0,1,2,3,4,5，數據庫中max-id是5，分配到3時，服務重啟了，下次會從6開始分配，4和5就成了空洞，不過這個問題也不大）
雖然每秒可以生成幾萬幾十萬個ID，但畢竟還是有性能上限，無法進行水平擴展
三、UUID
UUID 是指Universally Unique Identifier，翻譯為中文是通用唯一識別碼，UUID 的目的是讓分布式系統中的所有元素都能有唯一的識別信息。如此一來，每個人都可以創建不與其它人沖突的 UUID，就不需考慮數據庫創建時的名稱重復問題。
定義
UUID 是由一組32位數的16進制數字所構成，是故 UUID 理論上的總數為1632=2128，約等于3.4 x 10123。
也就是說若每納秒產生1百萬個 UUID，要花100億年才會將所有 UUID 用完
格式
UUID 的十六個八位字節被表示為 32個十六進制數字，以連字號分隔的五組來顯示，形式為 8-4-4-4-12，總共有 36個字符（即三十二個英數字母和四個連字號）。例如：
123e4567-e89b-12d3-a456-426655440000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
數字 M的四位表示 UUID 版本，當前規范有5個版本，M可選值為1, 2, 3, 4, 5 ；
數字 N的一至四個最高有效位表示 UUID 變體( variant )，有固定的兩位10xx因此只可能取值8, 9, a, b
UUID版本通過M表示，當前規范有5個版本，M可選值為1, 2, 3, 4, 5。這5個版本使用不同算法，利用不同的信息來產生UUID，各版本有各自優勢，適用于不同情景。具體使用的信息
version 1, date-time & mac address
version 2, date-time & group/user id
version 3, MD5 hash & namespace
version 4, pseudo-random number
version 5, SHA-1 hash & namespace
使用較多的是版本1和版本4，其中版本1使用當前時間戳和MAC地址信息。版本4使用(偽)隨機數信息，128bit中，除去版本確定的4bit和variant確定的2bit，其它122bit全部由(偽)隨機數信息確定。
因為時間戳和隨機數的唯一性，版本1和版本4總是生成唯一的標識符。若希望對給定的一個字符串總是能生成相同的 UUID，使用版本3或版本5。
隨機 UUID 的重復機率
Java中 UUID 使用版本4進行實現，所以由java.util.UUID類產生的 UUID，128個比特中，有122個比特是隨機產生，4個比特標識版本被使用，還有2個標識變體被使用。利用生日悖論，可計算出兩筆 UUID 擁有相同值的機率約為
其中x為 UUID 的取值范圍，n為 UUID 的個數。
以下是以 x = 2122 計算出n筆 UUID 后產生碰撞的機率：
換句話說，每秒產生10億筆 UUID ，100年后只產生一次重復的機率是50%。如果地球上每個人都各有6億筆 UUID，發生一次重復的機率是50%。與被隕石擊中的機率比較的話，已知一個人每年被隕石擊中的機率估計為170億分之1，也就是說機率大約是0.00000000006 (6 x 10-11)，等同于在一年內生產2000億個 UUID 并發生一次重復。
作者：william0318
原文鏈接：https://blog.csdn.net/William0318/article/details/103636032
