ビジネスが成長するにつれて、本番システムでは常にビジネス量が小規模から大規模に増加するプロセスが発生します。スケーラビリティは、システムの高可用性を検討するための重要な指標です。データベース システム; 単一のテーブル/データベース内のデータ量が多すぎて更新量が急増し続ける場合、MySQL DBA はビジネス システムのシャーディング ソリューションを提案することがよくあります。シャーディングが必要なため、商品を保管するデータベースなど、一部のビジネス システムではシャーディング キーの問題について議論することは避けられません。では、グローバルに一意の ID を生成するにはどうすればよいでしょうか。 DBA の観点から、いくつかの一般的なソリューションを紹介します。
CAS プロトコルとは何ですか
Memcached は、バージョン 1.2.4 で CAS (Check and Set) プロトコルを追加しました。これは、Java の同時 CAS (Compare and Swap) アトミック操作に似ており、変更される同じ項目の同時実行を処理します。複数のスレッドによる質問
基本原理は非常に簡単で、一言で言えば「バージョン番号」です。
次の例から理解できます:
CAS が使用されていない場合、次のシナリオが発生します:
最初のステップでは、A はデータ オブジェクト X を取り出し、CAS-ID1 を取得します。
2 番目のステップでは、B はデータ オブジェクト X を取り出し、CAS-ID2 を取得します。SQL文
リーリー SQL ステートメント内のおよび gid
update ステートメントの影響を受けるレコード数が 0 の場合、別のプロセスが事前に値 203 を生成し、データベースに書き込んでいることを意味します。再生成するには、上記の手順を繰り返す必要があります。
コードは次のように実装されます:
リーリー2. グローバルロックを使用する
並行プログラミングを実行する場合、通常はロック機構が使用されます。実際、グローバル ID の生成により、同時実行の問題も解決されます。
世代のアイデアは次のとおりです:
グローバルIDを生成する前に毎回、指定されたキーが存在するかどうかを確認し、存在しない場合はredisのincrメソッドまたはmemcacheのincrementを使用して1を加算します。この 2 つのメソッドの戻り値は 1 を加算した値になります。存在する場合はループ待ち状態になります。ループ中にキーがまだ存在するかどうかが常にチェックされ、キーが存在しない場合は上記の操作が実行されます。
コードは次のとおりです:
リーリー3. Redisとdbの組み合わせ
Redis を使用してメモリを直接操作すると、パフォーマンスが向上する可能性があります。しかし、redis が停止した場合はどうすればよいでしょうか?上記の 2 つの解決策を組み合わせると、安定性が向上します。
コードは次のとおりです:リーリー
4. フリッカーの解決策 まず別のデータベース (例: チケット) を作成し、次にテーブルを作成します:
リーリー
アプリケーション側では、次の 2 つの操作を実行し、トランザクション セッションで送信する必要があります:
リーリー
これまでのところ、高可用性の観点から、単一のデータベースでのみ ID を生成してきました。 SELECT * from Tickets64
次のステップは、単一障害点の問題を解決することです。Flicker は、2 つのデータベース サーバーで ID を生成できるようにしました。 auto_increment 値とステップ サイズを調整して奇数 ID と偶数 ID を生成します。
最後に、クライアントはポーリングを通じて ID を取得するだけで済みます。
参考:
http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/
http://segmentfault.com/a/1190000004090537
。