1 面試題
分庫分表之后，id主鍵如何處理？
2 考點分析
其實這是分庫分表之后你必然要面對的一個問題，就是id咋生成？因為要是分成多個表之后，每個表都是從1開始累加，那肯定不對啊，需要一個全局唯一的id來支持。所以這都是你實際生產環境中必須考慮的問題。
3 面試題詳解
3.1 數據庫自增id
-
分庫分表的id主鍵問題
這個就是說你的系統里每次得到一個id，都是往一個庫的一個表里插入一條沒什么業務含義的數據，然后獲取一個數據庫自增的一個id。拿到這個id之后再往對應的分庫分表里去寫入。
這個方案的好處就是方便簡單，誰都會用；缺點就是單庫生成自增id，要是高并發的話，就會有瓶頸的；如果你硬是要改進一下，那么就專門開一個服務出來，這個服務每次就拿到當前id最大值，然后自己遞增幾個id，一次性返回一批id，然后再把當前最大id值修改成遞增幾個id之后的一個值；但是無論怎么說都是基于單個數據庫。
適合的場景：你分庫分表就倆原因，要不就是單庫并發太高，要不就是單庫數據量太大；除非是你并發不高，但是數據量太大導致的分庫分表擴容，你可以用這個方案，因為可能每秒最高并發最多就幾百，那么就走單獨的一個庫和表生成自增主鍵即可。
并發很低，幾百/s，但是數據量大，幾十億的數據，所以需要靠分庫分表來存放海量的數據
3.2 uuid
好處就是本地生成，不要基于數據庫來了；不好之處就是，uuid太長了，作為主鍵性能太差了，不適合用于主鍵。
適合的場景：如果你是要隨機生成個什么文件名了，編號之類的，你可以用uuid，但是作為主鍵是不能用uuid的。
UUID.randomUUID().toString().replace(“-”, “”) -> sfsdf23423rr234sfdaf
3.3 獲取系統當前時間
這個就是獲取當前時間即可，但是問題是，并發很高的時候，比如一秒并發幾千，會有重復的情況，這個是肯定不合適的。基本就不用考慮了。
適合的場景：一般如果用這個方案，是將當前時間跟很多其他的業務字段拼接起來，作為一個id，如果業務上你覺得可以接受，那么也是可以的。你可以將別的業務字段值跟當前時間拼接起來，組成一個全局唯一的編號，訂單編號，時間戳 + 用戶id + 業務含義編碼
3.4 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 | 1 1001 | 0000 00000000
2018-01-01 10:00:00 -> 做了一些計算，再換算成一個二進制，41bit來放 -> 0001100 10100010 10111110 10001001 01011100 00
機房id，17 -> 換算成一個二進制 -> 10001
機器id，25 -> 換算成一個二進制 -> 11001
snowflake算法服務，會判斷一下，當前這個請求是否是，機房17的機器25，在2175/11/7 12:12:14時間點發送過來的第一個請求，如果是第一個請求
假設，在2175/11/7 12:12:14時間里，機房17的機器25，發送了第二條消息，snowflake算法服務，會發現說機房17的機器25，在2175/11/7 12:12:14時間里，在這一毫秒，之前已經生成過一個id了，此時如果你同一個機房，同一個機器，在同一個毫秒內，再次要求生成一個id，此時我只能把加1
0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 1 1001 | 0000 00000001
比如我們來觀察上面的那個，就是一個典型的二進制的64位的id，換算成10進制就是910499571847892992。
public class IdWorker{
private long workerId;
private long datacenterId;
private long sequence;
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));
}
System.out.printf("worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d",
timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId);
this.workerId = workerId;
this.datacenterId = datacenterId;
this.sequence = sequence;
}
private long twepoch = 1288834974657L;
private long workerIdBits = 5L;
private long datacenterIdBits = 5L;
private long maxWorkerId = -1L ^ (-1L << workerIdBits); // 這個是二進制運算，就是5 bit最多只能有31個數字，也就是說機器id最多只能是32以內
private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits); // 這個是一個意思，就是5 bit最多只能有31個數字，機房id最多只能是32以內
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();
}
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));
}
// 0
// 在同一個毫秒內，又發送了一個請求生成一個id，0 -> 1
if (lastTimestamp == timestamp) {
sequence = (sequence + 1) & sequenceMask; // 這個意思是說一個毫秒內最多只能有4096個數字，無論你傳遞多少進來，這個位運算保證始終就是在4096這個范圍內，避免你自己傳遞個sequence超過了4096這個范圍
if (sequence == 0) {
timestamp = tilNextMillis(lastTimestamp);
}
} else {
sequence = 0;
}
// 這兒記錄一下最近一次生成id的時間戳，單位是毫秒
lastTimestamp = timestamp;
// 這兒就是將時間戳左移，放到41 bit那兒；將機房id左移放到5 bit那兒；將機器id左移放到5 bit那兒；將序號放最后10 bit；最后拼接起來成一個64 bit的二進制數字，轉換成10進制就是個long型
return ((timestamp - twepoch) << timestampLeftShift) |
(datacenterId << datacenterIdShift) |
(workerId << workerIdShift) |
sequence;
}
0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 1 1001 | 0000 00000000
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());
}
}
}
怎么說呢，大概這個意思吧，就是說41 bit，就是當前毫秒單位的一個時間戳，就這意思；然后5 bit是你傳遞進來的一個機房id（但是最大只能是32以內），5 bit是你傳遞進來的機器id（但是最大只能是32以內），剩下的那個10 bit序列號，就是如果跟你上次生成id的時間還在一個毫秒內，那么會把順序給你累加，最多在4096個序號以內。
所以你自己利用這個工具類，自己搞一個服務，然后對每個機房的每個機器都初始化這么一個東西，剛開始這個機房的這個機器的序號就是0。然后每次接收到一個請求，說這個機房的這個機器要生成一個id，你就找到對應的Worker，生成。
他這個算法生成的時候，會把當前毫秒放到41 bit中，然后5 bit是機房id，5 bit是機器id，接著就是判斷上一次生成id的時間如果跟這次不一樣，序號就自動從0開始；要是上次的時間跟現在還是在一個毫秒內，他就把seq累加1，就是自動生成一個毫秒的不同的序號。
這個算法那，可以確保說每個機房每個機器每一毫秒，最多生成4096個不重復的id。
利用這個snowflake算法，你可以開發自己公司的服務，甚至對于機房id和機器id，反正給你預留了5 bit + 5 bit，你換成別的有業務含義的東西也可以的。
這個snowflake算法相對來說還是比較靠譜的，所以你要真是搞分布式id生成，如果是高并發啥的，那么用這個應該性能比較好，一般每秒幾萬并發的場景，也足夠你用了。
