左視覺丶Left

可以的。

全局唯一 ID

有些同學可能會有疑問，MySQL 數據庫本身就有自增長的主鍵，為什麼還需要別的組件協助生成呢？

如果是單臺 MySQL 數據庫的話，當然是用本身的自增長序列就可以了，但是如果我們做了分庫分表之後呢？比如用戶表 userTable 數據量達到了 4000 萬，單表有些吃力，我們將 userTable 拆成兩張表保存到兩個 MySQL 數據庫中；這時候如果再使用數據庫本身的自增序列，倒是也不會有錯，每一個表內的主鍵不會重複，但是表和表比較的話，主鍵 ID 可能會發生重複；這時候就需要使用組件或者算法，生成全局唯一 ID 了。

MongoDB ObjectId

MongoDB 的 ObjectId ，也是可以用於全局唯一 ID 的。

{"_id": ObjectId("5d47ca7528021724ac19f745")}

MongoDB 的 ObjectId 共佔 12 個字節，其中：

• 3.2 之前的版本（包括 3.2）：4 字節時間戳 + 3 字節機器標識符（機器 ID） + 2 字節進程 ID + 3字節隨機計數器；

• 3.2 之後版本：4 字節時間戳 + 5 字節隨機值 + 3 字節遞增計數器；

其中時間戳字節可以保證毫秒級唯一，節機器標識符考慮到了分佈式，字節進程 ID 保證了同一臺服務器運行多個實例時的唯一性，字節遞增計數器保證了同一個時間點內 ID 的唯一性。

優缺點

不管是老版本還是新版本，MongoDB 的 ObjectId 至少都可以保證集群內的唯一，我們可以搭建一個全局唯一 ID 生成的服務，利用 MongoDB 生成 ObjectId 並對外提供服務（MongoDB 的各語言驅動都實現了 ObjectId 的生成算法）。

• 優點：MongoDB 的性能不錯，可以使用集群部署，保證其高可用；ID 內自帶一些含義，比如時間戳，必要的時候可以進行反解；

• 缺點：和數據庫一樣，需要引入對應的組件/軟件，增加了系統的複雜度；最關鍵的是，這兩種方案都意味著生成全局唯一 ID 的系統（服務），會成為一個單點，在軟件架構中，單獨就意味著風險；如果這個服務出現問題，那麼所有依賴於這個服務的系統都會崩潰掉。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

會點代碼的大叔

哈哈，我自己的文章，被頭條推薦邀請回答，這是什麼操作！那我就再來回答一下吧

MongoDB是分佈式的，那麼它是如何保證全局主鍵唯一的呢？首先看下MongoDB ObjectId的數據結構

ObjectId由12個Byte組成，分成4個部分

• 4個byte用於表示當前時間，只到秒（可以考慮下為什麼不是毫秒？）
• 3個byte用於表示當前機器，將網卡信息編碼到3個byte中
• 2個byte用於表示當前進程id
• 2個byte用於自增數

優點

• 不同主機之間，由於網卡信息是不一樣的，因此生成的id是不可能衝突的
• 在同一個主機上，即使部署了多個實例，由於它們的進程ID是不一樣的，因此生成的id也不可能衝突

看到這裡就感覺這樣的方案簡直就是完美，不用任何配置，就自動的生成了全局唯一ID。比起Snowflake算法好用多了！

那我們不是直接就可以拿到Mysql中用於主鍵字段了？等等，事情沒那麼簡單！想想mysql數字類型BigInt的最大值，BigInt由8 byte組成，如圖