シャーディングのための 9 つの分散主キー ID 生成ソリューション

[[351290]]

この記事はWeChatの公開アカウント「Programmer's Insider Things」から転載したもので、著者はProgrammer's Insider Thingsです。この記事を転載する場合は、Programmer Insider 公式アカウントまでご連絡ください。

どのようなテクノロジーを導入するにもリスクは伴いますが、シャーディングも例外ではありません。データベースとテーブル内のデータ量が、既存の高可用性アーキテクチャでサポートできなくなるほど増加し続けない限り、データベースとテーブルをシャードすることはお勧めしません。なぜなら、データシャーディングを行うと、落とし穴に陥ることになりますが、分散主キー ID が最初に遭遇する落とし穴だからです。

異なるデータノード間でグローバルに一意の主キーを生成することは難しい問題です。論理テーブル t_order は複数の実テーブル t_order_n に分割され、異なるシャードライブラリ db_0、db_1 などに分散されます。各実テーブルの自動インクリメントキーは互いを認識できないため、主キーが重複します。現時点では、データベース自体の自動増分主キーは、シャードライブラリとテーブルの主キーのグローバル一意性要件を満たすことができません。

 db_0 --  
   | -- t_order_0  
   | -- t_order_1  
   | -- t_order_2  
 db_1 --  
   | -- t_order_0  
   | -- t_order_1  
   | -- t_order_2

各シャードテーブルの自己増分主キーの初期値とステップサイズを厳密に制約することで重複 ID の問題を解決できますが、これにより運用および保守コストが大幅に増加し、スケーラビリティが極めて悪くなります。シャードテーブルの数を拡張する必要がある場合、元のテーブルのデータが大幅に変更されるため、この方法はお勧めできません。

ステップサイズ step = サブテーブルの数
 
 db_0 --  
   | -- t_order_0 ID: 0、6、12、18...  
   | -- t_order_1 ID: 1、7、13、19...  
   | -- t_order_2 ID: 2、8、14、20...  
 db_1 --  
   | -- t_order_0 ID: 3、9、15、21...  
   | -- t_order_1 ID: 4、10、16、22...  
   | -- t_order_2 ID: 5、11、17、23...

この問題を完全に解決できるサードパーティのソリューションはすでに数多く存在します。たとえば、UUID、SNOWFLAKE アルゴリズム、セグメント番号セグメントに基づいて、特定のアルゴリズムを使用して一意のキーを生成したり、Meituan (Leaf) や Didi (TinyId) などの主キー生成サービスを直接参照したりします。

Sharding-jdbc には、UUID と SNOWFLAKE という 2 つの分散主キー生成スキームが組み込まれています。また、分散主キージェネレーターのインターフェイスを抽出し、開発者がカスタム主キージェネレーターを実装できるようにします。後ほど、Didi の主キー生成サービス (TinyId) をカスタムジェネレータに接続します。

前述のように、sharding-jdbc のフィールドの主キー ID を自動的に生成する場合は、application.properties ファイルで次の構成を行うだけです。

 # 主キーフィールド
spring.shardingsphere.sharding.tables.t_order。キージェネレーター。列= 注文ID
 # 主キーID生成スキーム
spring.shardingsphere.sharding.tables.t_order。キー-generator.type=UUID
 # ワーカーマシンID
 spring.shardingsphere.sharding.tables.t_order。キー-generator.props.worker.id=123

key-generator.column は主キーフィールドを示し、key-generator.type は主キー ID 生成スキーム (組み込みまたはカスタム) を示し、key-generator.props.worker.id はマシン ID を示します。主キー生成スキームが SNOWFLAKE に設定されている場合、マシン ID はビット単位の演算に参加します。

sharding-jdbc 分散主キーを使用する場合、注意すべき点が 2 つあります。

挿入操作のエンティティオブジェクトの主キーフィールドに値が割り当てられると、主キー生成スキームが構成されている場合でも無効になり、最終的な SQL によって実行されるデータは割り当てられた値に基づきます。
主キーフィールドに自動増分属性を設定しないでください。そうしないと、主キー ID がデフォルトの SNOWFLAKE モードで生成されます。たとえば、MyBatis Plus の @TableId アノテーションを使用して order_id フィールドに自動インクリメントの主キーを設定すると、この時点でどのスキームが設定されていても、常にスノーフレークアルゴリズムに従って生成されます。
次に、sharding-jdbc の組み込み主キー生成スキーム UUID と SNOWFLAKE がソースコードからどのように実装されているかを分析します。

言語

UUID 型主キー生成実装クラス UUIDShardingKeyGenerator のソースコードを開くと、その生成ルールには UUID.randomUUID() という 1 行のコードしかないことがわかりました。え～っと、心の中でうわーって思いました。

UUID はグローバルな一意性を実現できますが、実際の業務では、user_id であれ order_id であれ、主キーはほとんどが整数であり、UUID は 32 ビットの文字列を生成するため、主キーとして使用することは推奨されません。

そのストレージとクエリは MySQL のパフォーマンスを大量に消費し、MySQL の担当者も主キーをできるだけ短くすることを明確に推奨しています。データベースの主キーとしての UUID の乱れも、データの場所の頻繁な変更を引き起こし、パフォーマンスに重大な影響を与えます。

パブリックファイナルクラスUUIDShardingKeyGeneratorはShardingKeyGeneratorを実装します{
    プライベートプロパティプロパティ = 新しいプロパティ(); 
 
パブリックUUIDShardingKeyGenerator() {
    } 
 
パブリック文字列getType() {
戻る  「UUID」 ;
    } 
 
パブリック同期Comparable<?> generateKey() {
 UUID.randomUUID().toString().replaceAll( "-" , "" )を返します。
    } 
 
パブリックプロパティ getProperties() {
 this.propertiesを返します。
    } 
 
パブリックvoid setProperties(プロパティ プロパティ) {
        this.properties = プロパティ;
    }
 }

スノーフレーク

SNOWFLAKE (スノーフレークアルゴリズム) は、64 ビットの長整数 (Long) データを生成するデフォルトの主キー生成スキームです。

sharding-jdbc のスノーフレークアルゴリズムによって生成される主キーは、主に 1 ビットの符号ビット、41 ビットのタイムスタンプビット、10 ビットの作業プロセスビット、および 12 ビットのシーケンス番号ビットの 4 つの部分で構成されます。

符号ビット（1ビット）

Java の Long 型の最上位ビットは符号ビットで、正の数の場合は 0、負の数の場合は 1 になります。通常、生成される ID は正の数なので、デフォルト値は 0 です。

タイムスタンプビット（41ビット）

41 ビットのタイムスタンプが保持できるミリ秒数は 2 の 41 乗であり、1 年間の合計ミリ秒数は 1000L * 60 * 60 * 24 * 365 となり、約 69 年に相当します。まあ、私の人生にはそれで十分です。

 Math.pow(2, 41) / (365 * 24 * 60 * 60 * 1000L) = = 69年

作業工程ビット（10ビット）

一意のワーカープロセス ID を表します。デフォルト値は 0 で、key-generator.props.worker.id プロパティを介して設定できます。

 spring.shardingsphere.sharding.tables.t_order。キー-generator.props.worker.id=0000

シリアル番号ビット（12ビット）

同じミリ秒内に異なる ID が生成されます。

時計を戻す

スノーフレークアルゴリズムの主キー ID の構成を理解すると、これがサーバー時間に大きく依存するアルゴリズムであることは容易にわかります。サーバー時間に依存すると、クロックのダイヤルバックという厄介な問題が発生します。

なぜ時計は戻るのでしょうか?

インターネットには ntp (Network Time Protocol) と呼ばれるネットワークタイムプロトコルがあり、これは特にネットワーク内の各コンピューターの時間を同期および調整するために使用されます。

そのため、携帯電話の時刻を手動で確認する必要はなくなりましたが、誰の携帯電話の時刻も同じままです。

ハードウェアクロックは、さまざまな理由により不正確になる (速くなるか遅くなる) 場合があります。このとき、時刻調整を実行するには ntp サービスが必要です。キャリブレーション中に、サーバーのクロックがジャンプしたり、戻ったりする場合があります。

スノーフレークアルゴリズムは時計の巻き戻しの問題をどのように解決するのでしょうか?

サーバークロックのダイヤルバックにより、ID が重複する可能性があります。 SNOWFLAKE ソリューションは、最大許容クロックダイヤルバックミリ秒を追加することで、元のスノーフレークアルゴリズムを改善します。

クロックのダイヤルバック時間が最大許容ミリ秒しきい値を超えると、プログラムは直接エラーを報告します。許容範囲内であれば、デフォルトの分散主キージェネレーターは、クロックが最後の主キー生成の時刻に同期されるまで待機してから、作業を続行します。

許容される最大クロックセットバック（ミリ秒単位）。デフォルト値は 0 で、プロパティ max.tolerate.time.difference.milliseconds を介して設定できます。

 # 時計のダイヤルバックの最大許容ミリ秒数
spring.shardingsphere.sharding.tables.t_order.key - generator.max.tolerate.time.difference.milliseconds = 5

ソースコード実装クラス SnowflakeShardingKeyGenerator を見てみましょう。コアプロセスは次のとおりです。

主キーが最後に生成された時刻 (lastMilliseconds) が現在の時刻 (currentMilliseconds) と比較されます。 lastMilliseconds > currentMilliseconds の場合、クロックがコールバックされたことを意味します。

次に、2 つの時間の差 (timeDifferenceMilliseconds) が、設定された最大許容時間しきい値 max.tolerate.time.difference.milliseconds 以内であるかどうかを判断します。しきい値内の場合、スレッドは差分時間 Thread.sleep(timeDifferenceMilliseconds) の間スリープします。それ以外の場合、差より大きい場合は例外が直接報告されます。

 /**
 * @著者 xiaofu
 */
パブリック最終クラス SnowflakeShardingKeyGenerator は ShardingKeyGenerator を実装します{
    @ゲッター
    @セッター
    プライベートプロパティプロパティ = 新しいプロパティ(); 
     
パブリック文字列getType() {
戻る  「スノーフレーク」 ;
    } 
     
パブリック同期Comparable<?> generateKey() {
     /**
      * 現在のシステム時間（ミリ秒）
      */
        現在のミリ秒を長くするには、timeService.getCurrentMillis() を使用します。
        /**
         * 許容時間差を待つ必要があるかどうかを判断します。必要に応じて、時間差が経過するのを待ってから現在のシステム時間を取得します。
         */
        if (waitTolerateTimeDifferenceIfNeed(currentMilliseconds)) {
            現在のミリ秒 = timeService.getCurrentMillis();
        }
        /**
         * 最後のミリ秒が現在のシステム時間のミリ秒と同じである場合、それらはまだ同じミリ秒以内であることを意味します。
         */
        if (lastMilliseconds == currentMilliseconds) {
         /**
          * & ビット AND 演算子: 両方の数値がバイナリに変換されます。対応するビットが1の場合、結果は1、それ以外の場合は0になります。
          * シーケンスが4095の場合、4095+1後の新しいシーケンスとマスク間のビット単位のAND演算の結果は0になります。
          * シーケンスが他の値の場合、ビットAND演算の結果は0になりません。
          * つまり、現在のミリ秒シーケンスは最大値 4096 を使い果たしており、次のミリ秒の時間値が必要になります。
          */
            if (0L == (シーケンス= (シーケンス+ 1) & SEQUENCE_MASK)) {
                現在のミリ秒 = 次の時間まで待機します(現在のミリ秒);
            }
        }それ以外{
         /**
          * 最後のミリ秒が経過したら、シーケンス値を1にリセットします
          */
            振動シーケンスオフセット();
シーケンス= シーケンスオフセット;
        }
        最後のミリ秒 = 現在のミリ秒; 
         
        /**
         * XX......XX XX000000 00000000 00000000 時間差XX
         * XXXXXX XXXX0000 00000000 マシンID XX
         * XXXX XXXXXXXX シリアル番号 XX
         * 3つの部分はビットごとにOR演算されます。対応するビットがすべて0の場合、結果は0になり、それ以外の場合は1になります。
         */
戻り値((currentMilliseconds - EPOCH) << TIMESTAMP_LEFT_SHIFT_BITS) | (getWorkerId() << WORKER_ID_LEFT_SHIFT_BITS) |順序;
    } 
     
    /**
     * 許容時間差を待つかどうかを決定する
     */
    フォロー
    プライベートブールwaitTolerateTimeDifferenceIfNeed(final long currentMilliseconds) {
     /**
      * IDが最後に取得された時刻が現在のシステム時間（ミリ秒単位）以下である場合は正常であり、待つ必要はありません。
      */
        （最後のミリ秒 <= 現在のミリ秒）の場合{
戻る 間違い;
        }
        /**
         * ===> 時計のダイヤルバック（シーケンス生成の時間が現在のシステム時間よりも大きい）の場合、時間差を待つ必要があります。
         */
        /**
         * ID取得時の最後のミリ秒と現在のシステム時間ミリ秒間の時間差
         */
        long timeDifferenceMilliseconds = lastMilliseconds - currentMilliseconds;
        /**
         * 時間差は最大許容時間差より小さい、つまり現在の時間差は時計のダイヤルバック時間差の範囲内である
         */
        前提条件.checkState(timeDifferenceMilliseconds < getMaxTolerateTimeDifferenceMilliseconds(),
 「時計は逆方向に動いています。前回の時刻は %d ミリ秒、現在の時刻は %d ミリ秒です」 、lastMilliseconds、currentMilliseconds);
        /**
         * スレッドスリープ時間差
         */
        スレッドをスリープ状態にします。
戻る 真実;
    } 
     
    //設定されたマシンID
    プライベートlong getWorkerId() {
        long 結果 = Long.valueOf(properties.getProperty( "worker.id" 、 String.valueOf(WORKER_ID)));
        前提条件.checkArgument(結果 >= 0L && 結果 < WORKER_ID_MAX_VALUE);
結果を返します。
    } 
     
    プライベートint getMaxTolerateTimeDifferenceMilliseconds() {
戻る 整数.valueOf(properties.getProperty( "max.tolerate.time.difference.milliseconds" , String.valueOf(MAX_TOLERATE_TIME_DIFFERENCE_MILLISECONDS)));
    } 
     
    プライベート long waitUntilNextTime(final long lastTime) {
        長い結果 = timeService.getCurrentMillis();
        （結果<= lastTime）の間{
            結果 = timeService.getCurrentMillis();
        }
結果を返します。
    }
 }

しかし、SNOWFLAKE ソリューションによって生成された主キー ID では、order_id は 18 桁の長整数になります。長すぎると思いますか? MySQL のように 0 から増加する自動増分主キーを実装するにはどうすればよいでしょうか?心配しないでください。解決策は後で示されます。

カスタム

Sharding-jdbc は、SPI (サービスプロバイダーインターフェイス) メカニズムを使用して、主キー生成ルールを拡張します。これは、プロジェクトパス META-INF/services の下のファイルをスキャンし、ファイルで定義されているクラスを自動的にロードするサービス検出メカニズムです。

カスタム主キージェネレーターの実装は実際には非常に簡単で、必要な手順は 2 つだけです。

最初のステップは、ShardingKeyGenerator インターフェイスを実装し、その内部メソッドを書き換えることです。ここで、getType() メソッドはカスタム主キー生成スキームタイプであり、generateKey() メソッドは主キーを生成するための特定のルールです。

次のコードでは、AtomicInteger を使用して、順序付けられた自己増加 ID の生成をシミュレートします。

 /**
 * @著者: xiaofu
 * @説明: カスタム主キージェネレーター
 */
 @成分
パブリッククラス MyShardingKeyGenerator は ShardingKeyGenerator を実装します { 
 
 
    プライベート最終AtomicInteger count = new AtomicInteger(); 
 
    /**
     * カスタム生成スキームタイプ
     */
    @オーバーライド
パブリック文字列getType() {
戻る  「XXX」 ;
    } 
 
    /**
     * コアメソッド - 主キーIDを生成する
     */
    @オーバーライド
パブリックComparable<?> generateKey() {
戻る カウント.incrementAndGet();
    } 
 
    @オーバーライド
パブリックプロパティ getProperties() {
戻る ヌル;
    } 
 
    @オーバーライド
パブリックvoid setProperties(プロパティ プロパティ) { 
 
    }
 }

2 番目のステップは、SPI メカニズムを使用して機能拡張を実現することです。そのため、META-INF/services ファイルでカスタム主キージェネレーターのクラスパスを構成する必要があります。

 com.xiaofu.sharding.キー.MyShardingKeyGenerator

上記が完了したら、テストを行い、定義済みの主キー生成タイプ XXX を設定し、いくつかのデータを挿入して効果を確認してみましょう。

 spring.shardingsphere.sharding.tables.t_order。キージェネレーター。列= 注文ID
 spring.shardingsphere.sharding.tables.t_order。キー-generator.type=XXX

コンソールの SQL 解析ログを見ると、order_id フィールドが順序付けられた自己増加方式でレコードに挿入されており、構成が正しいことがわかります。

一つの例から推論する

生成スキームはカスタマイズできるため、分散主キーを実装するためのアイデアは数多くあります。以前書いた記事「9 つの分散 ID 生成スキーム」を思い出しましたが、それらは完全に互換性があることがわかりました。ここでは、練習に Didi (Tinyid) を選びます。別途分散ID生成サービスなので、まずは環境を構築する必要があります。

Tinyid のサービスでは、Http と Tinyid クライアントの 2 つのアクセス方法が提供されます。以下は、Tinyid クライアントメソッドの簡単な紹介です。詳細については、こちらの記事をお読みください。何度も紹介されすぎています。

Tinyidサービス構築

まず、ソースコード https://github.com/didi/tinyid.git を取得します。

分散IDは番号セグメントモードに基づいて実装されるため、データベースに依存します。対応するテーブル tiny_id_info と tiny_id_token を作成し、デフォルトデータを挿入する必要があります。

作成する テーブル`tiny_id_info` (
 `id` BIGINT (20) 符号なしNOT   NULL AUTO_INCREMENT COMMENT '自動増分主キー' ,
 `biz_type` VARCHAR (63) NOT   NULL  デフォルト  ''コメント「ビジネスタイプ、ユニーク」 、
 `begin_id` BIGINT (20) NOT   NULL  デフォルト  '0' COMMENT '開始 ID、初期値のみを記録し、他の意味はありません。初期化時には、begin_idとmax_idは同じである必要があります。
 `max_id` BIGINT (20) ではない  NULL  デフォルト  '0' COMMENT '現在の最大ID' ,
 `step` INT (11)デフォルト  '0'コメント'ステップサイズ' 、
 `デルタ` INT (11) NOT   NULL  デフォルト  '1' COMMENT 'IDごとに増加' ,
 `剰余` INT (11) NOT   NULL  デフォルト  '0'コメント'残り' ,
 `create_time`タイムスタンプ ない  NULL  デフォルト  '2010-01-01 00:00:00'コメント'作成時間' 、
 `update_time` タイムスタンプ ない  NULL  デフォルト  '2010-01-01 00:00:00'コメント'更新時間' 、
 `version` BIGINT (20) NOT   NULL  デフォルト  '0'コメント'バージョン番号' ,
主要な キー(`id`)、
個性的 キー`uniq_biz_type` (`biz_type`)
 ) ENGINE = INNODB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8 COMMENT 'id information table' ; 
 
作成する テーブル`tiny_id_token` (
 `id` INT (11) 符号なしNOT   NULL AUTO_INCREMENT COMMENT '自動増分ID' ,
 `トークン` VARCHAR (255) NOT   NULL  デフォルト  '' COMMENT 'トークン' 、
 `biz_type` VARCHAR (63) NOT   NULL  デフォルト  '' COMMENT 'このトークンがアクセスできるビジネスタイプ識別子' 、
 `コメント` VARCHAR (255) NOT   NULL  デフォルト  '' COMMENT 'コメント' ,
 `create_time`タイムスタンプ ない  NULL  デフォルト  '2010-01-01 00:00:00'コメント'作成時間' 、
 `update_time` タイムスタンプ ない  NULL  デフォルト  '2010-01-01 00:00:00'コメント'更新時間' 、
主要な キー(`id`)
 ) ENGINE = INNODB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8 COMMENT 'トークン情報テーブル' ; 
 
入れる  INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`) VALUES ( '1' , '0f673adf80504e2eaa552f5d791b644c' , 'order' , '1' , '2017-12-14 16:36:46' , '2017-12-14 16:36:48' ); 
 
入れる  INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`) VALUES ( '1' , 'order' , '1' , '1' , '100000' , '1' , '0' , '2018-07-21 23:52:58' , '2018-07-22 23:19:27' , '1' );

そして、Tinyidサービスで上記のテーブルのデータソース情報を設定します。

データソース.tinyid。プライマリ.url=jdbc:mysql://47.93.6.e:3306/ds-0?autoReconnect= true &useUnicode= true &characterEncoding=UTF-8
 datasource.tinyid.primary.username =root
 datasource.tinyid.primary.password =ルート

最後に、プロジェクト Maven をインストールし、TinyIdServerApplication を右クリックしてサービスを開始すると、Tinyid 分散 ID 生成サービスがセットアップされます。

カスタム Tinyid 主キータイプ

Tinyid サービスがビルドされたら、それをプロジェクトに導入し、新しい tinyid_client.properties ファイルを作成し、それに tinyid.server プロパティと tinyid.token プロパティを追加します。トークンは、SQL に事前に挿入されたユーザーデータです。

 # tinyid 分散ID
 # サービスアドレス
tinyid.server=127.0.0.1:9999
 # ビジネストークン
タイニーIDトークン=0f673adf80504e2eaa552f5d791b644c

コード内で ID を取得する方が簡単で、必要なコードは 1 行だけで済み、ビジネスタイプの順序は SQL によって事前に挿入されたデータです。

ロングid = TinyId.nextId( "order" );

Tinyid 主キー生成タイプの実装クラス TinyIdShardingKeyGenerator のカスタマイズを開始します。

 /**
 * @著者: xiaofu
 * @説明: カスタム主キージェネレーター
 */
 @成分
パブリッククラス TinyIdShardingKeyGenerator は ShardingKeyGenerator を実装します { 
     
    /**
     * カスタム生成スキームタイプ
     */
    @オーバーライド
パブリック文字列getType() {
戻る  「ちっちゃい」 ;
    } 
 
    /**
     * コアメソッド - 主キーIDを生成する
     */
    @オーバーライド
パブリックComparable<?> generateKey() { 
         
        ロングid = TinyId.nextId( "order" ); 
         
 IDを返します。
    } 
 
    @オーバーライド
パブリックプロパティ getProperties() {
戻る ヌル;
    } 
 
    @オーバーライド
パブリックvoid setProperties(プロパティ プロパティ) { 
 
    }
 }

構成ファイルで Tinyid 主キー生成タイプを有効にします。これで設定は完了です。すぐにテストしてみましょう。

 # 主キーフィールド
spring.shardingsphere.sharding.tables.t_order。キージェネレーター。列= 注文ID
 # 主キーID生成スキーム
spring.shardingsphere.sharding.tables.t_order。キー-generator.type=tinyid

Tinyid 主キーのテスト

注文レコードをデータベースに挿入すると、主キー ID フィールド order_id が増加傾向にあることがわかりました。 Tinyid サービスが正常に接続されました。完璧！

要約する

以降の 8 つの生成方法については、「9 つの分散 ID 生成スキーム」を参照し、必要に応じてアクセスしてください。全体的な方法は比較的単純なので、ここでは一つずつ実装しません。

事例 GitHub アドレス: https://github.com/chengxy-nds/Springboot-Notebook/tree/master/springboot-sharding-jdbcLiu Yishou

オリジナルリンク: https://mp.weixin.qq.com/s/x1gVtnKh2OEAzSwv0sFDxg

<<: Huawei Cloud WeLinkがクラウドノート機能を開始

>>: アントファイナンシャルの「テクニカルミドルプラットフォーム」：1億レベル分散システムアーキテクチャの実践