MySQLとRedisキャッシュ間の同期ソリューションについての簡単な説明

1. ソリューション 1 (UDF)

シナリオ分析: MySQLデータベースでデータ操作を実行すると、対応するデータが同時にRedisに同期されます。Redisに同期した後、クエリ操作はRedisから検索されます。

プロセスはおおよそ次のようになります。

MySQLで操作するデータにトリガーを設定し、操作を監視する

クライアント（NodeServer）がMySQLにデータを書き込むと、トリガーがトリガーされ、トリガー後にMySQL UDF関数が呼び出されます。

UDF関数はRedisにデータを書き込んで同期効果を実現できる

ソリューション分析:

このソリューションは、書き込みよりも読み取りが多く、同時書き込みがないシナリオに適しています。
MySQL トリガー自体が効率低下の原因となるため、テーブルが頻繁に操作される場合、このソリューションは適していません。

デモケース

以下はMySQLテーブルです

以下はUDFの解析コードです

対応するトリガーを定義する

2. ソリューション2（binlogの解析）

ソリューション 2 を紹介する前に、まず次の図に示すように、MySQL レプリケーションの原理を紹介します。

メインサーバーはデータを操作し、データをBinログに書き込みます
スレーブサーバーは I/O スレッドを呼び出してマスターサーバーの Bin ログを読み取り、それを自身の Relay ログに書き込みます。次に、SQL スレッドを呼び出して Relay ログのデータを解析し、自身のデータベースに同期します。

解決策2は次のとおりです。

上記のMySQLのレプリケーションプロセス全体は、1つの文で要約できます。マスターサーバーのBinログのデータをスレーブサーバーから読み取り、それを独自のデータベースに同期します。
ソリューション 2 でも同様です。概念的には、マスターサーバーを MySQL に変更し、スレーブサーバーを Redis に変更します (下の図を参照)。データが MySQL に書き込まれると、MySQL Bin ログを解析し、解析したデータを Redis に書き込んで同期を実現します。

たとえば、クラウドデータベースインスタンスの分析は次のとおりです。

クラウドデータベースとローカルデータベースはマスターとスレーブの関係にあります。クラウドデータベースは主に書き込みサービスを提供するプライマリデータベースであり、ローカルデータベースはプライマリデータベースからデータを読み取るセカンダリデータベースです。

ローカルデータベースはデータを読み取った後、Bin ログを解析し、同期のためにデータを Redis に書き込みます。その後、クライアントは Redis からデータを読み取ります。

この技術的ソリューションの難しさは、MySQL Bin Log をどのように解析するかにあります。ただし、これには、binlog ファイルと MySQL に関する非常に深い理解が必要です。同時に、binlog は Statement/Row/Mixed レベルなど複数の形式で存在するため、同期を実現するために binlog を分析する作業負荷は非常に大きくなります。

キャナルオープンソーステクノロジー

Canal は、純粋な Java で開発された Alibaba のオープンソースプロジェクトです。データベースの増分ログ分析に基づいて、増分データのサブスクリプションと消費を提供します。現在は主にMySQLをサポートしています（mariaDBもサポートしています）

オープンソースの参照アドレスは https://github.com/liukelin/canal_mysql_nosql_sync です。

仕組み（MySQL レプリケーションを模倣）:

Canal は MySQL スレーブの対話型プロトコルをシミュレートし、MySQL スレーブのふりをして、ダンププロトコルを MySQL マスターに送信します。
MySQL マスターはダンプ要求を受信し、バイナリログをスレーブ (チャネル) にプッシュし始めます。
Canalはバイナリログオブジェクト（元々はバイトストリーム）を解析します

建築：

サーバーは、JVMに対応するチャネル実行インスタンスを表します。

インスタンスはデータキューに対応します (1 つのサーバーは 1..n 個のインスタンスに対応します)

インスタンスモジュール:

eventParser (データソースアクセス、スレーブプロトコルとマスターの相互作用のシミュレーション、プロトコル解析)
eventSink (パーサーおよびストアコネクタ、データのフィルタリング、処理、および配信を実行)
eventStore (データストレージ)
metaManager (増分サブスクリプションおよび消費情報マネージャー)

一般的な解析プロセスは次のとおりです。

ParseはMySQL Binログを解析し、データをシンクに格納します。
シンクはデータをフィルタリング、処理、配布します
ストアはシンクから解析されたデータを読み取り、それを保存します。
次に、デザインコードを使用して、ストア内のデータを Redis に同期します。
このうち、parse/sink はフレームワークによってカプセル化されており、私たちが行うのはストアからデータを読み取るステップです。

Canclの詳細については、Baiduで検索してください。

以下は動作トポロジー図です

MySQL テーブルの同期は責任連鎖モデルを採用しており、各テーブルはフィルターに対応します。たとえば、zvsync で使用されるクラスの設計は次のとおりです。

以下は、具体的な zvsync で使用されるクラスです。テーブルが追加または削除されるたびに、直接追加または削除できます。

3. 追加

この記事の上記の紹介は、MySQL からキャッシュへの同期に関するものです。しかし、実際の開発では、次のような解決策を使用する人もいます。

クライアントがデータを受信すると、まずRedisに保存され、その後MySQLに同期されます。
このソリューションは本質的に安全でなく信頼性も低いため、Redis に短時間のダウンタイムや障害が発生すると、データが失われます。

これで、MySQL と Redis Cache の同期ソリューションに関するこの記事は終了です。MySQL と Redis Cache の同期の詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: