背景
それは単一のMySQLデータベースライブラリ単一のテーブルまたは単一のredisは、読み取りと書き込み操作の高い並行性と大規模なデータストレージ機能を満たすことができないされているかどうか、より大きく、より多くのデータのアプリケーションでは、おなじみのサブライブラリのサブテーブルがあります。
垂直分割と水平分割
縦割り、つまりテーブルの分割は、1つの元のテーブルから2つのテーブルに情報を操作的に分割します。
水平分割、つまり行の分割は、あるテーブルから別のテーブルへ、次のようなルールでデータを分割します。
もちろん、垂直分割と水平分割の概念はこの記事で議論する焦点ではなく、この記事は水平分割のルールについて議論するものです。水平分割の本質と分散システム、そしてマイクロサービスの考え方が一致するのは、1つのサービスがあまりにも多くのビジネスロジックを運ぶため、コードロジックが巨大で複雑、開発者間の関係と相まって、単一障害点などの問題が発生するためだと述べました。DBやredisにもこのような問題があるでしょう：
- アクセス要求の数が増加すると、スタンドアロンDB/redisは要求の高い並行性に耐えるために十分なスレッドを割り当てることができません。
- データの量がどんどん大きくなっているとき、水のボウルから針を見つけることは、困難と時間のかかる海から針を見つけることと同じではありません。
そのため、DB/redisを複数のテーブルに拡張する必要があります。
分散クラスタにおけるいくつかのルーティングアルゴリズム
前回の紹介で水平分割の必要性は説明できたと思いますが、問題はどのように分割するか、どのようなルールに従って異なるデータを異なるmysqlライブラリ/mysqlテーブル/redisマシンに分類するかです。以下はuseridをキーとした例です。
固定ハッシュ
(userid % 32) ^ (userid >> 32)固定ハッシュを理解することは非常に良いですが、私は今、分割ライブラリのデータベースの部門であり、分割テーブルのロジックは簡単ですが、上位32ビットと合計操作の下位32ビットのuseridを取りました。
欠点は、新しいサービスを追加する必要があるときに、新しいマシンは、単にルーティングすることはできません、スケーラビリティが悪いです。ときに固定ハッシュに起因するサービスをダウンする必要が必然的にサービス要求への要求の失敗につながるでしょう。
整合性ハッシュ
一貫性のあるハッシュは、新しいマシンにリクエストを一貫して切り替えることができますが、いくつかの小さな欠点があります。ハッシュフェッチモードアルゴリズムによって得られる結果はランダムであるため、個々のサービスノードがハッシュリング全体に均等に分散される保証はありません。これは、例えば、図のケースに示すように、8時方向のサービスが過剰な負荷にさらされることにつながる、データスキュー問題としても知られる古典的なホットスポット問題につながります。
仮想ノードの一貫したハッシングの導入
上記の問題に対処するため、仮想ノードという概念が導入され、マシンごとに複数のハッシュをマッピングすることで
hashA = hash('.0.1-A') % 0x20;
hashB = hash('.0.1-B') % 0x20;
hashC = hash('.0.1-C') % 0x20;これにより、図に示すように、マシンはリング上に複数の仮想ノードを持つことができます。
カスタマイズされた計算
前述したように、ライブラリのルールの会社の事前分割の著者は、固定ハッシュですが、その後、ビジネスの実際のパフォーマンスと組み合わせて小さなユーザーn回へのユーザーアクセスのいくつかを参照してくださいに、普通のユーザーがdbまたはredisにルーティングされ、普通のユーザーの読み取りと書き込みに影響を与えるためにバインドされているので、これらの特別な世帯のために9999の特別なスライスのスライス番号のスライスにルーティングされた別のルールを実行します。
