mysqlが全文検索またはファジークエリをサポートできないために取引量が増えると、システムのクエリの場所に低速のsqlなどが表示され、システムの他のモジュールをドラッグダウンして、パフォーマンスが低下します。
ESの使用の人気が高まるにつれ、ESはmysqlの効果的なサプリメントになります。専門的なサービスを提供する検索エンジン（ESなど）にデータを送信できます。
次に、作業で使用される実際のシーンに基づいて、mysqlからesへのデータ同期の分析。
実際には、以下の方法をまとめました。
タイプ1：同期二重書き込み
これは、mysqlにデータを書き込むときに同時にESにデータを書き込む最も簡単な方法で、データの二重書き込みを実現します。
利点：
ビジネスロジックは単純です。
短所：
ハードコーディング：mysqlに書き込む必要がある場合はいつでも、ESに書き込むコードを追加する必要があります。ビジネスは強く結合されています。二重書き込み障害によるデータ損失のリスクがあります。パフォーマンスが低い：mysqlのパフォーマンスはそれほど高くなく、ESを追加します。システムのパフォーマンスは低下する傾向があります。説明：
上記のポイント3で述べた二重書き込み障害のリスクには、次の3つのタイプがあります。
ESシステムが使用できない、アプリケーションシステムとES間のネットワークに障害がある、アプリケーションシステムが再起動するため、システムが遅すぎてESに書き込むことができない。この状況を考慮すると、強いデータ整合性要件がある場合は、処理するためにトランザクションに二重に書き込む必要がありますが、トランザクションが使用されると、パフォーマンスの低下はより明白になります。
2番目のタイプ：非同期二重書き込み（MQモード）
次の図に示すように、最初の同期二重書き込みのパフォーマンスとデータ損失については、MQは非同期二重書き込みソリューションを形成すると考えることができます。
MQのパフォーマンスは基本的にmysqlよりも1桁高いため、パフォーマンスを大幅に改善できます。
利点：
高性能、データ損失の問題はありません。短所：
ハードコーディングの問題：依然として強いビジネスカップリングが存在します：依然として複雑さが増しています：mqコードがシステムに追加されます;遅延の問題がある可能性があります：プログラムの書き込みパフォーマンスは向上しますが、MQの消費が原因でネットワークまたはその他の理由が原因である可能性がありますユーザーが書き込んだデータがすぐに表示されず、遅延が発生する場合があります。3番目の種類：非同期二重書き込み（ワーカーモード）
上記の2つのスキームにはハードコーディングの問題があります。つまり、mysqが追加、削除、または変更された場所は、ESコードが埋め込まれるか、MQコードに置き換えられます。
リアルタイム要件が高くない場合は、タイマーを使用してそれを処理することを検討できます。具体的な手順は次のとおりです。
タイムスタンプという名前のフィールドがデータベース内の関連するテーブルに追加されます。クラッド操作を行うと、このフィールドの時間が変更されます。元のプログラムのCURD操作は変更を加えません。これを可能にするタイマープログラム（Working in Jingdong）が追加されますプログラムは、指定されたテーブルを特定の期間に従ってスキャンし、この期間に変更されたデータを抽出して、ESに1つずつ書き込みます。以下のように入力してください
利点：
元のコードへの変更、煩わしさ、ハードコーディング、強力なビジネスカップリング、元のプログラムのパフォーマンスへの変更、ワーカーコードの単純な記述で、追加、削除、変更を考慮する必要はありません。短所：
適時性が低いです。タイマーのデューティサイクルを2番目のレベルに設定できないため、リアルタイムのパフォーマンスは上記の2ほど良くありません。データベースに一定のポーリング圧力がかかっています。改善された方法は、重い圧力にポーリングを置くことです。ライブラリ。4番目の種類：Binlog同期モード：
上記の3つのスキームは、コード侵入、ハードコード、または遅延のいずれかです。4番目のスキームでは、mysqlのbinlogを使用して同期できます。
具体的な手順は次のとおりです。
1）mysqlのbinlogログを読み取り、指定されたテーブルのログ情報を取得します。
2）読み取った情報をMQに変換します。
3）MQコンシューマープログラムを記述します。
4）MQの消費を継続し、メッセージが消費されるたびにESにメッセージを書き込みます。
利点：
コードの侵入やハードコーディングはありません。元のシステムは変更も知覚も必要ありません。ハイパフォーマンスです。ビジネスの分離では、元のシステムのビジネスロジックに注意を払う必要はありません。短所：
Binlogシステムの構築は複雑であり、スキーム2と同様に、MQ遅延のリスクがあります。