數據庫自增id：
這個就是說你的系統里每次得到一個id，都是往一個庫的一個表里插入一條沒什么業務含義的數據，然后獲取一個數據庫自增的一個id。拿到這個id之后再往對應的分庫分表里去寫入。
這個方案的好處就是方便簡單；缺點就是單庫生成自增id，要是高並發的話，就會有瓶頸的；
適合的場景：你分庫分表就倆原因，要不就是單庫並發太高，要不就是單庫數據量太大；除非是你並發不高，但是數據量太大導致的分庫分表擴容，你可以用這個方案，因為可能每秒最高並發最多就幾百，那么就走單獨的一個庫和表生成自增主鍵即可。
uuid：
好處就是本地生成，不要基於數據庫來了；不好之處就是，uuid太長了，作為主鍵性能太差了，不適合用於主鍵。
適合的場景：如果你是要隨機生成個什么文件名了，編號之類的，你可以用uuid，但是作為主鍵是不能用uuid的。
獲取系統當前時間：
適合的場景：一般如果用這個方案，是將當前時間跟很多其他的業務字段拼接起來，作為一個id，如果業務上你覺得可以接受，那么也是可以的。你可以將別的業務字段值跟當前時間拼接起來，組成一個全局唯一的編號，訂單編號，時間戳 + 用戶id + 業務含義編碼
snowflake算法：
twitter開源的分布式id生成算法，就是把一個64位的long型的id，1個bit是不用的，用其中的41 bit作為毫秒數，用10 bit作為工作機器id，12 bit作為序列號
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
64位的long型的id，64位的long -> 二進制
0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 11001 | 0000 00000000
轉自：中華石杉Java工程師面試突擊