ホームページ  >  記事  >  データベース  >  Redis の Codis について詳しく見る

Redis の Codis について詳しく見る

青灯夜游
青灯夜游転載
2022-01-06 09:54:122907ブラウズ

この記事では、Redis の Codis を理解し、Codis の原則を紹介します。お役に立てば幸いです。

Redis の Codis について詳しく見る

シナリオ

ビッグ データの同時実行性が高いシナリオでは、たとえ Redis のパフォーマンスが高くても、単一の Redis インスタンスを使用するのは非常に困難になります。

まず、データ量が大きくなると、redis が占有するメモリも大きくなり、RDB ファイルも大きくなりすぎるため、マスタとスレーブの完全同期時間が長くなってしまいます。同時にインスタンスを再起動すると、大きすぎるRDBが読み込まれるため、起動時間が長くなります。 [関連する推奨事項: Redis ビデオ チュートリアル ]

次に、CPU の使用に関して、Redis の 1 つのインスタンスは 1 つの CPU コアしか使用できません。1 つのコアに多すぎるデータも表示されます。これは私たちの能力を超えています。

したがって、膨大な量のデータを 1 つのインスタンスから複数のインスタンスに分散するには、クラスター ソリューションが必要です。Redis の人気から独自のクラスター ソリューションの公式サポートに至るまで、サードパーティは独自のサポートも開発しています。Codis はクラスターのコンポーネントの 1 つです。

Codis は Go 言語を使用して開発され、Redis とクライアントの間のエージェントとして機能します。Redis プロトコルを使用するため、クライアントはCodis に直接接続して指示を送信します。Codis は指示を Redis に転送し、最終的に返された結果を受信して​​クライアントに返します。

Redis の Codis について詳しく見る

#Redis Codis で表されるインスタンスは、クラスターのスペースが足りない場合に使用できる Redis クラスターを形成します。同時に、動的に容量を拡張して Redis インスタンスを追加し続けることができます。同時に、クライアントが使用する SDK変更する必要はありません。元の接続を redis から codis に変更するだけで済みます。

Codis 自体は、クラスターを使用して独自の高可用性を確保することもできます。ステートレスであるため、次のことのみを担当します。コンテンツの転送。複数の Codis を追加しても副作用はなく、QPS を確実に向上させることができます。Codis の 1 つが失敗した場合は、別の Codis を使用することもできます。

Redis の Codis について詳しく見る

原則

Codis は、特定のキーを特定の Redis インスタンスに転送します。クラスター内の各インスタンスはキーの一部を保存し、他のインスタンスへの圧力を軽減します。同時に、すべてのインスタンスのデータが合計されて、完全な情報が形成されます。

Codis はデフォルトで 1024 のスロットに分割されています。クラスター内の各 Redis インスタンスは、スロットの一部に対応します。Codis は、スロットと Redis インスタンス間の対応関係をメモリ内に維持します。

スロット数はデフォルトで 1024 ですが変更可能で、クラスタノードが多い場合にはスロット数を増やすことができます。

Redis の Codis について詳しく見る

クライアントから送信されたキーを受信すると、Codis はキーに対して crc32 操作を実行してハッシュ値

を取得し、ハッシュされた整数を取得します。 value は、キーが保存されるスロットである剰余を取得するためのモジュロ 1024 (スロットの数) です。スロットを使用すると、キーを送信する必要がある Redis インスタンスを見つけることができます。

疑似コード:

hash = crc32(command.key) # 计算hash值
slot = hash % 1024 # 取模得到槽位
redisInstance = slots[slot].redis # 得到redis实例
redis.do(command) # 执行命令复制代码

クラスター スロットの同期

Redis とスロット間のマッピング関係は Codis メモリに存在するため、 Codis クラスターは、各ノードのスロット マッピング関係が確実に同期されていることを考慮する必要があるため、Codis は Zookeeper と Etcd 分散構成ストレージ ミドルウェアを使用してスロット マッピング関係を永続化し、Codis クラスター間のデータ同期を確保します。

以下に示すように, Codis は、スロット関係を Zookeeper に保存し、スロット関係を観察および変更するためのダッシュボードを提供します。変更が発生すると、Codis プロキシは変更をリッスンしてスロット関係を再同期します。

Redis の Codis について詳しく見る

拡張

既存のクラスターがビジネス ニーズを満たさない場合、新しいクラスターを追加する必要があります。インスタンスがクラスターに追加されるとき、スロット マッピング関係を再配布する必要があり、スロットの一部を新しいノードに割り当てる必要があります。

Codis は、指定されたスロットの下にあるすべてのキーを走査できる新しい SLOTSSCAN 命令を追加しました。この命令を使用して、移行するスロット内のすべてのキーをスキャンし、各キーを 1 つずつ走査して移行します。

移行プロセス中、Codis は外部サービスを提供し続けました。この時点で、移行中のスロットにリクエストが届きました。スロットは現在古いノードと新しいノードに対応しているため、Codis は判断できませんキーが持っているかどうか 古いノードから新しいノードへの移行はありません。

したがって、この場合、Codis は現在のキーの単一の移行を直ちに強制します。移行が完了すると、リクエストは新しい Redis インスタンスに転送されます。

疑似コード:

slot_index = crc32(command.key) % 1024
if slot_index in migrating_slots:
    doMigratingKey(command.key)
    redis = slots[slot_index].new_redis
else:
    redis = slots[slot_index].redis复制代码
SLOTSSCAN Redis 独自の Scan コマンドと同様に、スキャンされたデータの重複は回避できませんが、単一のキーが移行された後は、移行の正確さに影響しません。古いインスタンスからすぐに削除され、スキャンアウトできなくなります。

#スロットの自動バランス調整

新しいインスタンスが追加されるたびに、スロット マッピング関係を手動で維持するのは面倒です。Codis は自動バランシングを提供します。この機能は、システムが比較的アイドル状態のときに、各 Redis インスタンスに対応するスロットの数を監視します。アンバランスな場合は、自動バランシングおよびデータ移行操作が実行されます。

欠点

Codis は Redis に拡張上の利点をもたらしますが、いくつかの副作用も引き起こします。

トランザクションはサポートされません

トランザクションは複数のキーで動作する可能性がありますが、トランザクションは 1 つのインスタンスでのみ完了できます。ただし、キーは複数のインスタンスに分散されているためです。インスタンス であるため、Codis はトランザクション操作をサポートできません。

名前の変更はサポートされていません

名前を変更すると、あるキーから別のキーに名前が付けられますが、2 つのキーは同じスロットにハッシュされるのではなく、異なるインスタンスのスロットにハッシュされる可能性があります。したがって、名前の変更はサポートされていません。

公式に提供されているサポートされていない命令のリスト: https://github.com/CodisLabs/codis/blob/master/doc/unsupported_cmds.md

拡張がスタックしました

Codis の拡張プロセス中のデータ移行では、ハッシュ構造などのキー全体が直接移行されます。Codis はすべてのコンテンツを直接 hgetall プルし、hmset を使用して新しいノードに配置します。

ハッシュの内容が大きすぎると、遅延が発生します。当局は、単一のコレクション構造の合計サイズが 1MB を超えないよう推奨しています。ビジネスでは、大きなデータをバケット ストレージを通じて複数の小さなデータに分割できます。 、など、妥協してください。

ネットワーク オーバーヘッド

Codis はクライアントと Redis インスタンスの間のネットワーク プロキシとして機能するため、追加のレイヤーがあり、ネットワーク オーバーヘッドは当然高くなります。 Redis に直接接続するよりもパフォーマンスは高くなりますが、パフォーマンスはわずかに低下します。

ミドルウェアの運用と保守のオーバーヘッド

Codis クラスター構成では Zk または Etcd を使用する必要があります。つまり、Codis クラスターを導入する場合、負荷を増やすために他のミドルウェアを導入する必要があります。運用および保守用の機械リソースとコスト。

利点

Codis は分散一貫性の問題をサードパーティ (ZK または Etcd) に引き継ぎ、分散化を実現するためにこの側面を排除します。 、Redis 公式クラスターには Raft プロトコルと Gossip プロトコルが導入され、調整が必要な多数の構成パラメーターが導入され、複雑さが急激に増加しました。

バッチ取得mget を使用して複数のキーの値を取得するなどのバッチ操作の場合、これらのキーは複数のキーに分散している可能性があります。 Codis は、キーが配置されているインスタンスに従ってキーをグループ化し、各インスタンスで mget を 1 つずつ呼び出し、最後に概要をクライアントに返します。

Redis の Codis について詳しく見る

その他の機能Codis はダッシュボード インターフェイスを提供し、Codis-fe はクラスターを管理します。グループやノードの追加、自動バランシングなどの操作、スロットのステータスやスロットに対応するredisインスタンスの確認など、運用・保守をより便利・​​簡単に行えます。

Redis の Codis について詳しく見る

Redis の Codis について詳しく見る

Redis の Codis について詳しく見る

Redis の Codis について詳しく見る

歴史へ

#Codis は、Redis が公式にクラスターの概念を提供していなかった事実を補うために登場しました。現在、Redis は正式にクラスター機能を提供しています。公式サポートはサードパーティのサポートよりも当然有利です。 . 同時に、サードパーティ ソフトウェアも公式がリアルタイムでリリースする新機能に注意を払う必要があり、Cluster は確実に新機能にリアルタイムで対応しているため、よりお勧めします。公式の Cluster を使用する 過去の知識として、Codis には特定のアイデアがあり、Cluster には重複する部分があります。

プログラミング関連の知識について詳しくは、

プログラミング入門

をご覧ください。 !

以上がRedis の Codis について詳しく見るの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事はjuejin.cnで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。