序文
リレーショナル データベース内のデータ量が多すぎる場合、通常、データベース テーブルの検索の負荷を軽減するためにサブデータベースとテーブルが使用されます。サブデータベースやテーブルにはさまざまな種類があり、1 つのデータベースに分割されて複数のテーブルを持つものや、複数のデータベースと複数のテーブルに分割されるものもあります。一般に、ShardingSphere は、データベースやテーブルのシャーディング、シャーディング キーの作成などに使用されます。しかし、データベースをテーブルに分割した後、主キー ID はどのように処理すればよいでしょうか?同じビジネス テーブルの異なるシャード テーブルの主キー ID を同じにすることはできません。実際、これはデータベースとテーブルをシャーディングした後に直面する必要がある問題、つまり主キー ID をどのように生成するかということです。複数のテーブルに分割され、各テーブルが 1 から累積し始める場合、それは明らかに間違っており、これをサポートするにはグローバルに一意の ID が必要です。したがって、これらはすべて実際の運用環境で考慮する必要がある問題です。
以下は、私がコンパイルした主キー ID を処理するいくつかの方法です。
1. 主キーIDを自動生成
このメソッドは通常、主キーを bitint タイプに設定し、自動インクリメントします。ビジネスの観点から見ると、複数のサブテーブルのデータは特定のビジネスを構成するため、主キーの競合は許可されません。
主キー ID を自動生成するソリューションを使用する場合、複数の固定サブテーブルをセットアップできます。各サブテーブルの開始点は異なり、新しい追加のステップ サイズは次のようになります。各サブテーブルの主キーが競合しないことが保証できるように、同じです。
データベースシーケンスまたはテーブルの自動インクリメントフィールドステップサイズを設定することにより、水平スケーリングを実行できます。現在、サービス ノードは 10 個あります。各サービス ノードはシーケンス関数を使用して ID を生成します。各シーケンスの開始 ID は異なり、ステップ サイズ 10 で順番に増加します。
たとえば、特定のテーブルに 10 個のサブテーブルがある場合、各テーブルの開始主キー ID を 1 から 10 まで設定でき、各サブテーブルの主キー ID の増分ステップは 10 です。
| テーブル名 | 開始主キー ID | 刻み幅 |
|---|---|---|
| 表1 | 1 | 10 |
| テーブル_2 | 2 | 10 |
| テーブル_3 | 3 | 10 |
| テーブル_4 | 4 | 10 |
| テーブル_5 | 5 | 10 |
| テーブル_6 | 6 | 10 |
| テーブル_7 | 7 | 10 |
| テーブル_8 | 8 | 10 |
| テーブル_9 | 9 | 10 |
| テーブル_10 | 10 | 10 |
上記のサブテーブルの主キーの増加ルールに従って、各テーブルの行数は次のように増加します。
主キーの増分形式に従うことには欠点があります。つまり、新しいテーブルを追加するときに主キーのロジックを処理するのが難しいということです。主キー ID をインクリメントするこの方法は、サブテーブルが比較的固定されている状況に適しています。
2. 主キーとしての UUID
利点は、UUID がデータベースに基づいて生成されず、ローカルで生成されることです。欠点は、UUID が長すぎて多くのスペースを占有することです。UUID としてのパフォーマンス主キーが貧弱すぎる< a i=2>; さらに重要なのは、UUID が順序付けされていないため、B+ ツリー インデックスを書き込むときにランダムな書き込み操作が多すぎる原因になります (連続 ID では部分的なシーケンシャル書き込みが発生する可能性があります)。書き込み時、順次追加操作は生成できませんが、挿入操作が必要です。B+ ツリー ノード全体がメモリに読み込まれます。このレコードを挿入した後、ノード全体がディスクに書き戻されます。この操作は、レコード内でより多くのスペースを占有し、大規模な場合にはパフォーマンスが大幅に低下します。
適切なシナリオ: ファイル名、番号などをランダムに生成する場合は、UUID を使用できますが、UUID を主キーとして使用することはできません。
UUID.randomUUID().toString().replace("-", "") -> sfsdf23423rr234sfdaf3. 現在のシステム時刻を取得する
これは現在の時刻を取得するだけですが、問題は同時実行数が非常に高い場合（1 回あたりの同時実行数が数千件など）です。 2 番目に、 a>重複が発生しますが、これは明らかに不適切です。基本的には考える必要はありません。
適切なシナリオ: 一般に、このソリューションを使用すると、現在時刻を他の多くのビジネス分野と ID としてつなぎ合わせることになりますが、ビジネス上許容されると思われる場合は、それも許容されます。他のビジネス フィールドの値を現在の時刻と連結して、グローバルに一意の数値を形成できます。
4. スノーフレーク アルゴリズム スノーフレーク
(1) 1 つのプレースホルダー: デフォルトは 0 です。最上位ビットは正と負を表し、1 は負の数、0 は正の数を表し、デフォルトは正の数です。
(2) 41 ビット タイムスタンプ: ミリ秒レベルの時刻、69 年間保存可能、(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69 年
(3) 5 桁のワーク センター ID: 10 進数の範囲は 0 ～ 31、5 桁のデータ センター ID: 10 進数の範囲は 0 ～ 31。 2 つを組み合わせると、最大 1024 ノードを収容できます。
(4) シリアル番号: 12 ビットを占有し、最大 4095 まで累積できます。自己増加値は、同じノードが同じミリ秒内に 4096 個の ID を生成できることをサポートしており、この値は同じノード上で同じミリ秒内に 0 から蓄積され続けます。 (単一ノードで最大約 400 万の同時実行をサポートできます)
スノーフレーク アルゴリズムは、Scala 言語で実装された Twitter のオープン ソースの分散 ID 生成アルゴリズムです。64 ビット長の ID を受け取り、1 ビットは使用されず、ミリ秒として 41 ビットを使用し、作業マシンとして 10 ビットを使用します。シリアル番号として 12 ビット。
•1 ビット: いいえ、なぜですか?バイナリの最初のビットは 1 であるため、すべて負の数になりますが、生成する ID はすべて正の数であるため、最初のビットは一律に 0 になります。
•41 ビット: タイムスタンプを表し、単位はミリ秒です。 41 ビットは最大 2^41 - 1 桁を表すことができ、 2^41 - 1 ミリ秒の値を識別できます。大人に換算すると 69 年を表します。
・10 ビット: 動作中のマシン ID を記録します。これは、このサービスを最大 2^10 のマシン、つまり 1024 台のマシンに展開できることを意味します。ただし、10 ビットのうち 5 ビットはコンピュータ室 ID を表し、5 ビットはマシン ID を表します。これは、最大 2^5 コンピューター ルーム (32 コンピューター ルーム) を表すことができ、各コンピューター ルームは 2^5 マシン (32 マシン) を表すことができることを意味します。
•12 ビット: 同じミリ秒内に生成された異なる ID を記録するために使用されます。12 ビットで表現できる最大の正の整数は 2^12 - 1 = 4096 です。つまり、この 12 ビットは次のとおりです。使用されている数値は、同じミリ秒内で 4096 個の異なる ID を区別します。
0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 1 1001 | 0000 00000000public 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;
// 这个是二进制运算，就是 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();
}
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));
}
if (lastTimestamp == timestamp) {
// 这个意思是说一个毫秒内最多只能有4096个数字
// 无论你传递多少进来，这个位运算保证始终就是在4096这个范围内，避免你自己传递个sequence超过了4096这个范围
sequence = (sequence + 1) & sequenceMask;
if (sequence == 0) {
timestamp = tilNextMillis(lastTimestamp);
}
} else {
sequence = 0;
}
// 这儿记录一下最近一次生成id的时间戳，单位是毫秒
lastTimestamp = timestamp;
// 这儿就是将时间戳左移，放到 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());
}
}
}何と言いますか? おそらくこれは、41 ビットが現在のミリ秒単位のタイムスタンプであり、それが意味することです。そして、5 ビットが渡されたものであることを意味します。コンピュータ ルーム ID (ただし、最大値は 32 以内のみ)、残りの 5 ビットは machine に渡したものです。 ID (ただし、最大数は 32 以内のみ)、残りの 12 ビットのシリアル番号は、最後に ID を生成してから 1 ミリ秒以内であれば、シーケンスが蓄積されることを意味します。 、最大 4096 個のシリアル番号。
このツールクラスを使って自分でサービスを作り、それを各計算機室のマシンごとに初期化するのですが、この計算機室のマシンのシリアル番号は最初は0です。その後、このコンピュータ室のこのマシンが ID を生成する必要があるというリクエストを受け取るたびに、生成する対応するワーカーが見つかります。
このスノーフレークアルゴリズムを利用することで自社サービスを開発することができ、計算機室IDやマシンIDも5ビット+5ビットは自分専用に確保されているので、ビジネス上の意味のあるものに変更することも可能です。
このスノーフレーク アルゴリズムは比較的信頼性が高いため、分散 ID の生成に実際に取り組んでいる場合、同時実行性が高い場合は、これを使用するとパフォーマンスが向上するはずです。一般に、1 秒あたり数万の同時実行シナリオを使用するには十分です。 . .
要約:
上記の ID 生成アルゴリズム以外にも、もちろん整理されていない主キー ID 生成アルゴリズムがあり、具体的にどのアルゴリズムを使用するかはビジネスの状況に応じて使い分ける必要があります。