Redis メッセージ キューがデータ損失を防ぐ方法

Redis は 2 つの形式でメッセージ キューを実装します。

ブロードキャスト サブスクリプション モード: Redis の Pub/Sub メカニズムに基づいて、クライアントがアクセスすると、特定のキーでメッセージをパブリッシュすると、すべてのサブスクライブ クライアントがイベント クラスター サブスクリプション モードをトリガーします: Redis リストの双方向アトミック性 BRPOP に基づいて (推奨される学習: Redis ビデオ チュートリアル )

Redis メッセージ キューを使用する場合、Redis がダウンするとメッセージが失われる可能性があります (永続化戦略にも依存します)。メッセージ受信者に再送信および検証メカニズムがない場合、Redis 内のデータは失われます。 したがって、Redis をメッセージ キューとして使用するのは、通常、メッセージの精度がそれほど高くないシナリオです。

データの最終的な一貫性を絶対に保証し、メッセージが 100% 失われないことを保証する場合は、次のものが必要です:

1.書き込み時の要件 書き込みを確実に成功させるためにトランザクション処理を有効にします。

2. Redis は、変更をリアルタイムで永続化する必要があるように構成されています。たとえば、ストレージ側がディスクの場合、各変更はディスクに同期して書き込まれます。完成されました。 Redis はこの方法での構成をサポートしていますが、そうするとメモリ内データベース機能が完全に失われ、パフォーマンスが非常に低下します。

3. コンシューマ側もトランザクションモードを実装する必要があり、処理が完了したら戻ってきて実際にメッセージを削除します。

4. 複数のスレッドや複数の端末の同時処理は、ロックすることで回避できます。

3 4 の要件は自分で実装する必要があります。一緒に検討することもできます。別のキューを使用して実装することもできますが、より良い方法はキュー内にカウンターを実装することです。ハッシュ形式の場合はフィールドを追加してから値を追加、リストの場合は先に値を追加してベースにします文字列の先頭に値と区切り文字を追加すれば簡易的なカウンタが作れます。十分実用的です。

特定のシステムを除いて、このような強整合性は通常は必要ありません。実装は難しくありませんが、パフォーマンスは非常に低下します。

銀行決済ビジネスでは厳格なトランザクションの一貫性が必要ですが、インターネット ビジネスでは一般に、パフォーマンスの向上と引き換えに、非常に短期間での少量のデータ損失を許容できる難しいアプローチが使用されます。

たとえば、上記の Redis 処理を変更して、1000 個のデータが変更されたときに実際にディスクに書き込むことができます。突然の停電などの極端な場合には、これら 1,000 件のデータが失われる危険性があります。もちろん、これが起こる確率も非常に低いので (Lanxiang 掘削機から離れてください?)、ほとんどのシナリオで許容されます。

Redis 関連の技術記事の詳細については、Redis 入門チュートリアル 列にアクセスして学習してください。

以上がRedis メッセージ キューがデータ損失を防ぐ方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。