最近、同社はOracleからMySQLへのデータベース移行を行っています。これは、Oracleの主キー
SYS_GUID ()
がこのOracleが提供する関数を使用し て、16バイトで構成されるグローバルに一意の識別子(元の値)を生成したためです。ただし、mysqlがデフォルトで使用するInnoDBストレージエンジンが使用するクラスター化インデックスのため、uuidの使用は書き込みパフォーマンスに特定の影響を与えます。さらに、後続のサブデータベースサブテーブルの考慮事項では、データベースの自己インクリメントを使用することはお勧めできません。そのため、分散インクリメントをサポートでき、グローバルに一意のId生成アルゴリズムが必要であると考えられます。調査後、スノーフレークアルゴリズムは、Twitterによって分散されたグローバル一意IDオープンソースを生成するための古典的なアルゴリズムであり、全体的な時間の増加を保証できます。
インターネット上のスノーフレークアルゴリズムに関するほとんどの情報を確認した後、インターネット上のスノーフレークアルゴリズムについて多くの解釈があり、それらのほとんどがコピーされています。これらのチュートリアルのほとんどに2つの問題があることがわかりました。
- 公式アルゴリズムの原理を解釈するだけで、マシンID(5桁)とデータセンターID(5桁)の構成の問題を解決しません。分散配置の一意の構成を確保する方法。
- すべてのデモは、すぐに使えるツールクラスを形成せずにオブジェクトをインスタンス化する必要があり、プロジェクトと一緒に直接使用することはできません。
この記事は、上記の2つの問題を改善することを目的としており、SnowFlakeアルゴリズムを使用してプロジェクトでデータベースの主キーを生成する準備をしている私のような友人を助けたいと考えています。
概観
SnowFlakeアルゴリズムがidを生成した結果は64ビット整数であり、その構造は次のとおりです。
-
1位
、する必要がない。バイナリシステムでは、1の最上位ビットは負の数ですが、生成するIDは通常整数を使用するため、最上位ビットは0に固定されます -
41位
、タイムスタンプ(ミリ秒)を記録するために使用されます。- 41ビットは2 41 2 ^ {41}を表すことができます24 1-1番号。
- 正の整数を表すためだけに使用される場合(コンピューター内の正の数には0が含まれます)、表現できる値の範囲は次のとおりです:0から2 41 − 1 2 ^ {41} -124 1−1表現可能な値の範囲は0ではなく1から計算されるので、マイナス1です。
- つまり、41ビットは2 41 − 1 2 ^ {41} -1を表すことができます24 1−1ミリ秒の値は2 41 − 1 /(1000 ∗ 60 ∗ 60 ∗ 24 ∗ 365)= 69 2 ^ {41} -1 /(1000 * 60 * 60 * 24 * 365)= 6924 1−1 / (1 0 0 0∗6 0∗6 0∗2 4∗3 6 5 )=6 9年
-
10位
、稼働中のマシンIDを記録するために使用されます。- 2 10 = 1024で展開可能2 ^ {10} = 102421 0=
5位datacenterId
およびを含む 1 0 2 4ノード5位workerId
5位(bit)
表現できる最大の正の整数は2 5 − 1 = 31 2 ^ 5-1 = 31です。25−1=3 1、つまり、32の数値0、1、2、3、... 31は、異なるdatecenterIdまたはworkerIdを表すために使用できます
- 2 10 = 1024で展開可能2 ^ {10} = 102421 0=
-
12位
、同じミリ秒で生成された異なるIDを記録するために使用されるシリアル番号。12位(bit)
表現できる最大の正の整数は2 12 − 1 = 4095 2 ^ {12} -1 = 4095です21 2−1=4 0 9 5、つまり、0、1、2、3、... 4094などの4095の数値は、同じマシンが同じ時間(ミリ秒)で生成した4095 IDのシリアル番号を表すために使用できます。
Javaの64ビット整数はlong型であるため、JavaのSnowFlakeアルゴリズムによって生成されたIDはlongで格納されます。
SnowFlakeは次のことを保証できます。
- 生成されたすべてのIDは時間トレンドで増加します
- 分散システム全体で重複したIDはありません(区別するためのdatacenterIdとworkerIdがあるため)
話は安いです、あなたにコードを見せてください
記事の冒頭で挙げられた2つの問題に対応するために、著者の解決策は、サーバーIPを使用してworkIdとhostNameを生成し、dataCenterIdを生成することです。 、重複が発生することは避けられませんが、実際の使用では、hostNameとIPの構成は一般に連続的または類似しています。これらが正確に32ビット離れていない限り、問題はありません。また、hostNameとIPが同時に32で区切られていることはほとんど不可能です。通常、分散デプロイメントは通常100コンテナを超えません。
上記の方法では、構成がゼロのスノーフレークアルゴリズムを使用できます。スノーフレークアルゴリズムの10ビットマシンコードは、理論的には1024ノードを持つことができます。本番環境で使用されるDocker構成は、通常1回コンパイルされ、別のコンテナーに配布されるため、違いはありません。構成。複製を完全に回避できるいくつかのソリューションを次に示します。アプリケーションの起動時に、redisを使用して割り当てられたマシンコードを自動的に増やして取得できます。zkを使用してマシンコードを発行し、マシンに対応するマシンコードをzkの永続ノードの下に格納して、起動するたびに取得することもできます。ただし、これらのソリューションは両方とも構成して開発する必要があり、運用展開マシンが少なく同時実行性が少ない場合は、この記事で提供されているソリューションを使用できます。将来問題が発生した場合は、ミドルウェアを使用してマシンコードを発行するこのソリューションが採用され、その時点で補足が行われます。
完全なコードは次のとおりです。
import org.apache.commons.lang3.RandomUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.net.Inet4Address;
import java.net.UnknownHostException;
public class SnowflakeIdWorker{
private static final Logger LOGGER = LoggerFactory.getLogger(SnowflakeIdWorker.class);
/** 工作机器ID(0~31) */
private long workerId;
/** 数据中心ID(0~31) */
private long dataCenterId;
/** 毫秒内序列(0~4095) */
private long sequence = 0L;
public SnowflakeIdWorker(long workerId, long dataCenterId){
// sanity check for workerId
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));
}
LOGGER.info("worker starting. timestamp left shift = {}, dataCenter id bits = {}, worker id bits = {}, sequence bits = {}, workerid = {}, dataCenterId = {}",
timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId,dataCenterId);
this.workerId = workerId;
this.dataCenterId = dataCenterId;
}
/**初始时间戳*/
private long twepoch = 1577808000000L;
/**长度为5位*/
private long workerIdBits = 5L;
private long datacenterIdBits = 5L;
/** 支持的最大机器id,结果是31 (这个移位算法可以很快的计算出几位二进制数所能表示的最大十进制数) */
private long maxWorkerId = -1L ^ (-1L << workerIdBits);
/** 支持的最大数据标识id,结果是31 */
private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
/** 序列在id中占的位数 */
private long sequenceBits = 12L;
/** 生成序列的掩码,这里为4095 (0b111111111111=0xfff=4095) */
private long sequenceMask = -1L ^ (-1L << sequenceBits);
//工作id需要左移的位数,12位
private long workerIdShift = sequenceBits;
//数据id需要左移位数 12+5=17位
private long datacenterIdShift = sequenceBits + workerIdBits;
//时间戳需要左移位数 12+5+5=22位
private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
//上次时间戳,初始值为负数
private long lastTimestamp = -1L;
private static SnowflakeIdWorker idWorker;
static {
idWorker = new SnowflakeIdWorker(getWorkId(),getDataCenterId());
}
/**
* 获得下一个ID (该方法是线程安全的)
* @return SnowflakeId
*/
public synchronized long nextId() {
long timestamp = timeGen();
//获取当前时间戳如果小于上次时间戳,则表示时间戳获取出现异常
if (timestamp < lastTimestamp) {
LOGGER.error("clock is moving backwards. Rejecting requests until : {}.", lastTimestamp);
throw new RuntimeException(String.format("Clock moved backwards. Refusing to generate id for %d milliseconds",
lastTimestamp - timestamp));
}
//获取当前时间戳如果等于上次时间戳(同一毫秒内),则在序列号加一;否则序列号赋值为0,从0开始。
if (lastTimestamp == timestamp) {
sequence = (sequence + 1) & sequenceMask;
// 毫秒内序列溢出
if (sequence == 0) {
timestamp = tilNextMillis(lastTimestamp);
}
} else {
sequence = 0;
}
//将上次时间戳值刷新
lastTimestamp = timestamp;
/**
* 返回结果:
* (timestamp - twepoch) << timestampLeftShift) 表示将时间戳减去初始时间戳,再左移相应位数
* (datacenterId << datacenterIdShift) 表示将数据id左移相应位数
* (workerId << workerIdShift) 表示将工作id左移相应位数
* | 是按位或运算符,例如:x | y,只有当x,y都为0的时候结果才为0,其它情况结果都为1。
* 因为个部分只有相应位上的值有意义,其它位上都是0,所以将各部分的值进行 | 运算就能得到最终拼接好的id
*/
return ((timestamp - twepoch) << timestampLeftShift) |
(dataCenterId << datacenterIdShift) |
(workerId << workerIdShift) |
sequence;
}
/**
* 阻塞到下一个毫秒,直到获得新的时间戳
* @param lastTimestamp 上次生成ID的时间截
* @return 当前时间戳
*/
private long tilNextMillis(long lastTimestamp) {
long timestamp = timeGen();
while (timestamp <= lastTimestamp) {
timestamp = timeGen();
}
return timestamp;
}
/**
* 返回以毫秒为单位的当前时间
* @return 当前时间(毫秒)
*/
private long timeGen(){
return System.currentTimeMillis();
}
private static Long getWorkId(){
try {
String hostAddress = Inet4Address.getLocalHost().getHostAddress();
char[] chars = hostAddress.toCharArray();
int sums = 0;
for(int b : chars){
sums += b;
}
return (long)(sums % 32);
} catch (UnknownHostException e) {
// 如果获取失败,则使用随机数备用
return RandomUtils.nextLong(0,31);
}
}
private static Long getDataCenterId(){
try {
char[] chars = Inet4Address.getLocalHost().getHostName().toCharArray();
int sums = 0;
for (int i: chars) {
sums += i;
}
return (long)(sums % 32);
} catch (UnknownHostException e) {
// 如果获取失败,则使用随机数备用
return RandomUtils.nextLong(0,31);
}
}
/**
* 静态工具类
*
* @return
*/
public static Long generateId(){
long id = idWorker.nextId();
return id;
}
/** 测试 */
public static void main(String[] args) {
System.out.println(System.currentTimeMillis());
long startTime = System.nanoTime();
for (int i = 0; i < 50000; i++) {
long id = SnowflakeIdWorker.generateId();
LOGGER.info("id = {}",id);
}
LOGGER.info((System.nanoTime()-startTime)/1000000+"ms");
}
}
拡大する
このアルゴリズムを理解した後、実際にできる拡張機能がいくつかあります。
- 理論的には、41ビットレコードのタイムスタンプは69年を表すことができ、タイムスタンプは1970年から計算されます。現時点では、1970年から2019年までのミリ秒数は使用できなくなったため、初期時間参照ポイントを設定できます(通常、idジェネレーターが使用を開始する時間に設定されます)、タイムスタンプの差(現在の時間のカットオフ開始時間のカットオフ)を計算します。このようにして、タイムスタンプの範囲を拡張できます。
- IDを復号化します。IDの各セグメントには特定の情報が格納されているため、IDを取得すると、各セグメントの元の情報を元に戻すことができるはずです。アンチ紹介情報は、分析に役立ちます。たとえば、注文として、注文が生成された日付、処理を担当するデータセンターなどを知ることができます。
- アルゴリズムでマシンIDを生成する戦略を改善し、さらにzk分布またはredis自己増分などを採用して、完全に衝突のないID生成を実現します。
- 自分のビジネスに応じて、各ビットセグメントに格納されている情報を変更します。アルゴリズムは普遍的であり、必要に応じて各セグメントのサイズと格納される情報を調整できます。
参考資料:
アルゴリズムではビット演算が広く使用されているため、それについてよく知らない場合は、この分析を参照できます