snowflakeアルゴリズムに基づいてSequenceのRestサービスを実現した
2748 ワード
まずSnowflakeについて簡単に話します.snowflakeはTwitterからのオープンソースアルゴリズムです.githubにはありますが、ソースコードが見つかりません.今は公有的なサービスのようですが、卵を並べています.他の人は壁の外にいます.私たちはやはりそのアルゴリズムを話しています.snowflakeはint 64でシーケンス番号を表しています.私たちのタイムスタンプに似ていますが、その始まりは1970年ではありません.カスタマイズされています.あなたは間違っていません.カスタマイズされています.そして、タイムスタンプには現在のミリ秒とカスタマイズされた元年の時間差が記録されています.そうすれば、最初は64ビット未満のbitでタイムスタンプ全体を記録することができます.多くの人は他のことをすることができます.次の構造を見ることができます.
セグメント1:42 bitタイムスタンプ
現在の時刻と元年の時間差を記録していますが、sequenceを入手した後、元年の時刻さえ分かれば、sequenceの生成時刻を推定することができますし、createTimeも含まれていますので、もちろんソートにも使えます
セグメント2:5 bitデータセンターIdタグ
記録されているのはデータセンターのIdで、5 bitは最大32のデータセンターを表すことができて、このような多くのデータセンターは全世界の範囲内のサービスが利用できることを保証することができます
セグメント3:5 bitノードタグ
記録されているのは、単一のデータセンター内のサービスノードのIdであり、同様に最大32個のノードがあり、これはデータセンター全体がオフラインでない限り、サービスが永遠に利用できることを保証することができる.
第四段:12 bit単ミリ秒内の自増流水
1つのサービスノードが高同時対応の場合、1ミリ秒以内にsequenceを複数回要求する場合に用いるため、1ミリ秒以内に1つの自増区間を増やしてバッファリングを行い、12 bitは最大4095まで表示することができるが、これは基本的に1ミリ秒ごとに4000回以上並列されているので、この同時の場合、会社も投入を増やすことになるだろう.だから基本的にこの問題を心配する必要はありません.
以上がsnowflakeのデータ構造の核心であり、4段を組み合わせるとちょうど64 bitであり、1つの長い整数型データは、時間を表現することができ、ソートにも便利であり、もちろん絶対ソートはできないが、相対的にソートし、基本的には粒子度がミリ秒級であれば、許容できる.また42ビットのタイムスタンプは170年以上の時間差を保証することができ、現在のソフトウェアサイクルで見ると、10年も使えるのはよくない.100年後、コンピュータがどうなっているかは誰が知っているだろうか.少なくとも今は十分で、後で128ビットに拡張しても問題ない.
私自身の実現はこの構造を少し変更しました.構造は以下の通りです.第1部はタイムスタンプですが、範囲がもっと広い です.で示されている単ミリ秒内の自己増水は、私は10 bitに縮小し、最大1ミリ秒以内に1024個の流水番号の生成をサポートすることができ、実際には も高い.はデータセンターのIdタグを削除し、ノードタグを保持して拡大し、最大255個のノード をサポートする.
具体的なコードはcfsequenceで、自分でダウンロードして、そしてコンパイルして使用することができて、具体的なREST API、READMEを参考することができます.md
ご意見をどうぞ
00000.....000 00000 00000 000000000000
|___________| |___| |___| |__________|
| | | |
42bit 5bit 5bit 12bit
セグメント1:42 bitタイムスタンプ
現在の時刻と元年の時間差を記録していますが、sequenceを入手した後、元年の時刻さえ分かれば、sequenceの生成時刻を推定することができますし、createTimeも含まれていますので、もちろんソートにも使えます
セグメント2:5 bitデータセンターIdタグ
記録されているのはデータセンターのIdで、5 bitは最大32のデータセンターを表すことができて、このような多くのデータセンターは全世界の範囲内のサービスが利用できることを保証することができます
セグメント3:5 bitノードタグ
記録されているのは、単一のデータセンター内のサービスノードのIdであり、同様に最大32個のノードがあり、これはデータセンター全体がオフラインでない限り、サービスが永遠に利用できることを保証することができる.
第四段:12 bit単ミリ秒内の自増流水
1つのサービスノードが高同時対応の場合、1ミリ秒以内にsequenceを複数回要求する場合に用いるため、1ミリ秒以内に1つの自増区間を増やしてバッファリングを行い、12 bitは最大4095まで表示することができるが、これは基本的に1ミリ秒ごとに4000回以上並列されているので、この同時の場合、会社も投入を増やすことになるだろう.だから基本的にこの問題を心配する必要はありません.
以上がsnowflakeのデータ構造の核心であり、4段を組み合わせるとちょうど64 bitであり、1つの長い整数型データは、時間を表現することができ、ソートにも便利であり、もちろん絶対ソートはできないが、相対的にソートし、基本的には粒子度がミリ秒級であれば、許容できる.また42ビットのタイムスタンプは170年以上の時間差を保証することができ、現在のソフトウェアサイクルで見ると、10年も使えるのはよくない.100年後、コンピュータがどうなっているかは誰が知っているだろうか.少なくとも今は十分で、後で128ビットに拡張しても問題ない.
私自身の実現はこの構造を少し変更しました.構造は以下の通りです.
000000....00000 0000000000 00000000
|_____________| |________| |______|
| | |
46bit 10bit 8bit
具体的なコードはcfsequenceで、自分でダウンロードして、そしてコンパイルして使用することができて、具体的なREST API、READMEを参考することができます.md
ご意見をどうぞ