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

この記事では、MySQLとRedisキャッシュを同期するための2つのソリューションを紹介します。

• ソリューション1: MySQL同期、MySQLトリガー+UDF関数実装によりRedisを自動的に更新する
• 解決策2: MySQLのbinlog実装を分析し、データベース内のデータを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 をよろしくお願いいたします。