Snowflake生成全局惟一ID的改進

爲何要改進Twitter_Snowflake算法呢？開始我是以爲原來的設計可能會生成的ID長度不是固定的，和設置的起始時間也有關係，並且服務還要配置這個起始時間，根據當前時間減去起始時間放入41位的時間戳裏面，因此生成的ID的長度依賴於這個起始時間，從使用者的角度，可用性不是很清晰。我想生成的ID是長度固定的，否則在用戶使用來講會很奇怪。

由於由於最大2的63次方-1，是個18位數 我看最小的18位是 ：

1101111000 0010110110 1011001110 1001110110 0100000000 0000000000
這個數還不到63位，因此在64位數前面的01就能肯定位數啦。

還有原來設置了workId和datacenterId，每一個佔據了5位，能夠用於配置多機房的某個機器，那就是32個機房，每一個機房配置32臺機器，這樣我感受不靈活，好比，根據業務發展，就是有的機房須要配置40臺，可是有的機房就是隻須要5臺，因此我以爲這10位合併一下，能夠表示1024臺機器，可是至於什麼機房的哪一臺機器，這個關係能夠配置在其餘地方，在發號器裏面配置Id，將這兩塊的邏輯解偶，考慮到通常中小企業也不會有那麼多臺機器要配置吧，我以爲7位128就已經夠了，除去去了前面的01佔位符，保持12位的序列不變，那麼時間戳位數就有了43位，比起原來的69年*2*2，因此有這個時間的範圍，去掉原來的起始時間設置也是合理的。

而後如下這個類的屬性的定義就是以下了：

而後主要的實現邏輯：

/**
 * 改過的SnowFlake的結構以下(每部分用-分開):
 * 01 - 0000000000 0000000000 0000000000 0000000000 000 - 0000000 - 000000000000 <br>
 * 1位標識，最高位是0<br>
 * 標識位後的1肯定位數
 * 41位時間截(毫秒級)，注意，43位時間截不是存儲當前時間的時間截 69*2*2 年
 * 7位的數據機器位，來肯定是一臺機器，128臺通常也夠用啦
 * 12位序列，毫秒內的計數，12位的計數順序號支持每一個節點每毫秒(同一機器，同一時間截)產生4096個ID序號<br>
 * 加起來恰好64位，爲一個Long型。
 */

git地址：https://github.com/woshiyexinjie/zootopia