mysql はどのようにしてメッセージの順序を保証しますか?

例を挙げましょう。以前に mysql binlog 同期システムを構築しました。プレッシャーは依然として非常に高いです。毎日の同期データは数億に達する必要があります。つまり、データはmysql データベースからそのままの状態で、別の mysql ライブラリに同期します (mysql -> mysql)。共通点は、たとえば、ビッグ データ チームが会社のビジネス システムのデータに対してさまざまな複雑な操作を実行するために、mysql ライブラリを同期する必要があるということです。

mysql でデータを追加、削除、または変更すると、追加、削除、または変更の 3 つのログ binlog が表示され、その後、これら 3 つの binlog が表示されます。は MQ に送信され、順番に消費されます。実行するときは、少なくとも人が順番に来ることを確認する必要があります。そうでなければ、本来は追加、変更、削除だったのを、順番を変えて削除、変更、追加と実行しただけですが、完全に間違っていますよね？

本来、このデータを同期する際、最後にデータを削除するべきだったのですが、順番を間違えてしまい、最後までデータが残ってしまい、データの同期が失敗してしまいました。 。

順序が狂う 2 つのシナリオを見てみましょう:

• RabbitMQ: 1 つのキュー、複数のコンシューマー。例えば、プロデューサは、data1/data2/data3の順で3つのデータをRabbitMQに送信し、それをRabbitMQのメモリキューにプッシュします。 MQ からの 3 つのデータのうちの 1 つを消費するコンシューマーが 3 人います。その結果、コンシューマー 2 が最初に操作を完了し、data2 をデータベースに保存し、次に data1/data3 を保存します。これは明らかに混乱しているわけではありません。

• Kafka: たとえば、3 つのパーティションを持つトピックを作成しました。プロデューサーが書き込むとき、実際にキーを指定できます。たとえば、注文 ID をキーとして指定すると、この注文に関連するデータは確実に同じパーティションに分散され、このパーティション内のデータはそこに存在する必要があります。命令です。
  コンシューマーがパーティションからデータを取り出すときは、それらも順序どおりである必要があります。この時点では、順序はまだ問題なく、混乱はありません。次に、コンシューマー内に複数のスレッドを作成して、メッセージを同時に処理します。コンシューマーが単一のスレッドで消費および処理し、その処理に時間がかかる場合 (たとえば、メッセージの処理に数十ミリ秒かかる場合)、1 秒間に処理できるメッセージは数十個のみであり、スループットが低すぎるためです。 。複数のスレッドを同時に実行すると、順序が崩れる可能性があります。 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃解決

ウサギMQ

複数のキューを分割し、各キューに 1 つのコンシューマーがあり、これは単にキューが増えただけであり、これは確かに厄介な点です。または、キューが 1 つしかなく、1 つのコンシューマーに対応し、このコンシューマーが内部でメモリ キューを使用します。最下層に処理する別のワーカーを与えます。

カフカ

1 つのトピック、1 つのパーティション、1 つのコンシューマ、内部シングル スレッドの消費量、シングル スレッドのスループットが低すぎるため、通常、これは使用されません。

N 個のメモリ キューを書き込むと、同じキーを持つデータが同じメモリ キューに送られ、N 個のスレッドに対して各スレッドがそれぞれ 1 つのメモリ キューを消費するため、順序性が確保されます。

以上がmysql はどのようにしてメッセージの順序を保証しますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。