デカップリング、負荷シフトするために使用される、広く使用されるメッセージミドルウェア、非同期処理。非同期処理は、すべての整数のシステムを使用して、そのような現在の技術のブログサイトなど、ほとんどの場面で使用することができる、ユーザーが記事を公開し、あなたがしたいポイントを獲得することができ、システムのパフォーマンスを向上させるために、ユーザーがクレジット・オペレーションを追加することができます非同期処理は、同期プロセスに配置する必要はありません。
私たちは、それが異なるサーバ間で発生するので、メッセージ配信システム、非同期処理・積分操作へのメッセージへの統合を高めるために、パッケージの必要性をユーザーIDを置くことができ、それによってユーザーを引き起こして、メッセージ配信の失敗、問題を障害処理可能ですプラス積分は失敗し、配信されたメッセージを繰り返した可能性があり、ユーザーは関係なく、状況のようなものを、プラスのポイントを繰り返す可能性があり、通常の状況ではありません。
上記の二つの例を避けるために、我々はこれらの2つの場合を回避する方法についての話の一般的なレベルから、メッセージングシステム、メッセージが失われていないと、メッセージは一度だけ消費されたことを確認しようとすることはさておき、この記事で特定のメッセージング・ミドルウェアが必要。
メッセージが失われないことを確実にするために1、
次のように生産から消費までのメッセージこのリンクは、メッセージの損失を引き起こす可能性が3ヶ所があり、以下のとおりです。
- プロセス・キューに生産者からのメッセージ配信障害メッセージを書き込みました。
- メッセージキュー内のメッセージ、永続的な障害が発生。
- 例外メッセージは、プロセスが発生し、消費者が消費しています。
メッセージ配信の失敗の製造方法において1.1
ニュース制作及びメッセージングシステムは、一般的に2つのサーバー間のネットワークを介して行われる通信する異なるサーバ上で独立して配備され、ネットワークが安定していない、ジッタは、データが失われる可能性があり、発生し得ます。ネットワークジッタは、次の2つの状況が発生しています。
シナリオ1：ネットワークジッタは、メッセージシステム、直接データの損失に送信されたメッセージ中に発生します。
シナリオ2：メッセージはメッセージングシステムを到着したが、メッセージサーバシステムは、生産者に情報を返すとき、ネットワークジッタが発生し、データが消失する。この時点では必ずしも真実ではない、それだけで生産者がデータの損失を考えるかもしれません。
プログラムは、ネットワークの異常を検出したとき、メッセージが、再入力機構に撮影することができますメッセージの失われた生産は、再びメッセージングシステムにメッセージを配信します。しかし、再配信シナリオ2のケースでは、それはデータの重複を引き起こす可能性が、どのようにこの問題を解決するために、それは後述します。
1.2永続的な障害メッセージキュー
メッセージは、メッセージの永続性である、それは一般的にローカルディスクにメッセージを格納している、もちろん、いくつかのメッセージ指向ミドルウェアのサポートがあり、データがデータベースに永続性、メッセージシステムのパフォーマンスが低下することがあります。
あなたは言葉Redisの持続性のいくつかの知識を持っている場合は、永続的なデータではなく、すべての新しいものをすぐにローカルディスクに入金する際のRedisを見つけるだろうが、データはまずオペレーティングシステムページキャッシュに書き込まれます。特定の条件が、それは/ O操作のランダムディスクIが減少するため、我々はランダムI / Oは非常に時間がかかるであることを知って、ブラシにディスクには、ページキャッシュのデータを満たしているにもシステムのパフォーマンスを向上させることになるとき永続がこの方法ですと、ミドルウェアメッセージングは、例外ではありません。
いくつかの極端な場合では、そのような突然の停電や異常リブートマシンとしてデータページキャッシュの損失をもたらし得ます。データ損失の問題を解決するためのページキャッシュ、デプロイクラスタへの方法は、データが失われないことを保証しようとするために使用することができます。
消費メッセージ損失の過程で1.3が存在
消費プロセスのメッセージも失われ、そして発生はるかに大きいよりも消費過程における損失の確率の前に2例。3つのステップに消費プロセスに関するメッセージ：プルメッセージコンシューマ、消費者は、消費の進捗状況を更新するために、メッセージシステムをメッセージを処理します。
プルメッセージが異常ネットワーク・ジッタを発生し得る場合の最初のステップは、メッセージに対処する第二のステップは、プロセスへ導かれ、完了していないいくつかの異常動作であってもよく、もし最初のステップは、例外の第二工程、システムの更新通知メッセージの消費者の進捗状況は、このエラーメッセージは、実際には、私たちの事業を終了しませんでした、自然に失われ、扱われることはありません。
消費者に失われたメッセージを回避するために、消費者は、メッセージが受信され、処理された後にのみ進行状況を更新することができますが、極端な場合には、メッセージを繰り返し消費の問題が発生し、このようなプロセスの後にメッセージとして、消費者の一顧を完了していますマシンは、その後、消費者は、消費者の再起動後、このメッセージはまだに消費され、スケジュールが更新されていません。
2、どのようにメッセージが一度だけ消費されたことを保証するために、
メッセージシステムは、消費者が自分自身を繰り返す可能性があるため、メッセージ自体は、一度だけ消費されていることではない保証は、システムがダウンストリームの繰り返しを引っ張って起動することができ、補償ロジックで、その結果、繰り返しもたらした失敗の再試行を引き起こす可能性があり、メッセージを繰り返して繰り返しメッセージのみが消費されることを保証するために、時間は、電力の使用率を達成することができます。
他の大国が数学的概念であり、繰り返し同じ操作を実行すると、一度の操作を実行していると、結果は最終的には同じになってしまいます。
概念的には冪等は、メッセージングシステムの使用中に等しい力を確保するために、どのようにして、メッセージが複数回のシステムには影響しません実行しても、見ることができますか？生産者と消費者は、消費電力の確保における生産者と消費者の両端ので、重複したメッセージを生成する可能性があるので。
などの電力生産の保証同じIDが既にマッピングテーブルに存在する場合は、グローバルIDにメッセージジェネレータ雪のアルゴリズムを使用して、メッセージの発生時には、IDがシステムメッセージでのメンテナンスメッセージのマッピングを持っている、それはメッセージを破棄し、メッセージは、メッセージの重複を避けるために、1保存実際には2回配信されているが、けれども。
生産者の力と関係を持っている他のメッセージングミドルウェアを選択し、メッセージシステムは例膨大な数の下で私たち自身を達成する必要がないので、それはコントロール、非常に良いと他の大国ではない消費者と私たちの他の電源開発キーパーソン方向制御。
それは私たちのビジネスの要件に応じて、一般消費者およびビジネスレイヤ冪等業務の両端から行うことができます。
一般的なレベルでは、良いニュースの使用は、メッセージが正常に処理された後に発生した世界的にユニークなIDクエリIDがプロセスに存在するこのグローバル・データベースで開始し、前に、データには、このグローバルIDにメッセージを入れて生成され、それが存在しない場合は、直接メッセージを与えます。
このグローバルユニークIDを使用して実現冪等メッセージ、次の擬似コードです。
boolean isIDExisted = selectByID(ID); // 判断ID是否存在
if(isIDExisted) {
return; //存在则直接返回
} else {
process(message); //不存在，则处理消息
saveID(ID); //存储ID
}メッセージを処理した後、十分なデータベースに保存されていない場合は、極端な場合には、このアプローチはまだ、消費者が再起動をダウンタイム、および再起動、クエリの実行、およびメッセージの後に再度メッセージが表示されます、間違って行くだろう消費はされていなかった、または二回消費を実行されます。データベースのトランザクションは、この問題を解決するために導入されてもよいが、システムのパフォーマンスが低下します。メッセージは消費が特に厳しい要件ではない繰り返された場合、これは直接うまく事務の一般的なスキームに導入されていない、そして、結局のところ、これは物事の非常に小さな確率です。
運用レベルでは、我々は、楽観的ロック、悲観的ロック、メモリデエンファシス（として、より選択的になるであろうhttps://github.com/RoaringBitmap/RoaringBitmap）および他の方法。
私たちは、あなたが楽観的ロックを使用して、通知するために、非同期メッセージング・システムを使用できるように積分操作は、メイン業務に配置する必要がないため、あなたはポイントテーブルを追加する必要があり、我々はユーザーのプラスポイントを与えるような、例えば、楽観的ロックを取りますバージョン番号フィールド。そして、メッセージと一緒にこのアカウントの最初の照会メッセージとバージョン番号の製造時にメッセージシステムに送信されます。
消費者はこのように、あなたはSQLの更新操作を実行するための統合をもたらすメッセージとバージョン番号、バージョン番号を取得します：
update score set score = score + 20, version=version+1 where userId=1 and version=1;このニュースの後、消費者の成功重複バージョンが存在する場合、バージョンが2になり、そう= 1つのニュースは再び、消費者にSQL文を引っ張るので、冪等メッセージを確保し、正常に実行されません。
メッセージは一度しか消費されていることを確実にするために、我々は、メッセージが一度に消費されることを保証するために、消費者の力この期間、利用に注力する必要があります。
今日では、一般的なレベルのメッセージングミドルウェアの上に立って、あなたは価値の記事を信じるならば、私は歓迎のポイントのように、あなたが学ぶのを助けるか、仕事に、今日の記事を期待し、そのデータが失われないと、一度だけ消費することを確実にする方法おしゃべりありがとうございます。
遂に
現在、インターネット上のミドルウェア関連記事メッセージング大物をたくさん持っている、任意の類似性は、私を許してください。元は容易ではない、コードワードは容易ではないですが、また、我々がサポートできることを願っています。また、テキストに誤ったが、何かがなさ見ると、あなたに感謝します。