在分庫分表之後你必然要面對的一個問題，就是id咋生成?

　　因為要是一個表分成多個表之後，每個表的id都是從1開始累加自增長，那肯定不對啊。

　　舉個例子，你的訂單表拆分為了1024張訂單表，每個表的id都從1開始累加，這個肯定有問題了!

　　你的系統就沒辦法根據表主鍵來查詢訂單了，比如id = 50這個訂單，在每個表裏都有!

　　所以此時就需要分布式架構下的全局唯一id生成的方案了，在分庫分表之後，對於插入數據庫中的核心id，不能直接簡單使用表自增id，要全局生成唯一id，然後插入各個表中，保證每個表內的某個id，全局唯一。

　　比如說訂單表雖然拆分為了1024張表，但是id = 50這個訂單，只會存在於一個表裏。

　　那麽如何實現全局唯一id呢?有以下幾種方案。

　　(1)方案一：獨立數據庫自增id

　　這個方案就是說你的系統每次要生成一個id，都是往一個獨立庫的一個獨立表裏插入一條沒什麽業務含義的數據，然後獲取一個數據庫自增的一個id。拿到這個id之後再往對應的分庫分表裏去寫入。

　　比如說你有一個auto_id庫，裏面就一個表，叫做auto_id表，有一個id是自增長的。

　　那麽你每次要獲取一個全局唯一id，直接往這個表裏插入一條記錄，獲取一個全局唯一id即可，然後這個全局唯一id就可以插入訂單的分庫分表中。

　　這個方案的好處就是方便簡單，誰都會用。缺點就是單庫生成自增id，要是高並發的話，就會有瓶頸的，因為auto_id庫要是承載個每秒幾萬並發，肯定是不現實的了。

　　(2)方案二：uuid

　　這個每個人都應該知道吧，就是用UUID生成一個全局唯一的id。

　　好處就是每個系統本地生成，不要基於數據庫來了

　　不好之處就是，uuid太長了，作為主鍵性能太差了，不適合用於主鍵。

　　如果你是要隨機生成個什麽文件名了，編號之類的，你可以用uuid，但是作為主鍵是不能用uuid的。

　　(3)方案三：獲取系統當前時間

　　這個方案的意思就是獲取當前時間作為全局唯一的id。

　　但是問題是，並發很高的時候，比如一秒並發幾千，會有重復的情況，這個是肯定不合適的。

　　一般如果用這個方案，是將當前時間跟很多其他的業務字段拼接起來，作為一個id，如果業務上你覺得可以接受，那麽也是可以的。

　　你可以將別的業務字段值跟當前時間拼接起來，組成一個全局唯一的編號，比如說訂單編號：時間戳 + 用戶id + 業務含義編碼。

　　(4)方案四：snowflake算法的思想分析

　　snowflake算法，是twitter開源的分布式id生成算法。

　　其核心思想就是：使用一個64 bit的long型的數字作為全局唯一id，這64個bit中，其中1個bit是不用的，然後用其中的41 bit作為毫秒數，用10 bit作為工作機器id，12 bit作為序列號。

　　給大家舉個例子吧，比如下面那個64 bit的long型數字，大家看看

　　上面第一個部分，是1個bit：0，這個是無意義的

　　上面第二個部分是41個bit：表示的是時間戳

　　上面第三個部分是5個bit：表示的是機房id，10001

　　上面第四個部分是5個bit：表示的是機器id，1 1001

　　上面第五個部分是12個bit：表示的序號，就是某個機房某臺機器上這一毫秒內同時生成的id的序號，0000 00000000

　　1 bit：是不用的，為啥呢?

　　因為二進制裏第一個bit為如果是1，那麽都是負數，但是我們生成的id都是正數，所以第一個bit統一都是0

　　41 bit：表示的是時間戳，單位是毫秒。

　　41 bit可以表示的數字多達2^41 - 1，也就是可以標識2 ^ 41 - 1個毫秒值，換算成年就是表示69年的時間

　　10 bit：記錄工作機器id，代表的是這個服務最多可以部署在2^10臺機器上，也就是1024臺機器。

　　但是10 bit裏5個bit代表機房id，5個bit代表機器id。意思就是最多代表2 ^ 5個機房(32個機房)，每個機房裏可以代表2 ^ 5個機器(32臺機器)。

　　12 bit：這個是用來記錄同一個毫秒內產生的不同id。

　　12 bit可以代表的最大正整數是2 ^ 12 - 1 = 4096，也就是說可以用這個12bit代表的數字來區分同一個毫秒內的4096個不同的id

　　簡單來說，你的某個服務假設要生成一個全局唯一id，那麽就可以發送一個請求給部署了snowflake算法的系統，由這個snowflake算法系統來生成唯一id。

　　這個snowflake算法系統首先肯定是知道自己所在的機房和機器的，比如機房id = 17，機器id = 12。

　　接著snowflake算法系統接收到這個請求之後，首先就會用二進制位運算的方式生成一個64 bit的long型id，64個bit中的第一個bit是無意義的。

　　接著41個bit，就可以用當前時間戳(單位到毫秒)，然後接著5個bit設置上這個機房id，還有5個bit設置上機器id。

　　最後再判斷一下，當前這臺機房的這臺機器上這一毫秒內，這是第幾個請求，給這次生成id的請求累加一個序號，作為最後的12個bit。

　　最終一個64個bit的id就出來了，類似於：

　　這個算法可以保證說，一個機房的一臺機器上，在同一毫秒內，生成了一個唯一的id。可能一個毫秒內會生成多個id，但是有最後12個bit的序號來區分開來。

　　下面我們簡單看看這個snowflake算法的一個代碼實現，這就是個示例，大家如果理解了這個意思之後，以後可以自己嘗試改造這個算法。

　　總之就是用一個64bit的數字中各個bit位來設置不同的標誌位，區分每一個id。

　　(5)snowflake算法的代碼實現

　　public class IdWorker {

　　private long workerId; // 這個就是代表了機器id

　　private long datacenterId; // 這個就是代表了機房id

　　private long sequence; // 這個就是代表了一毫秒內生成的多個id的最新序號

　　public IdWorker(long workerId, long datacenterId, long sequence) {

　　// sanity check for workerId

　　// 這兒不就檢查了一下，要求就是你傳遞進來的機房id和機器id不能超過32，不能小於0

　　if (workerId maxWorkerId || workerId 0) {

　　throw new IllegalArgumentException(

　　String.format(worker Id can‘t be greater than %d or less than 0,maxWorkerId));

　　}

　　if (datacenterId maxDatacenterId || datacenterId 0) {

　　throw new IllegalArgumentException(

　　String.format(datacenter Id can‘t be greater than %d or less than 0,maxDatacenterId));

　　}

　　this.workerId = workerId;

　　this.datacenterId = datacenterId;

　　this.sequence = sequence;

　　}

　　private long twepoch = 1288834974657L;

　　private long workerIdBits = 5L;

　　private long datacenterIdBits = 5L;

　　// 這個是二進制運算，就是5 bit最多只能有31個數字，也就是說機器id最多只能是32以內

　　private long maxWorkerId = -1L ^ (-1L workerIdBits);

　　// 這個是一個意思，就是5 bit最多只能有31個數字，機房id最多只能是32以內

　　private long maxDatacenterId = -1L ^ (-1L datacenterIdBits);

　　private long sequenceBits = 12L;

　　private long workerIdShift = sequenceBits;

　　private long datacenterIdShift = sequenceBits + workerIdBits;

　　private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;

　　private long sequenceMask = -1L ^ (-1L sequenceBits);

　　private long lastTimestamp = -1L;

　　public long getWorkerId(){

　　return workerId;

　　}

　　public long getDatacenterId() {

　　return datacenterId;

　　}

　　public long getTimestamp() {

　　return System.currentTimeMillis();

　　}

　　// 這個是核心方法，通過調用nextId()方法，讓當前這臺機器上的snowflake算法程序生成一個全局唯一的id

　　public synchronized long nextId() {

　　// 這兒就是獲取當前時間戳，單位是毫秒

　　long timestamp = timeGen();

　　if (timestamp lastTimestamp) {

　　System.err.printf(

　　clock is moving backwards. Rejecting requests until %d., lastTimestamp);

　　throw new RuntimeException(

　　String.format(Clock moved backwards. Refusing to generate id for %d milliseconds,

　　lastTimestamp - timestamp));

　　}

　　// 下面是說假設在同一個毫秒內，又發送了一個請求生成一個id

　　// 這個時候就得把seqence序號給遞增1，最多就是4096

　　if (lastTimestamp == timestamp) {

　　// 這個意思是說一個毫秒內最多只能有4096個數字，無論你傳遞多少進來，

　　//這個位運算保證始終就是在4096這個範圍內，避免你自己傳遞個sequence超過了4096這個範圍

　　sequence = (sequence + 1) sequenceMask;

　　if (sequence == 0) {

　　timestamp = tilNextMillis(lastTimestamp);

　　}

　　} else {

　　sequence = 0;

　　}

　　// 這兒記錄一下最近一次生成id的時間戳，單位是毫秒

　　lastTimestamp = timestamp;

　　// 這兒就是最核心的二進制位運算操作，生成一個64bit的id

　　// 先將當前時間戳左移，放到41 bit那兒;將機房id左移放到5 bit那兒;將機器id左移放到5 bit那兒;將序號放最後12 bit

　　// 最後拼接起來成一個64 bit的二進制數字，轉換成10進制就是個long型

　　return ((timestamp - twepoch) timestampLeftShift) |

　　(datacenterId datacenterIdShift) |

　　(workerId workerIdShift) | sequence;

　　}

　　private long tilNextMillis(long lastTimestamp) {

　　long timestamp = timeGen();

　　while (timestamp = lastTimestamp) {

　　timestamp = timeGen();

　　}

　　return timestamp;

　　}

　　private long timeGen(){

　　return System.currentTimeMillis();

　　}

　　//---------------測試---------------

　　public static void main(String[] args) {

　　IdWorker worker = new IdWorker(1,1,1);

　　for (int i = 0; i 30; i++) {

　　System.out.println(worker.nextId());

　　}

　　}

　　}

　　(6)snowflake算法一個小小的改進思路

　　其實在實際的開發中，這個snowflake算法可以做一點點改進。

　　因為大家可以考慮一下，我們在生成唯一id的時候，一般都需要指定一個表名，比如說訂單表的唯一id。

　　所以上面那64個bit中，代表機房的那5個bit，可以使用業務表名稱來替代，比如用00001代表的是訂單表。

　　因為其實很多時候，機房並沒有那麽多，所以那5個bit用做機房id可能意義不是太大。

　　這樣就可以做到，snowflake算法系統的每一臺機器，對一個業務表，在某一毫秒內，可以生成一個唯一的id，一毫秒內生成很多id，用最後12個bit來區分序號對待。

?

分布式系統的唯一id生成算法你了解嗎？